Re: OpenGL in child windows
I have to ask, is there a reason each thread uses its own display connection (which are all different from gdi_display), and leaves the window data to only be available from the thread the window was created in? Besides the aforementioned problem with the GL context, I'd imagine it would be problematic even in current Wine.. for example, if something creates a window in one thread, passes it to another, then kills the thread it was originally created in while still using the window. In MS Windows, windows die if the creating thread exits for any reason.
Re: OpenGL in child windows
Wednesday January 10 2007 06:27、Chris Robinson さんは書きました: Here's something I've been working on for about the past week. It's my attempt to get OpenGL to render into an X11 child window that overlays the Win32 window. Your patches works perfectly! I have tested few applications with OpenGL windows and everything works perfectly. For better testing I have tested all Windows application I have including games to make sure there is no any regression. Everything works great including performance (i.e. I didn't find any bugs and 3D performance is as good as without patches). Well done! With luck, they can be gotten to a point soon where they can be rewritten properly to get into Wine. Hope so because it's very important to get this in main tree before 1.0 release. Now with your patchs all 3D professional software (which unusable because of OpenGL child windows in vanilla Wine) can work perfectly under Wine (Lightwave for example which has multiple OpenGL child windows works great).
Re: OpenGL in child windows
On 10.01.2007 07:27, Chris Robinson wrote: Beyond that, the only problem I can recall off-hand is that the OpenGL window will draw overtop of all Win32 windows that are sharing the same X11 parent window. Hmm, if OGL is displayed in its own child window, maybe it's possible to shape it so that overlapping Win32 child windows are excluded... -f.r.
Re: OpenGL in child windows
On Wednesday 10 January 2007 12:22, Frank Richter wrote: Hmm, if OGL is displayed in its own child window, maybe it's possible to shape it so that overlapping Win32 child windows are excluded... I'm not sure how to do that, given that the overlaps can cause the child window to have concave shapes that change when the user moves child windows around. One idea I had though, was to create another child window on the opengl child, and draw child windows that are above the opengl child to that (in addition to the base window), if it intersects. Would be harsh on performance, but ony when its intersecting. Another idea was to somehow put the opengl window behind the parent window, and draw some special colorkey to cut out the X11 window and show the OpenGL child underneath. Sort of like an Xv overlay. That way, when win32 windows draw on top of the win32 opengl child, the colorkey won't be applied, and the x11 child will be hidden. I'm just not sure if that's possible. Short of that, I've thought about using an actual Xv overlay, but I can't find anywhere to get a drawable to redirect OpenGL to. Seems the only way to draw to such an overlay is with XPutImage (and redirecting OpenGL to a pixmap has speed issues, in addition to updating issues).
Re: OpenGL as child windows
On 12/31/06, Chris Robinson [EMAIL PROTECTED] 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
Re: OpenGL as child windows
Damjan Jovanovic [EMAIL PROTECTED] 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.
Re: OpenGL as child windows
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).
Re: OpenGL as child windows
On Sunday December 31 2006 08:12, Damjan Jovanovic wrote: On 12/31/06, Chris Robinson [EMAIL PROTECTED] 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.
Re: OpenGL as child windows
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 -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
Re: OpenGL as child windows
Dmitry Timoshkov wrote: Damjan Jovanovic [EMAIL PROTECTED] 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
Re: OpenGL as child windows
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
Re: OpenGL as child windows
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 -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
Re: OpenGL as child windows
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.
