On Tue, 14 Feb 2006 18:01:31 +0800, "Sheldon Gill"
<sheldon@westnet.net.au> said:
carmstrong _AT_ fastmail dot com dot au wrote:
Sheldon Gill wrote:
The problem isn't related to TIFF or any other file format. The problem isn't
really Windows, either. Its because of the way the backend is architected and
how it handles the image data. How to fix it is proving tricky.
May I ask how it handles image data that is known to cause the problem?
A couple of things here.
The AlphaBlend() function has a number of limitations, one of which is
source
information must be in 32-bits per pixel single plane, ARGB LE format.
The backend is writing to device dependent bitmaps so what happens to the
data
is up to the driver. Many don't support an alpha channel so it gets
quietly
dropped.
Also, since it's device dependent and you have to have 32-bits running in
16-bit or 24-bit mode ruins everything.
If I'm understanding what your saying correctly, is that GNUstep expects
the composite functions to blit from one part of the screen to another,
but expects them internally to be storing alpha channel data from when
they were first blitted? Or is it that when images are initially
blitted, the DPSimage function is ignoring alpha channel specifications.
One thing I have been looking at is how cairo handles this issue. They
have a post-script modelled backend running on Windows, and they use a
combination of the AlphaBlend and BitBlt functions, depending on the
situation. It seems to be related to 24bit bitmaps. Another thing worth
looking at is the GetDeviceCaps, although it could lie.