Re: [AD] X hardware cursors fix

[Evert Glebbeek <eglebbk@xxxxxxxxxx>]

On Saturday 19 March 2005 16:51, Elias Pschernig wrote:
> > I don't like gfx_capabilities & GFX_SYSTEM_CURSOR though.  
> > "Capabilities" should be about the gfx driver's potential, not what it 
> > is doing at present.  Of course, gfx_capabilities & 
> > GFX_CAN_TRIPLE_BUFFER and gfx_capabilities & GFX_HW_CURSOR violate this 
> > already.
> 
> Yes, I see. So we would have a static field in each driver with its
> capabilities. Having GFX_CAN_TRIPLE_BUFFER in there would merely tell if
> the driver can principally do it, not if it is currently enabled.
> 
> GFX_CAN_TRIPLE_BUFFER we can't change for 4.2.0, because it already was
> in 4.0.0. But GFX_HW_CURSOR and GFX_SYSTEM_CURSOR we could still fix.

No, we cannot, at least not for GFX_HW_CURSOR: this has been in Allegro as 
far back as I can remember. I don't think it ever did anything except in 
DOS and Windows GDI (in the latter case, it's even a lie that it's a 
hardware cursor as far as I recall it's a hack to make Allegro think it is 
one), but it was there.
I don't much like the construction either, but considering that 
GFX_HW_CURSOR was already there, adding GFX_SYSTEM_CURSOR in the same 
manner seemed at least API-consistent.

> Add show_os_cursor(), so in the case where the user just wants a HW/OS
> cursor, there is no confusion. A simple return value tells if it
> suceeded or not. No need for any flags, since Allegro isn't in any way
> involved into drawing the mouse.
> 
> The show_mouse API, OTOH, means Allegro takes over mouse drawing. But
> since the user must be prepared for the software mouse in any case, what
> if we simply drop these 3 functions:
> 
> enable_hardware_cursor/disable_hardware_cursor/select_mouse_cursor

You need enable_hardware_cursor because hardware cursors (that includes 
system cursors) are incompatible with an infinite range of mouse mickeys: 
you can't have both, and Allegro's former behavior guarenteed it at least 
in X11.
I think we discussed this sometime last summer, or whenever the issue first 
came up. I think the consensus at that time was that we shouldn't break 
backward compatibility by changing Allegro's behavior with respect to 
mouse mickeys (despite the fact that it already doesn't quite work in 
windowed mode in Windows anyway). I'm not saying we can't recondider that 
(I think it makes sense to reconsider it, considering the bloody mess the 
X11 mouse driver is because of it), but it's a bit late now to do this for 
the 4.1/4.2 branch.

Ideally, the API would look something like `show this or such system native 
mouse pionter' or `use this bitmap as a mouse pointer'. The complication 
sets in if we want to use a bitmap as a mouse pointer but have the OS draw 
it anyway, which is preferable if possible. Hence the distinction between 
`software cursor', `hardware cursor' and `system cursor'. The first two 
are historic and the latter is new. It would make sense to have a 
`software cursor' and a `hardware cursor' that can be either a custom 
bitmap or a system default pointer I suppose, but this does not fit 
cleanly into the old mouse cursor API.

In short, while the mouse drawing code could be far simpler and cleaner 
than it is now, making it so is quite a bit more work than it seems.

Evert