Geminus and PhotoFiler

For support of the Geminus screen acceleration feature
Post Reply
mikebatten
Posts: 7
Joined: Fri Dec 09, 2005 3:22 pm

Geminus and PhotoFiler

Post by mikebatten » Fri Mar 24, 2006 4:41 pm

Since upgrading to Geminus 1.30 PhotoFiler no longer displays thumbhails of JPEG images correctly.

Any suggestions?

admin
Site Admin
Posts: 381
Joined: Wed Oct 23, 2002 11:25 pm
Location: Cambridge, England
Contact:

Post by admin » Fri Mar 24, 2006 5:44 pm

Well, the obvious explanation would be that Geminus's JPEG code is interfering in some way, though I haven't seen that and know of no such fault.

I don't have PhotoFiler, so could you please (i) explain in what way it is incorrect/failing now, and (ii) try loading the same images into !Thump - http://www.kpo.org.nz/rick/software/thump.html and !Draw?

Thanks

mikebatten
Posts: 7
Joined: Fri Dec 09, 2005 3:22 pm

Post by mikebatten » Fri Mar 24, 2006 10:23 pm

Prior to running version 1.30 of Geminus, PhotoFiler would display minature thumbnails of JPEG images from my Canon digital camera when opening a filer window containing the JPEG's.

Now the thumbnail's are just a mess of coloured pixcels. The images open normally when dropped into !Draw or Variations. It is only the thumbnail view that is a problem.

admin
Site Admin
Posts: 381
Joined: Wed Oct 23, 2002 11:25 pm
Location: Cambridge, England
Contact:

Post by admin » Mon Mar 27, 2006 7:53 am

I've been investigating this and the only explanation that I can come up with is that maybe PhotoFiler contains a fault that prevents it working with its dynamic area(s) are high addresses, and that Geminus 1.30 induces this by claiming more memory than version 1.20.

However, we might find some more clues by trying the following, please:

(i) Firstly, please confirm that the 'Accelerate JPEGs' option is greyed out in the Settings pane of !GemConfig
(ii) with PhotoFiler displaying corrupted thumbnails, open a TaskWindow and type RMKill Geminus
Does this fix the thumbnails if you then drag a window across them? What about newly-created thumbnails if you open a new directory?

(iii) if the dynamic area theory is correct, PhotoFiler may also fail without Geminus running. Try restarting your box without PhotoFiler or Geminus in the boot sequence, and run the 'Fill' util in the following archive: http:://adrian.aemulor.com/downloads/dautils.zip - before starting PhotoFiler.

Beyond that, any further information that you can supply would be useful, please, because I can't see anything wrong with the code.

OzMac
Posts: 3
Joined: Sat Sep 04, 2004 5:01 am
Location: Adelaide, South Australia

Post by OzMac » Fri Apr 21, 2006 2:35 am

adrianl wrote:I've been investigating this and the only explanation that I can come up with is that maybe PhotoFiler contains a fault that prevents it working with its dynamic area(s) are high addresses, and that Geminus 1.30 induces this by claiming more memory than version 1.20.

However, we might find some more clues by trying the following, please:

(i) Firstly, please confirm that the 'Accelerate JPEGs' option is greyed out in the Settings pane of !GemConfig
(ii) with PhotoFiler displaying corrupted thumbnails, open a TaskWindow and type RMKill Geminus
Does this fix the thumbnails if you then drag a window across them? What about newly-created thumbnails if you open a new directory?
(iii) if the dynamic area theory is correct, PhotoFiler may also fail without Geminus running. Try restarting your box without PhotoFiler or Geminus in the boot sequence, and run the 'Fill' util in the following archive: http:://adrian.aemulor.com/downloads/dautils.zip - before starting PhotoFiler.

Beyond that, any further information that you can supply would be useful, please, because I can't see anything wrong with the code.
I do hope my intrusion does not confuse the issue.
I came looking for a solution for this precise problem.

(i) Yes it is grey.

(ii) I get this response.
"Geminus can't be killed at the moment (Another program is using the SWI vector)"

(ii) No change as the module was not killed.

(iii) I noted no difference having done this.

admin
Site Admin
Posts: 381
Joined: Wed Oct 23, 2002 11:25 pm
Location: Cambridge, England
Contact:

Post by admin » Fri Apr 21, 2006 11:32 am

Thanks very much for the information, both here and via email. I think the most likely explanation now is a conflict between Geminus and WimpSWIVe which PhotoFiler uses. It could be worth ensuring that all acceleration options are disabled for the Filer app (it doesn't benefit greatly from acceleration unless you have very large directories like mine!) and, also, can you please confirm whether it happens for all thumbnails or just JPEG thumbnails. Thanks.

One other thought - I would expect the two to coexist more happily if Geminus is started first, and then PhotoFiler/WimpSWIve. Given the 'SWI vector in use' error that you reported, I suspect, however, that you are already starting them in that order?

I will look into this again when I have access to all my dev equipment; hopefully in a couple of weeks. (I am between addresses right now and most of it's in storage :roll:)

OzMac
Posts: 3
Joined: Sat Sep 04, 2004 5:01 am
Location: Adelaide, South Australia

Post by OzMac » Sun Apr 23, 2006 11:41 pm

Disabling all acceleration options appears to make no difference except slowing non-PhotoFiler functions. Until Iyonix gets Select type thumbnails I do find PhotoFiler useful and had hoped Geminus would speed display of 'big' folders.

Other thumbnails (viz draw, sprite, artworks except for a few which seem to have blending) are fine. The JPEGs themselves display the top 10% or so before pixelating.

I load Geminus first.

I have now removed all apps loaded at booting to seek the clash when trying to RMKill as it occurs even when PhotoFiler has not been loaded. It would appear that the app using the SWI is Aemulor or associated app. I can RMKill Geminus if Aemulor is removed.

I should also have said of the inability to RMKill Geminus that the iconbar icon disappears but not the module.

Post Reply