On Thu, 1 Feb 2001, Lee Brown wrote:
> On Thu, 01 Feb 2001, Stefan Seefeld wrote:
> > Lee Brown wrote:
> > >
> > > Like I said, I've been working on cursors.
> > >
> > > Heres the api. In particular, I wonder if one thing I did was acceptable. I
> > > allow multiple cusors to be loaded into the visual. The user selects which one
> > > to show with ggiSetCursor. Is it bad that I require that the cursor handle
> >
> > so you assume that there is exactly one cursor at any given time.
> > That may not be the case. X may have such a restriction, but in berlin you can have
> > as many positional devices active at any time as you want. Each one has its own
> > cursor, focus, input event queue, etc.
>
> Well, I thought of this. But does anyone know of any piece of hardware that
> supports multiple cursors?
Well, any hardware which supports multiple sprites supports
multiple cursors. Amigas and Atari STs at least. And of course even a
single HW cursor can be virtualized and muxed within a device driver or
suchlike.
> Is this a trend in graphics cards?
Not that I know of, in SVGA PC-style video HW at least.
> I will agree that supporting multiple cursors seems less restraining, but at
> the cost of simplicity.
True. I say start out with single-cursor support and migrate to
multiple cursors later on if it becomes an issue. All of this is alpha at
best anyway right now....
> Can anyone else comment on this?
IMHO, one of the main sticky points here is that this
cursor/bob/sprite thing is doing something we've not done much before in
GGI: Manage persistent state for rendering primitives. We aren't just
drawing cursors/sprites, we are managing cursor/sprite _objects_. We have
to. Now, we have a whole host of new issues to contend with:
* Retained vs. immediate mode API (per-visual metadata persistence)
* Sprite format vs. visual format ("compiling" the sprite data)
* Allocation of hardware resources (grant/retract, HW resource DBs)
Of course we don't have to deal with all of this in a 100% correct
fashion right away. I'd start out by assuming only one cursor, stored in
Microsoft format or X11 format natively, compiled into a target-dependent
format (possibly also M$/X11 format for SVGA-style video HW), and cached
in the visual private data struct. Simple, straightforward, supports both
accelerated and unaccelerated cursors, and should cover 95%+ of both the
needs of the cursor API users and the target featuresets.
Another point is this: there is no law which states that all GGI
extensions must have non-overlapping feature sets. For example, I could
fairly easily add X11-style cursor handling functions to LibXMI. This
_would_ complicate things, since now the app code would have to either
forego the use of other APIs or possibly be forced to use LibXMI for other
stuff besides cursor support. Clunky clunky clunky. BUT, the task of
implementing cursor support does become _MUCH_ simpler when the cursor API
doesn't have to be as generic and comprehensive as a general-purpose
cursor API would end up being.
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
