Hi everybody,
I am trying to run a pretty complex dotnet (3.5) app which renders flash contents via flash in a box http://www.f-in-box.com/
I have to say that congratulations are in order to everybody involved because the whole thing works remarkably well for such a complex amalgam of technologies and platforms.
The problem I am trying to debug right now is that transparent windows comes out black in wine. So the question is: 1) What are the wine debug channels I have to turn on in order to understand what's happening? 2) Any ideas where the code responsible might be located (gdi, user32, wineserver)? 2a) Is it some window creation flag responsible for this? 2b) Is it X-Window dependent? Does it require OpenGL and 3D effects enabled?
Thanks in advance
.bill
It is probably a layered window, in which case the following functions in user32 are relevant: SetLayeredWindowAttributes, GetLayeredWindowAttributes, UpdateLayeredWindowIndirect, and UpdateLayeredWindow
Most of user32 is implemented based on gdi32, wineserver, and winex11.drv. When you see USER_Driver in user32, that indicates a function in winex11.drv. So USER_Driver->pSetLayeredWindowAttributes is really X11DRV_SetLayeredWindowAttributes.
Wine requires a compositing window manager to implement layered windows properly. It does not matter whether the window manager provides any 3D effects or uses opengl.
On 02/11/2010 02:12 πμ, Vincent Povirk wrote:
It is probably a layered window, in which case the following functions in user32 are relevant: SetLayeredWindowAttributes, GetLayeredWindowAttributes, UpdateLayeredWindowIndirect, and UpdateLayeredWindow
Most of user32 is implemented based on gdi32, wineserver, and winex11.drv. When you see USER_Driver in user32, that indicates a function in winex11.drv. So USER_Driver->pSetLayeredWindowAttributes is really X11DRV_SetLayeredWindowAttributes.
Wine requires a compositing window manager to implement layered windows properly. It does not matter whether the window manager provides any 3D effects or uses opengl.
Thank you very much for the directions. They certainly put me on the right track.
WINEDEBUG=+win does the trick and shows relevant information.
My application still displays black instead of transparent. I took the liberty and augment the trace message with the BLENDFUNCTION struct members like this --- a/dlls/user32/win.c +++ b/dlls/user32/win.c @@ -3531,7 +3531,7 @@ BOOL WINAPI UpdateLayeredWindowIndirect( HWND hwnd, const UPDATELAYEREDWINDOWINF }
if (info->pblend && !(info->dwFlags & ULW_OPAQUE)) alpha = info->pblend->SourceConstantAlpha; - TRACE( "setting window %p alpha %u\n", hwnd, alpha ); + TRACE( "setting window %p alpha %u BlendOp %u, BlendFlags %x SourceConstantAlpha %u AlphaFormat %x \n", hwnd, alpha, info->pblend->BlendOp, info->pblend->BlendFlags, info->pblend->SourceConstantAlpha, info->pblend->AlphaFormat); USER_Driver->pSetLayeredWindowAttributes( hwnd, info->crKey, alpha, info->dwFlags & (LWA_ALPHA | LWA_COLORKEY) ); return TRUE;
and I got output like this
trace:win:UpdateLayeredWindowIndirect setting window 0x10060 alpha 255 BlendOp 0, BlendFlags 0 SourceConstantAlpha 255 AlphaFormat 1
The BLENDFUNCTION structure is documented in MSDN http://msdn.microsoft.com/en-us/library/dd183393%28VS.85%29.aspx and is defined in include/wingdi.h
So from MSDN BlendOp = 0 == AC_SRC_OVER (the only option) BlendFlags = 0 (the only option) SourceConstantAlpha = 255 = 0xff AlphaFormat = 1 == AC_SRC_ALPHA (the only option)
then the documentation branches depending on if the SourceConstantAlpha is 0xff or not, if there is source alpha if there is destination alpha.
Just to be sure I hardcoded another value for SourceConstantAlpha and I did get some kind of transparency but not the right kind :-(
Is it possible that wine's implementation has a bug in the alpha blending handling in some subcase?
It is late now. I will hunt it down some more tomorrow.
.bill
On 03/11/2010 12:36 πμ, Vassilis Virvilis wrote:
On 02/11/2010 02:12 πμ, Vincent Povirk wrote:
It is probably a layered window, in which case the following functions in user32 are relevant: SetLayeredWindowAttributes, GetLayeredWindowAttributes, UpdateLayeredWindowIndirect, and UpdateLayeredWindow
Most of user32 is implemented based on gdi32, wineserver, and winex11.drv. When you see USER_Driver in user32, that indicates a function in winex11.drv. So USER_Driver->pSetLayeredWindowAttributes is really X11DRV_SetLayeredWindowAttributes.
Wine requires a compositing window manager to implement layered windows properly. It does not matter whether the window manager provides any 3D effects or uses opengl.
Thank you very much for the directions. They certainly put me on the right track.
Again thanks for the directions.
The UpdateLayeredWindowIndirect implementation of wine only utilizes a global per window alpha value.
After a little bit of research it looks like what I want is something called per-pixel alpha or per color alpha or blending with alpha channel.
Does wine and/or X-Windows support something like this and if so where?
My guess is in bitblit but any insightful comment is welcome.
.bill
2010/11/4 Vassilis Virvilis vasvir@iit.demokritos.gr:
On 03/11/2010 12:36 πμ, Vassilis Virvilis wrote:
[...]
Aain thanks for the directions.
The UpdateLayeredWindowIndirect implementation of wine only utilizes a global per window alpha value.
After a little bit of research it looks like what I want is something called per-pixel alpha or per color alpha or blending with alpha channel.
Does wine and/or X-Windows support something like this and if so where?
My guess is in bitblit but any insightful comment is welcome.
.bill
As much as I know XRender or Compositing Window Manager can be used for alpha blending.
On Thu, Nov 4, 2010 at 3:08 AM, Vassilis Virvilis vasvir@iit.demokritos.gr wrote:
On 03/11/2010 12:36 πμ, Vassilis Virvilis wrote:
On 02/11/2010 02:12 πμ, Vincent Povirk wrote:
It is probably a layered window, in which case the following functions in user32 are relevant: SetLayeredWindowAttributes, GetLayeredWindowAttributes, UpdateLayeredWindowIndirect, and UpdateLayeredWindow
Most of user32 is implemented based on gdi32, wineserver, and winex11.drv. When you see USER_Driver in user32, that indicates a function in winex11.drv. So USER_Driver->pSetLayeredWindowAttributes is really X11DRV_SetLayeredWindowAttributes.
Wine requires a compositing window manager to implement layered windows properly. It does not matter whether the window manager provides any 3D effects or uses opengl.
Thank you very much for the directions. They certainly put me on the right track.
Again thanks for the directions.
The UpdateLayeredWindowIndirect implementation of wine only utilizes a global per window alpha value.
After a little bit of research it looks like what I want is something called per-pixel alpha or per color alpha or blending with alpha channel.
Does wine and/or X-Windows support something like this and if so where?
My guess is in bitblit but any insightful comment is welcome.
.bill
You would require ARGB visuals. Various drivers support them these days for desktop composition purposes. When I asked Alexandre about them a long time ago, he said we couldn't use them in Wine. I don't know why that was. Further even if we could use it, we would have to recreate the window upon this call since I don't think we would want to use ARGB by default.
Roderick
On 04/11/2010 05:07 μμ, Roderick Colenbrander wrote:
You would require ARGB visuals. Various drivers support them these days for desktop composition purposes. When I asked Alexandre about them a long time ago, he said we couldn't use them in Wine. I don't know why that was. Further even if we could use it, we would have to recreate the window upon this call since I don't think we would want to use ARGB by default.
Thanks for the info. I wasn't aware of the proper terms (ARGB visual) to google properly.
Is it possible to destroy and recreate a window under an application's nose without noticing during the call to UpdateLayeredWindowIndirect() and friends?
Is there any other part of wine that is pulling such a trick (underlying window recreation)?
And if we do that then the next stop is bitblt in order to implement the proper blending behaviour. Is that correct?
May I ask about input transparency? Does X support that at all?
.bill
-
Ozan Türkyılmaz -
Roderick Colenbrander -
Vassilis Virvilis -
Vincent Povirk