On Sat, 20 May 2000, Andreas Beck wrote:
> > > Yes, as this _requires_ Hardware support.
> > Not really. You can do soft-cursors with transparency easily
> > enough, it just isn't very fast. You can hook ggiFlush() to ensure that
> > the cursor is always drawn last.
>
> DirectBuffer ?
>
> And how do you "retreat" the cursor before the next drawing command is
> issued on targets that directly map through (so that there is no backing
> store ...) ?
Hm. OK, perhaps it would be easier to just support cursors when
they are hardware accelerated |->. In which case, shouldn't hardware
cursor support go in the MISC extension along with WaitRayPos() and
SetSplitline(), which are also not supported when not hardware
accelerated? There would only need to be two functions, MakeCursor() and
SetCursor(), so it seems like overkill to have a whole extension...? It
would be very easy to add these two functions quickly to the MISC
extension, and lots of targets have accelerated cursor support. LibWMH,
LibGWT, LibXMI and Berlin could all use cursor functions....
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
