On Thu, 1 Feb 2001, Brian S. Julin wrote:
> On Thu, 1 Feb 2001, Stefan Seefeld wrote:
>
>
> > I'm totally confused. Of course, I don't know *anything* about h/w cursor
> > implementations, but I would assume that the cursor's pixel layout is the
> > same as that of the corresponding visual.
>
> Heh. Guess again. Most of the SVGA family have a 2-bit
X11-style (3 colors + transparent).
> or 4-bit depth,
Windows GDI-style (15 colors + transparent).
> and it is an index of a register which contains a value which can be anything
> from entirely independent from the main visual, to an index into the
> main visual's palette, to a raster op (transparant, inverse video, etc.)
Right. Gotta hide all that nastiness away inside the target code.
> And a lot of the chips have different registers you can poke around with
> to change the maening of the values of the cursor color registers.
>
> Getting this into an API that anyone is going to want to use is a worthy
> program design challenge :-)
I think that compiling a 4bpp visual into the target's native
cursor format should cover just about all cases. There's always only one
transparent color, and the 2bpp/1bpp cursor formats can just use the first
N CLUT entries from the 'master' cursor bitmap. If it turns out to be
impractical or impossible to do this native cursor format compilation
automatically, we could #define some CURSOR_HINT_TYPES or similar to work
around this. Alternatively, we could just say that if you don't use a
supported cursor format, it will automatically fall back to using a
software cursor. Or we could define the cursor using a vector-based
format, or....
> > Having a palette for the cursor
> > which needs to be translated into the visual (palette or truecolor) seems not
> > to make much sense. And why 4 bit ??
>
> <cynical>
> In order to make it difficult for us to get the cursor to work in the
> first place. In fact, there are even highly advanced ways of making
> it difficult for us to get the cursor to work, like not allowing the
> data for the curcor to reside in certain areas of the framebuffer memory.
> </cynical>
>
> (which is why we need a "feature negotiation API" before anything like
> the cursor or sprite libraries see hardware acceleration.)
We need feature negotiation to do this really well, but I really
think that a QuickHack(tm) is called for _right now_. Even if the damn
thing only does 2bpp software cursors, that would be much better than what
we have now (nothing).
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
