"Jon M. Taylor" wrote:
> Right. Gotta hide all that nastiness away inside the target code.
precisely.
> 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,
always ? I want 256 alpha levels....
> 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
yes, exactly. Isn't the first line you write about 'hiding this nastiness'
just that ? Seriously, my requirement for more alpha support was just to
make the point: if it turns out I don't use it for a given cursor (i.e.
a simple shaped cursor), all the better, let's use a h/w cursor. But if I want
a cursor that blends into the background, why should I (the high level GUI
programmer) need to care ? The more you hide inside the low level API, the
easier it is to adapt to other h/w architectures, which may support such
(not so) exotic features in the future.
And of course, this is a general question. You probably remember our discussions
concerning berlin's region management. I would love to delegate that stuff
to a lower level API, but there just isn't any API that deals with arbitrary
shapes, or alpha support (requiring retained mode graphics, as you say in another
mail). It's not so much that I'm keen on using 45' rotated windows, but it
must be possible (or shapes with holes, or whatever) !
And if the low level API can't deal with it, I have to provide a high level wrapper
that then decides case by case whether it can delegate down or needs to implement it
itself.
Regards, Stefan
