Before implementing a single way to handle bitmap cursor or monochrome cursor I’d like to let you know that the Hardware cursors in video cards history had faced multiple changes in color depth. With a brief search on the web I found:
video cards from long time ago (1987) like the original IBM chips or S3 Trio64 / Virge, Cirrus Logic, ATI Mach32 / Mach64 had 1 bit color depth
later some cards adopted 2 bits color depth like the Tseng Labs ET4000/W32, Matrox Millennium the first series of 3dfx Voodoo Rush/Banshee, and actually the SM750 I recently bought.
4 bits used on amigas or unix systems like Silicon Graphics or Sun Microsystems
8 bits like ATI Rage Pro, NVIDIA RIVA 128 / TNT, and Matrox Mystique
16 bits 3dfx Voodoo 3/4/5, NVIDIA GeForce 256 / GeForce 2 / 3, and ATI Radeon DDR (7000/8500)
32-bits Intel HD/Arc, NVIDIA GeForce 4 / FX, ATI Radeon 9000 and laters
so this is my idea: if we want to give a proper method to handle the hardware cursor colors we should make driver pass this information to accelerant and through a Hook inform the app_server the capability of the card
then the App_server will convert the image properly according to card capability.
Another solution (the one I prefere) can be: after informing the app_server about the card capability of hardware cursor depth, if it can’t handle 32bit cursors, disable hardware cursor only for dragging operation, and restore hardware cursor after restoring the normal cursor. So poor cards can have both worlds.
So far, I think it would be enough to just call SET_CURSOR_SHAPE if SET_CURSOR_BITMAP is not available. However, I would prefer if this is guarded behind a settings file – by default, I would prefer if the app_server uses software cursors if proper bitmap cursors are not available.
Or, alternatively, always support SET_CURSOR_BITMAP (and simply remove SET_CURSOR_SHAPE), and have some shared code that reduces the color space to whatever is required only if that option has been set.
This have sense, as the code example of @PulkoMandy, the pity would be not improving cursor quality if possible, a 16bit, 8 bit or even a 2 bit cursor has more visual appeal than the plain 1 bit with mask that provides SET_CURSOR_SHAPE.
that’s the reason of my last solution: provide a nicer accelerated cursor by default (which resolves the problem of Z-order explained before) but it fallbacks to software rendering when not able to handle all the needed colors (for example in dragging items).
this seems my first idea:
although I think removing SET_CURSOR_SHAPE will cause some problems for some apps
I don’t know if you can see this animated gif, but this would be the result if hardware cursor B_SET_CURSOR_BITMAP (with limited colorspace) will be mixed with software fallback when dragging
I wonder why drag bitmap has so large unneeded transparent part at right-bottom. It should be possible to remove that unneeded part. Maybe Tracker problem that use too big drag bitmap.
IIRC the drag bitmap from Tracker feature a max size with gradient, and I suspect the bitmap is always sized to this max size initialized as transparent whatever the actual amont of real content in that drag bitmap.
There were some recent changes to this code, first to make its size unlimited, and then restoring a limited size but with some changes from the previous code. Maybe I didn’t look into that last change carefully enough when reviewing and merging it and it introduced a regression in the computation of the drag rectangle in the case where it doesn’t need to be the largest possible and use the fade out.
