At 05:50 PM 30/10/2001 -0800, you wrote:
No no. Usually (0,0,0) means the default rgb layout. But if you always go to asis in that case, then things will be wrong for users with a bgr565 X configuration (should reverse in that case). SetImageBits_* and GetImageBits_* should never get (0,0,0) as the color masks. They don't know how to handle it and should not have to, their callers are supposed to take care of that. I think i found the source of the problem, some old code I had not changed. Can you try the attached patch?
I did and it does not change anything. I don't quite see how it could, since it does not seem better to not initialize data than initialize it to a wrong value :-)
I tried ff0000/ff00/ff instead, with better success...
Gerard
Gerard Patel wrote:
At 05:50 PM 30/10/2001 -0800, you wrote:
No no. Usually (0,0,0) means the default rgb layout. But if you always go to asis in that case, then things will be wrong for users with a bgr565 X configuration (should reverse in that case). SetImageBits_* and GetImageBits_* should never get (0,0,0) as the color masks. They don't know how to handle it and should not have to, their callers are supposed to take care of that. I think i found the source of the problem, some old code I had not changed. Can you try the attached patch?
I did and it does not change anything. I don't quite see how it could, since it does not seem better to not initialize data than initialize it to a wrong value :-)
Well, 0 is always wrong. So the previous code was always initializing it to a wrong value. I was expecting descr.compression to be different from BI_BITFIELDS which would give the expected 0xff0000, 0xff00 and 0xff. What is the value of descr.compression?
-
François Gouget -
Gerard Patel