The topic of getting OpenGL to show and use more visuals/pixel formats than just the one the main window uses came up on IRC, and I was told to make a post here. One of the ideas was to create a child window of the main X window (which can be given a different visual) and have OpenGL use that for drawing.
A simple test program I wrote (using X) seems to behave well. The child window stays relative to the parent, it remains fully connected (even with the wobbly effects of compositors like Beryl), and it can use a different visual. Since wgl is now a part of x11drv, it should be possible to make an X11 child window. Are there any problems with using this approach in Wine?
On 12/31/06, Chris Robinson chris.kcat@gmail.com wrote:
The topic of getting OpenGL to show and use more visuals/pixel formats than just the one the main window uses came up on IRC, and I was told to make a post here. One of the ideas was to create a child window of the main X window (which can be given a different visual) and have OpenGL use that for drawing.
A simple test program I wrote (using X) seems to behave well. The child window stays relative to the parent, it remains fully connected (even with the wobbly effects of compositors like Beryl), and it can use a different visual. Since wgl is now a part of x11drv, it should be possible to make an X11 child window. Are there any problems with using this approach in Wine?
AFAIK there is no technical problems, only political ones. Wine no longer allows subwindows to be X11 windows. I've heard Alexandre Julliard won't accept such patches.
Damjan
"Damjan Jovanovic" damjan.jov@gmail.com wrote:
AFAIK there is no technical problems, only political ones. Wine no longer allows subwindows to be X11 windows. I've heard Alexandre Julliard won't accept such patches.
That was a purely technical decision to get rid of X windows for child Win32 windows, and has fixed numerous painting and z-order related problems. If you or somebody else are really interested to go backwards, show us the code which cleanly passes 'make test' in dlls/user32 and simultaneously solves the problem for OpenGL child windows.
Dmitry Timoshkov wrote:
"Damjan Jovanovic" damjan.jov@gmail.com wrote:
AFAIK there is no technical problems, only political ones. Wine no longer allows subwindows to be X11 windows. I've heard Alexandre Julliard won't accept such patches.
That was a purely technical decision to get rid of X windows for child Win32 windows, and has fixed numerous painting and z-order related problems. If you or somebody else are really interested to go backwards, show us the code which cleanly passes 'make test' in dlls/user32 and simultaneously solves the problem for OpenGL child windows.
I'm not so sure that openGL windows behave the same way as GDI. Even native has lots of visual glitches with that. Some one said they act like an overlays - which might be true. In either case, what would stop us from at least considering this as a valid option limited to openGL only?
Another BTW I have not seen a single test in user32 that involves openGL.
Vitaliy
On Sunday 31 December 2006 00:12, you wrote:
AFAIK there is no technical problems, only political ones. Wine no longer allows subwindows to be X11 windows. I've heard Alexandre Julliard won't accept such patches.
These wouldn't be Win32 subwindows as X11 child windows (as I heard Wine doesn't do), but rather, a child window of the main window used solely for showing OpenGL on. I can't, in my admittedly limited knowledge, think of why it wouldn't work, and it should also help clear the problem Wine has with Win32 child windows using OpenGL since they'd implicitly clip to the child window extents, instead of trying to hack the scissors test. The X11 child window for OpenGL would be completely transparent to the app (as in, opengl wouldn't announce its existance, and the rest of the code wouldn't care about it).
On Sunday 31 December 2006 00:12, you wrote:
AFAIK there is no technical problems, only political ones. Wine no longer allows subwindows to be X11 windows. I've heard Alexandre Julliard won't accept such patches.
These wouldn't be Win32 subwindows as X11 child windows (as I heard Wine doesn't do), but rather, a child window of the main window used solely for showing OpenGL on. I can't, in my admittedly limited knowledge, think of why it wouldn't work, and it should also help clear the problem Wine has with Win32 child windows using OpenGL since they'd implicitly clip to the child window extents, instead of trying to hack the scissors test. The X11 child window for OpenGL would be completely transparent to the app (as in, opengl wouldn't announce its existance, and the rest of the code wouldn't care about it).
The subwindow would be created from within the opengl code (e.g. wglCreateContext / SetPixelFormat). That is where it happens on Windows too and on Windows OpenGL also uses some sort of overlay.
Roderick
These wouldn't be Win32 subwindows as X11 child windows (as I heard Wine doesn't do), but rather, a child window of the main window used solely for showing OpenGL on. I can't, in my admittedly limited knowledge, think of why it wouldn't work, and it should also help clear the problem Wine has with Win32 child windows using OpenGL since they'd implicitly clip to the child window extents, instead of trying to hack the scissors test. The X11 child window for OpenGL would be completely transparent to the app (as in, opengl wouldn't announce its existance, and the rest of the code wouldn't care about it).
Just wondered what would happen in the case of a non-X11 child window partially overlapping an X11 OpenGL window? I guess this wouldn't work still even with this solution. This could happen quite easily in an MDI situation.
Mark
These wouldn't be Win32 subwindows as X11 child windows (as I heard Wine doesn't do), but rather, a child window of the main window used solely
for
showing OpenGL on. I can't, in my admittedly limited knowledge, think of why it wouldn't work, and it should also help clear the problem Wine has
with
Win32 child windows using OpenGL since they'd implicitly clip to the
child
window extents, instead of trying to hack the scissors test. The X11
child
window for OpenGL would be completely transparent to the app (as in, opengl wouldn't announce its existance, and the rest of the code wouldn't care about it).
Just wondered what would happen in the case of a non-X11 child window partially overlapping an X11 OpenGL window? I guess this wouldn't work still even with this solution. This could happen quite easily in an MDI situation.
Mark
That would indeed be a problem. You could perhaps force that part to share the child window though that would cause other issues again.
I'm not sure what pixel formats MDI apps in general use but perhaps they might need specific pixelformats for instance ones with the cap 'PFD_GDI_SUPPORT' to allow gdi rendering. If that's the case we just hide the GDI support cap and add a pixelformat with that cap set. When that pixelformat is used the current opengl behavior could be used. (Assuming our glScissors code would work correctly, this would get MDI running)
Regards, Roderick
On Sunday 31 December 2006 11:44, Mark Hatsell wrote:
Just wondered what would happen in the case of a non-X11 child window partially overlapping an X11 OpenGL window? I guess this wouldn't work still even with this solution. This could happen quite easily in an MDI situation.
I suppose the OpenGL window would overlap the non-X11 child window. But such a thing does not work now, nor will it ever as long as OpenGL draws directly to the main window. But this would only be an issue when the actual OpenGL window area is overlapped by something from the same parent window (a seperate popup MessageBox, for example, would still work fine). And even in Windows, OpenGL windows have problems when overlapped with other child windows.
On Sunday December 31 2006 08:12, Damjan Jovanovic wrote:
On 12/31/06, Chris Robinson chris.kcat@gmail.com wrote:
The topic of getting OpenGL to show and use more visuals/pixel formats than just the one the main window uses came up on IRC, and I was told to make a post here. One of the ideas was to create a child window of the main X window (which can be given a different visual) and have OpenGL use that for drawing.
A simple test program I wrote (using X) seems to behave well. The child window stays relative to the parent, it remains fully connected (even with the wobbly effects of compositors like Beryl), and it can use a different visual. Since wgl is now a part of x11drv, it should be possible to make an X11 child window. Are there any problems with using this approach in Wine?
AFAIK there is no technical problems, only political ones. Wine no longer allows subwindows to be X11 windows. I've heard Alexandre Julliard won't accept such patches.
Why not? There is no harm to create X11 subwindows for OpenGL windows. Also this is only real and correct solution (without performance penalties) for this problem and this is how all Linux programs with OpenGL child windows works (GoogleEarth for Linux for example which has same interface as in its Windows version). At least I do not know any good solution of this problem without creating X11 subwindow.
-
Chris Robinson -
Damjan Jovanovic -
Dmitry Timoshkov -
L. Rahyen -
Mark Hatsell -
Roderick Colenbrander -
Vitaliy Margolen