web page last updated Tuesday 29th July 2003 1230am

Tue.29.jul.2003 1230am: further to sun.27 below a lot of improvements to the viewers are being done. In particular the viewers should be faster and more memory efficient on AGA. Full details when I make the upload.

Sun.27.jul.2003.evening: I am still looking into some things which are consequences of matters mentioned by JM Boucher, as a result of this I will try to make some changes to the code.

Some dilemmas: To get nice viewer behaviour you need to use interleaved-bitmaps on AGA. This removes a "flash" when the window image is updated. Interleaved bitmaps cause images to be updated on a line by line basis which is visually clean, non interleaved ones update plane by plane which means that for quite some time (ie until the last bitplane is begun) the entire image is incorrect.

Now we come to a problem, interleaved bitmaps appear to use 1 huge contiguous piece of memory covering all the bitplanes, this means if memory is fragmented it may be impossible to run the viewer, or impossible to have the scroll + zoom features. The non-interleaved bitmaps will be better for when memory runs low.

Anyway so I may put an option to allow non-interleaved BitMaps for AGA.

Some further problems, in the release version of gs8 all BitMaps are allocated by the OS, for graphics cards this is the only option. Now it would be nice to be able to use VM for non displayable BitMaps eg via the VMM program. But because the BitMaps are allocated via the OS I think they are in public memory ie not possible for VM. I attempted allocating the entire BitMap for AGA by hand in non public memory but they didnt function correctly. Its possible the OS BitMaps are always in graphics memory which then limits what the viewer can do.

JM Boucher said he didnt get the full page height when viewing via AGA. This is because the AGA viewers are by default restricted to a 800 x 800 subset of the full bitmap due to OS blitter bugs that cause malfunction beyond about 1000 pixels.

On the version I am now creating I am increasing this subset to 800 x 950 which will deal with typical PDF pages.

You can get around the problem for now via:

set whooshysafe 950 

:this increases the maximum AGA bitmap height to 950,

Similarly you can increase maximum AGA bitmap width via env-variable whooshxsafe.

For Cyber there is no such problem although the Cyber viewer is limited to approx 32000 x 32000 pixel subset of the full bitmap, (this would take up 3 x 32 x 32 million bytes== 3 Gig, so its not actually a problem, ie you will run out of memory before you hit this limit!). I calculated that with 50Mb fast memory you could fit a full 400dpi truecolour a4 bitmap in RAM for graphics cards!
Get a GoStats hit counter