Michael Schmid wrote:
> Nikita Egorov schrieb:
>>>> It looks a bit like a little/big-endian problem. Is this known Problem?
If it were just an issue of big vs. little endian,
FLTK supports both; it was originally designed on SGI (big endian)
32bit and 64bit, and when ported to windows/linux intel, it had to
deal with small endian details, which was a long time ago.
It's possible your processor might need some special flags if
it's somehow being detected with the wrong endian-ness, but
more likely the graphics hardware has a 'different twist' on
the byte ordering, where as Ian wrote, it sounds like white
becoming yellow might be a zero in alpha becoming the blue channel,
ie. RGBA of 0xffffff00 getting switched around to 0xffff00ff
Is it the case if you make a white image with a gradient on the
alpha channel, the image displays as a yellow-to-white gradient?
> I want to use Pixmap and Bitmap (32bit)... It seems that somewhere the 4
> bytes (alpha-chanel included) are changed. Both pixmap and bitmap are
> shown in the wrong colors. But if i want to show white, it is yellow...
> For me that is a hint, that alphachanel is also exchanged with the
> color-bytes.
The code for Fl_Pixmap is in src/Fl_Pixmap.cxx
and the source for Fl_Bitmap is in src/Fl_Bitmap.cxx.
And these in turn may use one of the
draw() methods in any of src/Fl_Image.cxx,
fl_draw_image() methods in src/fl_draw_image*.cxx,
and/or the code in src/fl_draw_pixmap.cxx.
You can probably hack around the problem by inspecting
and reordering the RGBA bytes in ram after the image
is loaded by eg. Fl_Pixmap/Bitmap, eg:
http://fltk.org/articles.php?L466+I0+THow-To+P1+Qimage
http://seriss.com/people/erco/fltk/#Fl_Image
I'm not sure where exactly to correctly attack the problem,
the core folks can probably help more on that one.
Kinda depends on if the data being read off disk is
being saved into memory in the order expected (in which
case the image loaders are the point of the problem).
But, if the image data is correct in memory, but displayed
incorrectly, in which case the lower level functions
like fl_draw_image() might be the place to fix.
If it really is an issue of endian-ness, then possibly
the fix would be in the 'configure' script, where it
might be incorrectly detecting endianess. Or it might
not be endianess, but a graphics hardware specific issue
where bytes are 'twisted' as someone described in some kind
of 'unique' way.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
