6 Jul
2005
6 Jul
'05
3:20 p.m.
Hi,
I have a bit of trouble with loading a 32bpp RGBA bitmap from a
resource. On Windows, using LoadImage() and LR_CREATEDIBSECTION the
alpha values stays the same; however, doing the same on Wine, the alpha
channel gets clobbered. I suspect it's the StretchDIBits() call, as
hacking around that by memcpy()ing the bitmap bits into the returned DIB
section makes it work... is memcpy()ing feasible?
I also checked StretchDIBits() (and BitBlt()), both preserve alpha when
blitting between 32bpp DIB sections... so maybe it's in order to add
alpha preservation to those functions?
-f.r.
6 Jul
6 Jul
6:23 p.m.
Frank Richter wrote:
Hi,
I have a bit of trouble with loading a 32bpp RGBA bitmap from a
resource. On Windows, using LoadImage() and LR_CREATEDIBSECTION the
alpha values stays the same; however, doing the same on Wine, the alpha
channel gets clobbered. I suspect it's the StretchDIBits() call, as
hacking around that by memcpy()ing the bitmap bits into the returned DIB
section makes it work... is memcpy()ing feasible?
I also checked StretchDIBits() (and BitBlt()), both preserve alpha when
blitting between 32bpp DIB sections... so maybe it's in order to add
alpha preservation to those functions?
-f.r.
Your problem sounds like one I am having for a long time with VB6
applications which use a toolbar: any icon with transparency gets its
transparency clobbered in Wine. Could you please send some sample code,
or else point to the source code of the app that is misbehaving? Maybe I
could fix the problem with a patch, as well as fixing my own problem too
(the part about pinpointing the root of the bug).
6:46 p.m.
On 06.07.2005 20:23, Alex Villacís Lasso wrote:
Your problem sounds like one I am having for a long
time with VB6
applications which use a toolbar: any icon with transparency gets its
transparency clobbered in Wine.
Hm... sure those VB6 apps use bitmaps with alpha?... AFAIK, 32bpp
bitmaps got "widespread" only after Windows XP and the fancy new UI
stuff. I'd assume that some typical VC6 app doesn't use any of the
fanciness...
Anyway, I stumbled upon the issue while tinkering with the theme code.
So to see the problem, you'd need a Windows XP theme that uses alpha
somewhere (e.g. the standard ones), a program utilizing themes (e.g.
"Theme Explorer"... I got it off the web some time ago, could mail it to
you) and some patches from me to have uxtheme use AlphaBlt() (which it
currently doesn't yet).
If that didn't scare you off, I can upload patches etc. somewhere. ;)
-f.r.
11:40 p.m.
On Wednesday 06 July 2005 11:20 am, Frank Richter wrote:
Hi,
I have a bit of trouble with loading a 32bpp RGBA bitmap from a
resource. On Windows, using LoadImage() and LR_CREATEDIBSECTION the
alpha values stays the same; however, doing the same on Wine, the alpha
channel gets clobbered. I suspect it's the StretchDIBits() call, as
hacking around that by memcpy()ing the bitmap bits into the returned DIB
section makes it work... is memcpy()ing feasible?
StrechDIBits is at fault, you´ll notice if you call that with the original
size of the bitmap (hence not stretching) it works as expected
If I remember correctly, its actually the XGetImage in
BITBLT_GetSrcAreaStretch that is causing this..but it´s been a while since I
looked into this issue
11:59 p.m.
On 07.07.2005 01:40, Kevin Koltzau wrote:
StrechDIBits is at fault, you´ll notice if you call
that with the original
size of the bitmap (hence not stretching) it works as expected
Hm, isn't that the case already here? LoadImage() is called without a
specific size, so the actual size of the bitmap should be used and no
stretching be done?
-f.r.
7 Jul
7 Jul
12:43 a.m.
On Wednesday 06 July 2005 7:59 pm, Frank Richter wrote:
On 07.07.2005 01:40, Kevin Koltzau wrote:
The stretching is happening when you try to paint, not when you load the
image.
As for stretching in uxtheme, the correct solution would actually be to use
AlphaBlend, which at the moment if you have a newish version of xrender will
stretch properly, as well as handle the alpha channel correctly.
If you change the StretchBlt call in UXTHEME_StretchBlt to AlphaBlend
everything should work properly.
The reason I didn´t do that as of yet is AlphaBlend will not draw at all if
you try to stretch and have an older version of xrender without
XRenderSetPictureTransform, there is no fallback currently.
StrechDIBits is at fault, you´ll notice if you
call that with the
original size of the bitmap (hence not stretching) it works as expected
Hm, isn't that the case already here? LoadImage() is called without a
specific size, so the actual size of the bitmap should be used and no
stretching be done?
11:06 a.m.
On 07.07.2005 02:43, Kevin Koltzau wrote:
The stretching is happening when you try to paint, not
when you load the
image.
As for stretching in uxtheme, the correct solution would actually be to use
AlphaBlend,
I did so in my working copy. I also removed the double-buffering stuff
from DrawThemeBackground(), ie I AlphaBlend() directly to the screen. I
also made a small test case; the alpha is already missing from the
bitmap returned from LoadImage() - the blitting there already clobbers
the alpha channel for me.
-f.r
1:21 p.m.
On Thursday 07 July 2005 7:06 am, Frank Richter wrote:
I did so in my working copy. I also removed the
double-buffering stuff
from DrawThemeBackground(), ie I AlphaBlend() directly to the screen. I
also made a small test case; the alpha is already missing from the
bitmap returned from LoadImage() - the blitting there already clobbers
the alpha channel for me.
The problem I think is when the image is put into an XImage, then copied back
out it looses the alpha, so using GetPixel to verify will have the same
problem (it just returns XGetPixel). StretchBlt also does this, but
AlphaBlend does not as its using XRenderSetPictureTransform to stretch
2:06 p.m.
On 07.07.2005 15:21, Kevin Koltzau wrote:
The problem I think is when the image is put into an
XImage, then copied back
out it looses the alpha, so using GetPixel to verify will have the same
problem (it just returns XGetPixel). StretchBlt also does this, but
AlphaBlend does not as its using XRenderSetPictureTransform to stretch
Hm... is there a way to make the *Blt() functions preserve alpha (as
they should)? This message:
http://lists.freedesktop.org/archives/cairo/2003-December/000900.html
seems to suggest that 32bpp XImages seem to be possible, but then, I
hardly know X or how Wine interacts with it...
-f.r.
3:56 p.m.
On Thursday 07 July 2005 10:06 am, Frank Richter wrote:
Hm... is there a way to make the *Blt() functions
preserve alpha (as
they should)? This message:
http://lists.freedesktop.org/archives/cairo/2003-December/000900.html
seems to suggest that 32bpp XImages seem to be possible, but then, I
hardly know X or how Wine interacts with it...
32bpp XImages are absolutely possible..creating them and drawing them (with
BitBlt for example) is fine, the problem is when you try to pull data back
out of the XImage
The solution IMO is to use a real DIB engine
8 Jul
8 Jul
9:32 a.m.
From: Kevin Koltzau
The solution IMO is to use a real DIB engine
Since ReactOS never had the benefit of being able to use X11 functions,
we've already done a lot of work on a DIB engine. As with just about
everything in ReactOS, it is not complete yet. However, often-used stuff
like BitBlt is fully supported, just don't expect Bezier curves drawn with a
3 pixel wide pen using a PATPAINT rop to work.
Recently we've added a code generator which generates pretty fast code for
BitBlt operations. At the moment, it only works for 16bpp destinations, but
I expect to add the other depths very soon. Timing tests show that this code
is significantly faster than the XP non-hardware-accellerated code.
It will take some effort to port this to Wine, since the internal
datastructures used are different (we're bound by the DDK engine types like
SURFOBJ). If there is interest in this from the Wine side, I'd be happy to
provide assistance.
Ge van Geldorp.
9:12 p.m.
>>>> "Ge" == Ge van Geldorp
<gvg(a)reactos.com> writes:
> From: Kevin Koltzau
>
> The solution IMO is to use a real DIB engine
Ge> Since ReactOS never had the benefit of being able to use X11
Ge> functions, we've already done a lot of work on a DIB engine. As with
Ge> just about everything in ReactOS, it is not complete yet. However,
Ge> often-used stuff like BitBlt is fully supported, just don't expect
Ge> Bezier curves drawn with a 3 pixel wide pen using a PATPAINT rop to
Ge> work.
Ge> Recently we've added a code generator which generates pretty fast
Ge> code for BitBlt operations. At the moment, it only works for 16bpp
Ge> destinations, but I expect to add the other depths very soon. Timing
Ge> tests show that this code is significantly faster than the XP
Ge> non-hardware-accellerated code.
Ge> It will take some effort to port this to Wine, since the internal
Ge> datastructures used are different (we're bound by the DDK engine
Ge> types like SURFOBJ). If there is interest in this from the Wine
Ge> side, I'd be happy to provide assistance.
Please do so.
I will be happy to test.
--
Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
6893
days inactive
6895
days old
11 comments
5 participants
participants (5)
-
Alex Villacís Lasso -
Frank Richter -
Ge van Geldorp -
Kevin Koltzau -
Uwe Bonnes