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.
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).
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.
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
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.
On Wednesday 06 July 2005 7:59 pm, Frank Richter wrote:
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?
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.
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
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
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.
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
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.
"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 ----------
participants (5)
-
Alex Villacís Lasso -
Frank Richter -
Ge van Geldorp -
Kevin Koltzau -
Uwe Bonnes