Re: opengl32: Correctly size and position opengl child windows
Hi, The plan is to get all the X-specific opengl code into winex11.drv and to get rid of things like ExtEscape. I also want to avoid using WineGLContext in opengl32.dll as I plan to change this too. A call like SyncCurrentDrawable should in the end be placed inside winex11.drv. I haven't looked into solutions to the window rendering bug. Based on old discussions solutions are to use pbuffers (but those are 'slow' compared to directly rendering to a window), FBOs, creation of a subwindow and the Scissors hack which you did. The scissors hack might work correctly for a number of programs but what do you plan to do with glReadPixels and friends? My work will first consist of routing some remaining wgl calls through gdi32 to winex11.drv. When that is done (which will hopefully be today or else this weekend) I want to get rid of ExtEscape calls and rewrite the WineGLContext code. There's no need for much win32-specific stuff inside winex11.drv Roderick
This patch override glViewport and glScissor to correctly position and size opengl child windows.
I've only tested this patch with Google Earth and Google Sketchup so I'd like to get some feedback to see if this solves the problem for your application.
Roderick: I realize you're currently reworking opengl32 so let me know if this conflicts with what you are doing.
Thanks,
/Ulrich
-- GMX DSL-Flatrate 0,- Euro* - Überall, wo DSL verfügbar ist! NEU: Jetzt bis zu 16.000 kBit/s! http://www.gmx.net/de/go/dsl
On Fri, Oct 06, 2006 at 01:30:43PM +0200, Roderick Colenbrander wrote:
Hi,
The plan is to get all the X-specific opengl code into winex11.drv and to get rid of things like ExtEscape. I also want to avoid using WineGLContext in opengl32.dll as I plan to change this too. A call like SyncCurrentDrawable should in the end be placed inside winex11.drv.
That mean we'll need to push all the internal_gl* calls into winex11.drv.
I haven't looked into solutions to the window rendering bug. Based on old discussions solutions are to use pbuffers (but those are 'slow' compared to directly rendering to a window), FBOs, creation of a subwindow and the Scissors hack which you did.
From our discussions at wineconf we concluded that overriding the various functions such as glViewport and glScissor will get us there for most applications. The only thing this will not do is handle the case where a child window overlaps a opengl child window. In this case the best solution is to use a glX extension that would allow us to provide a clip region to clip the overlapping child windows. The big question is this really necessary. How many applications make use of this? I don't know the answer.
The scissors hack might work correctly for a number of programs but what do you plan to do with glReadPixels and friends?
Like glViewport and glScissor these also need to be overridden to adjust the position and frame buffer bounds. /Ulrich
Am Freitag, 6. Oktober 2006 15:26 schrieb Ulrich Czekalla:
From our discussions at wineconf we concluded that overriding the various functions such as glViewport and glScissor will get us there for most applications.
The only thing this will not do is handle the case where a child window overlaps a opengl child window. In this case the best solution is to use a glX extension that would allow us to provide a clip region to clip the overlapping child windows. The big question is this really necessary. How many applications make use of this? I don't know the answer.
If I understand your question correctly, I'm sad to say that most applications using OpenGL viewports have overlapping child windows - especially pro applications/ content creation applications. You might want to try DAZ|Studio for reference, as it's freeware and shows what I mean. It's available at studio.daz3d.com. I'd test your patch myself, but OpenGL in Wine is completely broken for me for a few weeks now, and I have no idea how to fix it (D3D works just fine, though)... Ciao, Willie -- Willie Sippel //////// | Tritium Studios // | ______________________________ //// /// | http://www.tritium-studios.com <willie(a)froq.net>
Am Freitag, 6. Oktober 2006 15:26 schrieb Ulrich Czekalla:
From our discussions at wineconf we concluded that overriding the various functions such as glViewport and glScissor will get us there for most applications.
The only thing this will not do is handle the case where a child window overlaps a opengl child window. In this case the best solution is to use a glX extension that would allow us to provide a clip region to clip the overlapping child windows. The big question is this really necessary. How many applications make use of this? I don't know the answer.
If I understand your question correctly, I'm sad to say that most applications using OpenGL viewports have overlapping child windows - especially pro applications/ content creation applications. You might want to try DAZ|Studio for reference, as it's freeware and shows what I mean. It's available at studio.daz3d.com.
Right now nothing works well, so about everything is a step in the good direction. There's also another new way which might be a good option aswell next to the scissor one and that is to use the new GLX_EXT_texture_from_pixmap extension. Using it wine windows can be uploaded 'for free' to opengl. We can then do our opengl rendering on top of this texture. It is just a wild idea but perhaps it is usefull. 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
Am Freitag, 6. Oktober 2006 18:09 schrieb Willie Sippel:
Am Freitag, 6. Oktober 2006 15:26 schrieb Ulrich Czekalla:
From our discussions at wineconf we concluded that overriding the various functions such as glViewport and glScissor will get us there for most applications.
The only thing this will not do is handle the case where a child window overlaps a opengl child window. In this case the best solution is to use a glX extension that would allow us to provide a clip region to clip the overlapping child windows. The big question is this really necessary. How many applications make use of this? I don't know the answer.
I'd test your patch myself, but OpenGL in Wine is completely broken for me for a few weeks now, and I have no idea how to fix it (D3D works just fine, though)...
OK, just tested your patch with DAZ|Studio - quite an improvement! A few graphic glitches, like a disappearing menu bar (basically any part of the main window _except_ for the OpenGL viewport disappears randomly - you can still click on the buttons, but you can't see them). But I didn't notice any problems with floating (overlapping) child windows, they don't disappear and seem to work pretty much as expected!? It's a little sluggish, but I can't tell if that's due to your patch, or maybe DAZ|Studio really is that slow. Anyway, once the glitches I mentioned are sorted out and this patch gets committed, quite a few Wine users should be very happy! Ciao, Willie -- Willie Sippel //////// | Tritium Studios // | ______________________________ //// /// | http://www.tritium-studios.com <willie(a)froq.net>
participants (3)
-
Roderick Colenbrander -
Ulrich Czekalla -
Willie Sippel