glReadPixels() alpha issue over Remote Desktop

I am running WPF on Windows 7(tried it with both WDM/Aero switched on and off) with OpenGL for rendering. To prevent OpenGL airspace issues I render to the windows-generated-application backbuffer and read back the pixels by glReadPixels() which works great and I can have WPF and OpenGL on top/below/between each other.
However on remote desktop(running 32 bit with WDM/Aero turned on and off) glReadPixels returns pixels with all of its alpha channels as 255. This causes ‘airspace’ again and is no go. Not too many posts about this online and all “solutions” point to using a custom FBO, but Windows falls back to OpenGL 1.1 far far away from FBO extensions.
Here is a pseudo code.


byte[] readColor = new byte[(int)ActualWidth * (int)ActualHeight * 4];
GL.ClearColor(0f, 0f, 0f, 0.0f);
GL.Clear(ClearBufferMask.ColorBufferBit);
GL.Viewport(0, 0, (int)ActualWidth, (int)ActualHeight);
GL.LoadIdentity();
GL.Color4(_r, _g, _b, .5f);
//render stuff
GL.Finish();
GL.ReadPixels(0, 0, (int)ActualWidth, (int)ActualHeight, PixelFormat.Bgra, PixelType.UnsignedByte, readColor);

readColor in this case is filled with alpha values of 255 in remote desktop mode. The only explanation I have is the pixel format, but I am running 32 bit colors when on Microsoft’s Remote Desktop.

I have the pixel format with 32 bits color. 16 bits depth. 0 stencil. 0 accumulation. Supports Draw to Window, Supports OpenGL and Double Buffering.

Any idea what is going on here?

Have you explicitly requested 8 alpha bits on context creation? What do you get if you query GL_ALPHA_BITS?

There is the possibility that RDP (remote desktop protocol), being a presentation layer protocol, does not actually bring back to the host comupter all 32-bits of the remote desktop.
RDP will try and compress what it can (there are options on the connection to compress Bitmaps, etc) so who knows - perhaps Microsoft have programmed RDP to fetch 24-bit RGB and ignore alpha as traditionally it was never used on a Windows desktp anyway.

I did request 8 alpha bits, yes. Here is what my pixel format looks like.


static	PIXELFORMATDESCRIPTOR pfd=			
{
sizeof(PIXELFORMATDESCRIPTOR),					
1,
PFD_DRAW_TO_WINDOW |
PFD_SUPPORT_OPENGL |
PFD_DOUBLEBUFFER,
PFD_TYPE_RGBA,								
32,										
0, 0, 0, 0, 0, 0,			
8,			//alpha bits		
0,					
0,					
0, 0, 0, 0,				
16,                      //depth
0,											
0,										
PFD_MAIN_PLANE,
0,							
0, 0, 0										
};

I am not really using depth or accumulation(yet). And glGetIntegerv for the alpha bits returns 8.
@BionicBytes
RDP with all the settings maxed out(persistent bitmap caching, desktop composition) does work with aero! if aero/WDM is enabled on the server machine.

Microsoft don’t like OpenGL. I would not be surprised if mixing D3D and WPF over RDP works fine.

It doesn’t matter how many bits you request; the implementation is free to give you a closest match pixel format that may or may not include alpha bits. You need to use DescribePixelFormat after to validate that what you’ve got is what you actually asked for.

You may be correct on that, from MSDN Microsoft Learn: Build skills that open doors in your career
“You must ensure that the pixel format matched by the ChoosePixelFormat function satisfies your requirements. For example, if you request a pixel format with a 24-bit RGB color buffer but the device context offers only 8-bit RGB color buffers, the function returns a pixel format with an 8-bit RGB color buffer.”

I wonder how many people bother to check.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.