[interfacekit] Re: Cursors and acceleration info

Hi everyone,

I just want to say a few more things about the driver-side of things, 
and what I came across when working on NeoMagic's acceleration engine.

->CURSOR:
personally I won't mind a softcursor if it can be done without 
flickering. The hardsursors in graphicscards require position updating 
synced to retrace (taken care of in the driver as it should be). What I 
currently do is only sync if needed in the specific way that's needed 
on a per card basis. On some cards this loads the CPU considerably and 
I hate it (try nvidia while cursor is in lower part of screen compared 
to higher part of screen for example.
Much better (and much more universal) would be to update the position 
inside the kernel driver in the INT routine that is synced to retrace, 
and let the move routine only update the position in the shared_info 
struct, then return. (it's on my todo list somewhere :-)

The colordepth of a softcursor will not always be 32bit: you can only 
do that when the framebuffer is in 32bit space of course. For lower res 
you'd need to forget about the ls-bits to make it work. 

The current Be drivers can do just four colors, which is supported on 
_all_ graphicscards (Except in some modes/heads): black/white/intert/
transparent. I'd like it if we expand the interface to the driver at 
some point to use 32bit hardsursors when available alongside keeping 
the 4color cursor as it is now. All  nVidia cards can do that for 
example. the hardcursor can do this space for all framebuffer spaces of 
course as it's a seperate layer (just like hardware overlay for video 
which always displayes 32bit color (24 bit in fact of course ;-)

->ACC
I've been playing around with BeRoMeter 1.2.6 on my NeoMagic laptop(s) 
running DANO.
The functions:
Graphics ellipses flushed;
Graphics ellipses unflushed;
Graphics ellipses unflushed filled;
Graphics rectangles flushed;
Graphics rectangles unflushed;
Graphics polygons unflushed filled.
Are all hardware accelrated.
These functions all call the driver's fill_rect function by default. 
This means a single ellipse for example is split-up in fitting rects 
(top to bottom I suppose or you would probably see artifacts if 
'random' or partly software/hardware filling is done) that gets placed 
in a argument list that gets sent to the engine in a single fill_rect 
command (if one color is used). These rects you could interprete as 
lines with vaying width I guess.

If I disable the fill_rect command in the driver, the app_server falls-
back to fill_span to use instead.

I never looked at the Be API to applications for this, but I am 
assuming the figures BeRoMeter tests are existing in the API 1:1. It 
does not use tricks to get acc (no clones).

Remarks:
-Dano's app_server tends to send fill_rects (or spans, or invert) with 
zero-width sometimes. This should be prevented in the future, some 
engine's can't stand that and of course this slows things a bit down 
unnessesary also. (NeoMagic engines mess up big-time if you do this so 
I have to check the commands now for zero width and not execute if I 
have one)
Test: NM2070-NM2160 mess up with BeRoMeter on the above accelerated 
functions on Be's Dano (R4 style) and R3 drivers (included in R5: 
app_server addon). The slowness you'll witness is another problem in 
the Be drivers BTW

->Dano's blue selected menu-items are an example of fill_span use. one 
command with a list of spans surrounding the characters in the menuitem 
is given. (R5 app_server use invert rect here: one single rect is given 
then, instead of the big list needed for fill in DANO)

I guess I am talking a bit about these 'spans' here because of the 
clipping conversation going on ATM BTW.

--------

OK, that's it. You'll have to determine the relevance of the info I 
gave here yourself. I still am a bit of an outsider here I think, but 
it might help you if I provide some info from time to time from the 
driver's viewpoint I guess :-)

Best regards,

Rudolf.

Other related posts: