From: becka@rz.uni-duesseldorf.de
  To  : ggi-develop@eskimo.com
  Date: Fri, 4 Jun 1999 09:32:49 +0200 (MET DST)

Re: GGI Cursor API proposal.

Hi !

> > > 	void*	image;	// Must be of the same depth and color
> > format as the corresponding ggi_visual_t;
> > 
> > This is _not_ the usual case. Most HW cursor are of a
> > really different
> > format.
> O.k. If so we can accept plain RGB or YUV bitmaps and do
> the actual conversion and scaling in ggiCreateCursor().

Even that won't suffice. We will have to be able to set some extra data, like
colors that induce a xor/and/or with the underlying bitmap, colors that are
transparent etc. 

Maybe a completed LibGGI2D might help here, as IIRC it has all the hooks and modes needed.

> > > ggi_cursor_id_t	ggiCreateCursor(ggi_cursor_t	cursor);
> > > int	ggiMoveCursor(ggi_cursor_id_t	cursor,	int	x,	int
> > y);
> > > int	ggiHideCursor(ggi_cursor_id_t	cursor);
> > > int	ggiShowCursor(ggi_cursor_id_t	cursor);
> > > int	ggiDeleteCursor(ggi_cursor_id_t	cursor);
> > 
> > This lacks cursor image setup.
> What kind of setup do you need? I wasn't aiming for a
> perfect API. Just one that is simple, useable, and can be
> implemented now.

I think the best way to set up the cursor image would be, if we can 
Crossblit it from another visual. That's in the line of the general 
LibGGI philosophy.

I think I have proposed a sprite/bob API a while ago and we've been 
discussing that between the "hardcore coders" for a while, but then 
got distracted.

We should finally implement it. I'll skim through my mail archives 
and check with Marcus for a good preliminary API and then we should 
set up a "stub" extension.

> > > Systems that do not support hardware cursors can use
> > > software emulation.
> > No. They can't. This has been discussed here several
> > times. Please read up
> > the ML archives on that topic.
> If you have a better idea and want to implement it, great.
> :) I'm just selfishly trying to add features to GGI so I
> can make my stuff work. :) 

Please don't feel pissed, if I sound arrogant or something. 
It's just that the subject has been up too many times and noone 
ever coded something.

> Software implementation is not a problem even in DirectBuffer when the 
> proper hooks are added to GGI. 

You are right in the sense, that GGI now _has_ hooks for that with the 
RessourceAcquire code.

> It will probably be ugly and slow, but it'll work. 

As Linus said one day: I don't think we should emulate braindamage.

If we make it a general Sprite/Bob API, I'd say we shouldn't try such 
an emulation anyway, as it will be overly complex and slow.

The point is, that if you have no HW-cursor, the application should be 
told about that, as it can usually better decide on what to do then.
Often significant optimizations can be done, if the application handles 
the cursor, then.

With respect to multithreading, we'd have to at least block on sprite 
operations and all others, if emulated sprites are present, if we tried 
to emulate, so I'd say we should keep our hands off that.

> Or we can add:
> boolean ggiCursorAvailable() and avoid all that extra code.

Yes. Something along that line makes sense.

> Whatever the case, help me improve the API or replace it
> totally with your genious. Something is better than nothing.

Right you are. And I got the feeling you really want to get that done, so
I again apologize, if I sounded harsh.

Let's discuss this for the last time now. Let's find a good way to 
implement it and just do so.

I'll dig out the mails about that subject when I get home and forward 
them to you, so we can have a look at all previous thoughts and find a
good solution.

CU, ANdy

-- 
Andreas Beck              |  Email :  <Andreas.Beck@ggi-project.org>