Accelerating the ArtWorks Apple4

For support of the Geminus screen acceleration feature
Post Reply
pittdj
Posts: 19
Joined: Sun Feb 23, 2003 10:51 pm

Accelerating the ArtWorks Apple4

Post by pittdj » Sat Dec 10, 2005 6:10 pm

With a mode of 1600x1200x16M the ArtWorks Apple4 file is initially cached by the Geminus accelerator 1.10. Cover it with another window then bring it to the top and it redraws instantly. This stops happening after a while, the Apple4 is redrawn the hard way. Reboot the Iyonix and Geminus is back in business.

Further investigation shows that any mode change, even reselecting the current 1600x1200x16M, will restart Geminus redrawing this example instantaneously. The way stop Geminus cacheing the Apple4 is to run through several other of the Artworks demo files then try the Apple4 test again.

A large JPEG, however, is always accelerated. Indeed the large JPEG can be used as the cover for the Apple4 then just bring each one to the top in turn. The large JPEG is instant and the Apple4 is redrawn by ArtWorks.

Switching off Other apps and explicitly switching on ArtWorks in Choices did not help.

I have come to the view that the Apple4 failure though anomalous does not mean Geminus is not doing other good work.

I use the ArtWorks Viewer 1.74.

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

Post by admin » Sat Dec 10, 2005 6:17 pm

What are you using to display the JPEG?

pittdj
Posts: 19
Joined: Sun Feb 23, 2003 10:51 pm

Post by pittdj » Sun Dec 11, 2005 8:08 am

The JPEG was being displayed by ChangeFSI.

I have now seen the opposite of my earlier report where the large JPEG is the one not to be cached and Apple4 was OK.

Better still I have now seen both the JPEG and Apple4 not being cached. PrivatEye was displaying the JPEG.

The Iyonix is 3 years old with its original NVidia.

I have attached a diagnostic that did not change from working to not working.

*geminusinfo
Surfaces
--------

surface 00000001
name <unnamed
flags 40070000
screens 00000001
claimed 00000001
locked 00000000
base 47D00000
ttl size 01700000
areabase 47C18000

Screens
-------
available 00000000

screen 00000000
flags 00000000
base E8900000
phys 78000000
range 01F00000

*

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

Post by admin » Sun Dec 11, 2005 2:37 pm

The last number - range 01F00000 - shows that you have a 32MB card which means that, combined with your large 1600 x 1200 x 16M screen mode, you're seeing a weakness of the cache management rather than a fault as such. As you noted it does cache properly, but only under specific circumstances, making it too fussy to be useful on your machine just yet.

I have some changes planned for testing and release in the next few days; tbh I was hoping not to need them just yet because the current code is stable and works well on screens up to 1280 x 1024. Unfortunately it is hard for me to test its operation on larger screens because they exceed the capabilities of my LCDs. (I will find a way though!)

Wait for the update, and see how that performs.

As I've said elsewhere, you can assist the cacheing my enabling it only for those specific applications that benefit most. ChangeFSI shouldn't need to be cached, BTW, because its plotting will already be accelerated by the DMA hardware via Geminus (make sure the first option, sprite plotting is ticked in the Settings pane) which, although not as fast as cacheing, is not much slower.

pittdj
Posts: 19
Joined: Sun Feb 23, 2003 10:51 pm

Post by pittdj » Sun Dec 11, 2005 4:13 pm

I would be willing to attempt to assist to pin this down.

gtgreenfield
Posts: 5
Joined: Wed Jun 29, 2005 9:27 am

Accelerating the Artworks Apple4

Post by gtgreenfield » Thu Dec 29, 2005 9:38 am

I'm running Geminus 1.20 on RO 5.09 in an Iyonix X100 with a 64MB nvidia card (as standard). The version is Acceleration only: I am not using mulitple screens or cards. I have disabled redraw cacheing in the case of Photodesk - all other apps are fully enabled. The Apple4 file is not being cached consistently: when first opened, the file redraws each time the window size is adjusted by dragging from a small area to full size, and whenever another filer window is brought to the front over it. F12-Return causes the file to be cached, whereupon redraws are instantaneous: but altering the image scale (for example) causes it to redraw and then F12-Return does not always provoke cacheing.
I had assumed that opening /any/ file object with redraw cacheing enabled would automatically cause the object to be cached but this is apparently not the case with the Apple4 file on my system.

George

gtgreenfield
Posts: 5
Joined: Wed Jun 29, 2005 9:27 am

Accelerating the Artworks Apple4I

Post by gtgreenfield » Thu Dec 29, 2005 10:24 am

Progress: I've disabled redraw cacheing for all except the following: Artworks, DPingScan, Firefox, Firefox Integration, Messenger Pro, SwiftJPEG and Thump. It now seems to work reliably in the case of the Apple4 file.

I don't know if my choices above are valid: it would be helpful to have an 'authorised' list of which apps benefit from the various accelerations and redraw cacheing, and which don't.

George

User avatar
druck
Posts: 11
Joined: Sun Nov 03, 2002 8:02 pm
Location: Gloucestershire
Contact:

Post by druck » Wed Jan 04, 2006 2:00 pm

adrianl wrote:The last number - range 01F00000 - shows that you have a 32MB card which means that, combined with your large 1600 x 1200 x 16M screen mode, you're seeing a weakness of the cache management rather than a fault as such. As you noted it does cache properly, but only under specific circumstances, making it too fussy to be useful on your machine just yet.
I'm in a similar situation with an original 32MB card, but using a 2048x1536x32bpp mode. There was no caching of windows in this mode, although it did work down in 1280x1024x32bpp. I changed the amount of screen memory in GemConfig down from 16MB to 13MB, and did get some caching of the apple initially in 2048x1536x32bpp, but it stopped again after some desktop usage.

I can't really detect any accelaration with Geminus in normal use of the desktop so far, although I've yet to perform any benchmarking to look for improvements in the areas specified. Could the low amount of available memory on the old cards with a large screen mode be affecting anything else?

I think Geminus could do with some more diagnotic *commands to reveal what the graphics card memory is being used for, and what features are active. I suspect this would also aid debugging of reported problems.

Cheers
---Dave
The ARM Club www.armclub.org.uk

User avatar
druck
Posts: 11
Joined: Sun Nov 03, 2002 8:02 pm
Location: Gloucestershire
Contact:

Post by druck » Mon Jan 23, 2006 12:29 am

Any offical comment on this?

I am not happy that Geminus provides any real worth when using 2048x1536 mode screens with the original 32MB graphics card, and I'd like to know if this is being addressed.

Cheers
---Dave
The ARM Club www.armclub.org.uk

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

Post by admin » Mon Jan 23, 2006 11:17 pm

Making better use of the available storage is definitely on my list of things to do, and will happen. The code was written to cope with any screen dimensions and I can't see any reason why it should fail to work at your screen res (indeed, a 2048-pixel wide screen - albeit 2048 x 1024 - does work fine here), though I'd be grateful if you could confirm that it still doesn't cache with v1.20 after deleting the existing !Boot.Choices.Geminus.Config file, just to be sure that the cache isn't being filled by apps like Pinboard and Filer which are quick at redrawing already.

As I've said before, I cannot readily test at higher vertical resolutions because my LCD panels won't display them, but I have some prototyped code for allocating extra cache in the main memory (SDRAM) which will help with larger screens as well as allowing me to create a 'virtual store' with the same dimensions as that on your card, and thus hopefully work out what's happening.

Please understand also that I am working on Cino too.

Post Reply