discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Update: Windows, GMastermind2


From: Sheldon Gill
Subject: Re: Update: Windows, GMastermind2
Date: Wed, 15 Feb 2006 08:51:45 +0800
User-agent: Thunderbird 1.5 (Windows/20051201)

Christopher Armstrong wrote:
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.

It's that the backend was expecting the alpha data from the previous blit to still be around.

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.

I haven't looked at cairo on Windows at all.

GetDeviceCaps() isn't helpful in this situation at all. All it will report is if the display driver offers acceleration for source constant alpha and/or per pixel alpha.


Regards,
Sheldon




reply via email to

[Prev in Thread] Current Thread [Next in Thread]