Bug in QDGetCursorData on Intel?
Bug in QDGetCursorData on Intel?
- Subject: Bug in QDGetCursorData on Intel?
- From: "Daniel Mitchell" <email@hidden>
- Date: Fri, 28 Apr 2006 09:45:31 -0600
- Thread-topic: Bug in QDGetCursorData on Intel?
We've been using QDGetCursorData to read the system cursor -- it works
fine on PowerPC Macs, but on Intel Macs, it can return incorrect values.
Here's some examples -- left-hand side is what the actual ARGB value is
for the cursor, right-hand side is what QDGetCursorData returns for that
pixel.
ff ff 00 00 -> ff ff 00 00
ff 00 ff 00 -> ff 00 ff 00
ff 00 00 ff -> ff 00 00 ff
ff ff ff 00 -> ff ff ff 00
ff ff 00 ff -> ff ff 00 ff
ff 00 ff ff -> ff 00 ff ff
ff 00 00 00 -> ff 00 00 00
ff ff ff ff -> ff ff ff ff
ff 8c 00 00 -> ff 8c 00 00
So far, so good. And, in fact:
XX 00 00 00 -> XX 00 00 00 [for any XX, ie pure black works for any
alpha]
ff XX 00 00 -> ff XX 00 00 [for any XX, ie opaque pure red works]
ff 00 XX 00 -> ff 00 XX 00 [for any XX, ie opaque pure green works]
but..
ff 00 00 05 -> cd 00 00 05 [dark blue returns the wrong value]
ff 00 00 0d -> 89 00 00 0d
ff 00 00 15 -> 18 00 00 15
ff 00 00 70 -> 44 00 00 70
and so on -- shades of blue return the wrong value for alpha. The blue
value itself is correct, but I can't distinguish a transparent pure blue
with correct alpha from a pure blue with corrupted alpha. Similarly,
shades of grey go wrong:
ff cc cc cc -> 3e ff ff cc
ff 99 99 99 -> a9 ff ff 99
ff 87 87 87 -> e1 ff ff 87
ff 18 18 18 -> 95 ff ff 18
ff 10 10 10 -> e0 ff ff 10
ff 08 08 08 -> c0 ff ff 08
Again, the blue value itself remains correct, but if the blue value is
non-zero, in this case it'll corrupt the R and G values as well as the
alpha. There's a sort of pattern here, but nothing that I can obviously
use to reverse the corruption of data. If I'm passing in other colours,
things just go completely to pieces:
ff ab cd ef -> 10 b6 da ef
ff 12 34 56 -> f4 35 9a 56
ff 12 ef ed -> 12 13 43 ed
ff cc ff aa -> 7e 32 7e aa
ff 98 76 54 -> 06 cd 66 54
Does anyone know if there's a way to make this work properly? The
corruption of data seems to be consistent, I'll get the same wrong value
back for the same input value, and thus far, I haven't found any two
input values that return the same output, so theoretically I could just
create a 2^32-entry lookup table -- but I'd much rather not do that if
possible..
Would it be possible to somehow render the cursor into an offline
bitmap and then pull the pixels out of that? The cursor functions are
fairly unhelpful -- I'm using QDGetCursorData because, while deprecated,
at least it's in a header file somewhere (rather than
CGSGetGlobalCursorData, say) -- but given QDGetCursorData is returning a
broken PixMap, it seems like I need some other cursor function to tell
the system to draw it.
A bit of testing shows that if I set the cursor scaling to large enough
(for some mysterious value of 'large enough' -- it's not the scaling
itself, it seems to be related to the _width_ of the resultin cursor)
then the cursor starts to get drawn onto the screen as pixels, rather
than a hardware cursor (and then the position reported for the cursor is
not the same as the actual position of the drawing of the cursor) but I
can't see an obvious way to take advantage of that without drawing a
white(black, something) rectangle onscreen, positioning the cursor over
there, scaling it, capturing that part of the screen, and working out
what was going on (alpha?) -- even if it worked, it would be distracting
for the user.
I've bugged this, but does anyone have any other suggestions?
thanks,
-- dan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden