Author: Johan Klockars (as28-3-8.va.g.bonet.se)
Date: 05-28-2003 23:07
> The 16 bit colours issue is well weird.
>
> As it is right now, it DOES display everything, but the palette is all weird, and so I cannot see whats happening?
Sounds a bit strange.
What happens if you try to change a colour dynamically, like with the scroll bars in the colour CPX?
(Note that the normal colour CPXs will not actually change the desktop colours in a true colour mode. Only the specific colour rectangle in the CPX display will be affected.)
> BkGND IMG.
> Yes, at the mo, its got Jinnee's PAPER-Type Wallpaper, and the Jinnee Logo!
>I will kill those off to have a peek, however, the TT also uses the same piccies, but the 16 Colour ones as oopsed to the 256 colours ones, and that shows absolutely no flicker at all!
The TT has half the amount of data to send to the screen and way more bandwith to use for it. So, it's not strange at all that the Falcon will struggle.
If fVDI had been able to cache your background image on the RageII card, things would have been very different, obviously. Unfortunately, the VDI has no support for such things, and the 'tricks' that the fVDI RageII driver uses to improve matters are not 100% certain to work with all programs.
I've been planning on adding support for on-card, but off-screen, bit maps in fVDI, however. Using that, a program the knew about the feature could provide blazingly fast background image drawing (the same speed as screen to screen blits).
> Annoyingly, the TT scrolls WebPages silky smooth, while the Falcon is jerky as hell.
Could you name some specific web page that is jerky (and what browser you use)?
Anything that requires lots of data to be sent to the RageII card will unfortunately always (well, unless something like the planned functionality mentioned above is used) be somewhat slow (due to the slow Falcon bus). The actual scroll blit (which does not involve the bus) on the other hand, should be lightning quick on the RageII.
> The price here, is a colours trade-off still.
Only for images that need to be transferred.
There is no way around sending twice the amount of data for 16 bit mode, or four times for 32 bit mode, compared to 8 bit mode.
Text drawing, filling, etc, is done at very nearly the same speed in any mode, however.
> Even more annoying, is that GEMBench gives the Falcon 1200% and the TT only 600% so the
Well, most so called graphics benchmarks do not measure anything even remotely related to normal usage. At least GEMBench does not count circle/ellipse/rounded-rectangles for a major part of its score, unlike some recent benchmark programs I could mention. ;-)
Not that the GEMBench tests are any better, though (and some of them don't even measure what they are supposed to).
If you want to see impressive VDI drawing performance, you should check out some vector drawing program. For example, the demo of ArtWorx.
VDIBench is good at testing specific graphics operations, but it does not attempt to do anything approaching real work.
> Falcons display should be far, far better, and indeed you can see it is, but when it comes to normal use of it, its definitely NOT the case???
That depends on your definition of 'normal use'. ;-)
I almost never do anything with images, or anything that defeats the RageII driver's performance 'tricks', so my 'normal use' speed may well be significantly more than twice that of a TT.
> What did I do to get the speed a bit better?
> Well, basically I was simply eperimenting with the FVDI.SYS file more than anything! -
Sometimes a good idea, but perhaps some more information is needed on what the effects are of the various options.
> I did have the acceleration options set, and I have removed all that,
The default is to turn on all the 'acceleration functions', so there's no need to specify that option in normal use (it's mainly for driver testing during development).
> I have IMGCACHE out too, but I have kept
IMGCACHE could, theoretically, help a _lot_ with background image display. With it active, the driver tries to cache images on the card rather than transfer the data via the bus all the time.
For the time being, this only affects 32x32 images (standard size file icons), but I've been thinking about making some optional extension of this available.
(Note that this means that a background image that is 32x32 pixels will currently display _lots_ (as in perhaps more than ten times) faster than any other size.)
> SCREENCACHE ( or vice-versa )
IIRC, SCREENCACHE is necessary under MagiC to get the background save caching working at all (there's an AES function that is supposed to return the address of the AES's background buffer, which the RageII driver normally makes use of to cache menu and dialog backgrounds) but I seem to recall that not being useful under MagiC).
Unlike the semi-automatic AES background caching, SCREENCACHE is not 100% certain to work correctly. It assumes that any blit from the screen to RAM is done to save a background which will be blitted back again shortly. If an application does anything else with the supposedly fetched data (including blitting back the same image multiple times, which I've seen some drawing program doing), this will fail.
> but TBH I dont know if they helped all that much!
If your menus drop down instantly, you have SCREENCACHE (or the mostly equivalent AES background caching) to thank for it.
Otherwise there will be a noticeable pause before a menu is drawn,
IMGCACHE should be _very_ noticeable if you have a 32x32 pixel background image. It will also help speed up the drawing of file icons, as long as you don't have too many different types of icons showing (IIRC, the current cache is limited to storing <screen width>/32 icons).
|
