bug 2398: OpenGL, child windows, and wine
The change back in January or so to no longer give each window its own x window seems to have caused an upheaval in the opengl world. The first app to report a problem was Lightwave 3D: http://bugs.winehq.org/show_bug.cgi?id=2398 followed by http://bugs.winehq.org/show_bug.cgi?id=2908 WeatherScope (free) http://bugs.winehq.org/show_bug.cgi?id=3083 Google Earth (free) http://bugs.winehq.org/show_bug.cgi?id=3400 Quake3 Radiant http://bugs.winehq.org/show_bug.cgi?id=3583 Moray 3.5 (free) I've taken the liberty of marking the latter four bugs as duplicates of 2398, reopening 2398, and targeting it to be fixed for Wine 1.0. Willie Sippel's comment, http://bugs.winehq.org/show_bug.cgi?id=2398#c41, seems to point the way to a fix; he suggests using the new GL_EXT_framebuffer_object OpenGL extension. I checked around a bit, and it appears to be at least partly supported by the latest NVidia and ATI drivers. Sun's starting to use it in Java, too; see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6255507 A workaround is probably also possible without that OpenGL extension, but it would probably run slower. I'm tempted to say skip the workaround, at least for the first pass, and just implement the real fix using the opengl extension. As Sippel said, people who use apps like Lightwave (and maybe Quake3 Radiant :-) tend to have the latest 3d hardware and drivers anyway. What do other people think? Has anybody started looking at fixing this yet? Thanks, Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
Hello, Dan Kegel wrote:
he suggests using the new GL_EXT_framebuffer_object OpenGL extension. I checked around a bit, and it appears to be at least partly supported by the latest NVidia and ATI drivers.
I'm tempted to say skip the workaround, at least for the first pass, and just implement the real fix using the opengl extension. As Sippel said, people who use apps like Lightwave (and maybe Quake3 Radiant :-) tend to have the latest 3d hardware and drivers anyway.
I want to point out that there are other applications like my Diamond (bug 2315, duplicate of 2320; Diamond is a crystal structure viewer), which are definitly also run on weaker hardware. And at least a glxinfo |grep -i GL_EXT_frame does not return anything on my Laptop ("IBM (ATI Radeon) RV250 Lf"). Maybe some solution which works on both high-end systems and on a bit older systems would be useful. (Implementing maybe conditionally GL_EXT_framebuffer_object and the work around?) Tobias PS: Diamond screen shots: http://www.crystalimpact.com/diamond/ (Windows w/ openGL) http://appdb.winehq.org/screenshots.php?appId=1307&versionId= (Wine, no openGL)
On Tue, Oct 18, 2005 at 12:08:04AM -0700, Dan Kegel wrote:
I'm tempted to say skip the workaround, at least for the first pass, and just implement the real fix using the opengl extension. As Sippel said, people who use apps like Lightwave (and maybe Quake3 Radiant :-) tend to have the latest 3d hardware and drivers anyway.
I would tend to do the reverse. First code what works on all cards / drivers (that would be pbuffers which are pretty much supported on all cards that I know of) and then only code the 'fast path' if any.
What do other people think? Has anybody started looking at fixing this yet?
I am aware of the issue since WineConf 2004 but never had the time / motivation / knowledge to fix it. Lionel -- Lionel Ulmer - http://www.bbrox.org/
--- Lionel Ulmer <lionel.ulmer(a)free.fr> wrote:
On Tue, Oct 18, 2005 at 12:08:04AM -0700, Dan Kegel wrote:
I'm tempted to say skip the workaround, at least for the first pass, and just implement the real fix using the opengl extension. As Sippel said, people who use apps like Lightwave (and maybe Quake3 Radiant :-) tend to have the latest 3d hardware and drivers anyway.
I would tend to do the reverse. First code what works on all cards / drivers (that would be pbuffers which are pretty much supported on all cards that I know of) and then only code the 'fast path' if any.
What do other people think? Has anybody started looking at fixing this yet?
I am aware of the issue since WineConf 2004 but never had the time / motivation / knowledge to fix it.
Huw has done some work on this using pbuffers but I'm not sure how far he's got. Oliver.
Lionel
-- Lionel Ulmer - http://www.bbrox.org/
___________________________________________________________ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
Huw has done some work on this using pbuffers but I'm not sure how far he's got.
I thought it was GLXPixmaps seeing the patch he submitted to wine-cvs :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Lionel Ulmer wrote:
Huw has done some work on this using pbuffers but I'm not sure how far he's got.
I thought it was GLXPixmaps seeing the patch he submitted to wine-cvs :-)
Which patch is that? I couldn't find it... -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
Which patch is that? I couldn't find it...
* dlls/x11drv/bitmap.c, dlls/x11drv/init.c, dlls/x11drv/opengl.c, dlls/x11drv/x11drv.h: Huw Davies <huw(a)codeweavers.com> Add an x11drv escape that returns a glx drawable. At the time the patch was submitted I was (and I am still :-) ) intrigued about the use case for this patch. Lionel -- Lionel Ulmer - http://www.bbrox.org/
On Wed, Oct 19, 2005 at 11:13:03PM +0200, Lionel Ulmer wrote:
Which patch is that? I couldn't find it...
* dlls/x11drv/bitmap.c, dlls/x11drv/init.c, dlls/x11drv/opengl.c, dlls/x11drv/x11drv.h: Huw Davies <huw(a)codeweavers.com> Add an x11drv escape that returns a glx drawable.
At the time the patch was submitted I was (and I am still :-) ) intrigued about the use case for this patch.
It's going to be used to enable OpenGL to draw on dibsections (ie PFD_DRAW_TO_BITMAP). The deal is that while you can use a Window as a glx drawable you can't use a Pixmap, so the old drawable Escape wasn't sufficient. There are some more bits to come, but they'll have to wait until after 0.9. Huw.
On Wed, Oct 19, 2005 at 10:24:32PM +0100, Huw D M Davies wrote:
It's going to be used to enable OpenGL to draw on dibsections (ie PFD_DRAW_TO_BITMAP). The deal is that while you can use a Window as a glx drawable you can't use a Pixmap, so the old drawable Escape wasn't sufficient. There are some more bits to come, but they'll have to wait until after 0.9.
I hesitated between the two possilibites (but one could imagine that once we get GL rendering to DIBs, the poor's man fix for the GL windowed problem would be to create DIBs for each GL 'subwindow' and then just BitBlt the DIB onto the screen - with Wine handling clipping - each time it is necessary)... Probably slow (as I doubt that GLXPixmaps are using any direct rendering) but workable. Anyway, it will be nice be able to have Civ3 running without it complaining about 'unhandled pixel format flag' :-) Lionel PS: thanks for the update, always wanted to ask you on IRC about this patch but always forgot it :-) -- Lionel Ulmer - http://www.bbrox.org/
On Wed, Oct 19, 2005 at 11:31:07PM +0200, Lionel Ulmer wrote:
On Wed, Oct 19, 2005 at 10:24:32PM +0100, Huw D M Davies wrote:
It's going to be used to enable OpenGL to draw on dibsections (ie PFD_DRAW_TO_BITMAP). The deal is that while you can use a Window as a glx drawable you can't use a Pixmap, so the old drawable Escape wasn't sufficient. There are some more bits to come, but they'll have to wait until after 0.9.
I hesitated between the two possilibites (but one could imagine that once we get GL rendering to DIBs, the poor's man fix for the GL windowed problem would be to create DIBs for each GL 'subwindow' and then just BitBlt the DIB onto the screen - with Wine handling clipping - each time it is necessary)... Probably slow (as I doubt that GLXPixmaps are using any direct rendering) but workable.
Yeah, this is for a customer of ours who has the OpenGL in child windows problem. The easiest way around this was to get them to modify their code to draw onto dibsections and blit to the window. Then all we needed to do was to implement the OpenGL on dibsection bit.
Anyway, it will be nice be able to have Civ3 running without it complaining about 'unhandled pixel format flag' :-)
That's what /dev/null is for ;-) Huw.
Yeah, this is for a customer of ours who has the OpenGL in child windows problem. The easiest way around this was to get them to modify their code to draw onto dibsections and blit to the window. Then all we needed to do was to implement the OpenGL on dibsection bit.
Ah I understand now. Do you know when the 'in DIB section' patch will be sent to wine-patches (maybe after the 0.9 freeze) ? I think once this is in, I will try (for fun) to see if I can get a hacked version of wgl.c together which uses DIB for the 'in window' rendering part. It would only handle 'back buffer' rendering (i.e. the DIB flushing would be done on the swap buffer call) but it could be a temporary solution waiting for a real OpenGL guru (i.e. not me) to fix using funky extensions :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
On 10/20/05, Lionel Ulmer <lionel.ulmer(a)free.fr> wrote:
Ah I understand now. Do you know when the 'in DIB section' patch will be sent to wine-patches (maybe after the 0.9 freeze) ?
I think once this is in, I will try (for fun) to see if I can get a hacked version of wgl.c together which uses DIB for the 'in window' rendering part. It would only handle 'back buffer' rendering (i.e. the DIB flushing would be done on the swap buffer call) but it could be a temporary solution waiting for a real OpenGL guru (i.e. not me) to fix using funky extensions :-)
Oh, man, don't tease me! I'm looking forward to testing your hack someday. - Dan
On Thu, Oct 20, 2005 at 08:25:42PM +0200, Lionel Ulmer wrote:
Ah I understand now. Do you know when the 'in DIB section' patch will be sent to wine-patches (maybe after the 0.9 freeze) ?
Ok, here's a patch for fun. It has one really nasty hack that needs to be sorted out - that's how to keep the dib section pixmap and bits in sync during opengl calls. We probably need to bracket all opengl calls with the equivalent of x11drv's X11DRV_{Lock,Unlock}DIBSection, presumably exposed by another x11drv escape. For now I just coerce the dib section into the correct state whenever opengl.dll asks for a glx drawable. This will work fine unless somebody starts fiddling with the bits of the dibsection, in which case the thing will just go out of sync. If anybody has any ideas on this then please let me know. Huw. -- Huw Davies huw(a)codeweavers.com ? dlls/opengl32/opengl32.dll.dbg.c Index: dlls/x11drv/init.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/init.c,v retrieving revision 1.22 diff -u -p -r1.22 init.c --- dlls/x11drv/init.c 26 Sep 2005 11:04:12 -0000 1.22 +++ dlls/x11drv/init.c 21 Oct 2005 10:39:55 -0000 @@ -415,6 +415,7 @@ INT X11DRV_ExtEscape( X11DRV_PDEVICE *ph if(!physDev->bitmap->glxpixmap) physDev->bitmap->glxpixmap = create_glxpixmap(physDev); + X11DRV_CoerceDIBSection(physDev, DIB_Status_GdiMod, FALSE); *(Drawable *)out_data = physDev->bitmap->glxpixmap; } else Index: dlls/opengl32/wgl.c =================================================================== RCS file: /home/wine/wine/dlls/opengl32/wgl.c,v retrieving revision 1.64 diff -u -p -r1.64 wgl.c --- dlls/opengl32/wgl.c 25 Sep 2005 15:23:21 -0000 1.64 +++ dlls/opengl32/wgl.c 21 Oct 2005 10:39:56 -0000 @@ -43,9 +43,15 @@ WINE_DEFAULT_DEBUG_CHANNEL(opengl); #define X11DRV_ESCAPE 6789 enum x11drv_escape_codes { - X11DRV_GET_DISPLAY, /* get X11 display for a DC */ - X11DRV_GET_DRAWABLE, /* get current drawable for a DC */ - X11DRV_GET_FONT, /* get current X font for a DC */ + X11DRV_GET_DISPLAY, /* get X11 display for a DC */ + X11DRV_GET_DRAWABLE, /* get current drawable for a DC */ + X11DRV_GET_FONT, /* get current X font for a DC */ + X11DRV_SET_DRAWABLE, /* set current drawable for a DC */ + X11DRV_START_EXPOSURES, /* start graphics exposures */ + X11DRV_END_EXPOSURES, /* end graphics exposures */ + X11DRV_GET_DCE, /* get the DCE pointer */ + X11DRV_SET_DCE, /* set the DCE pointer */ + X11DRV_GET_GLX_DRAWABLE /* get current glx drawable for a DC */ }; void (*wine_tsx11_lock_ptr)(void) = NULL; @@ -119,11 +125,11 @@ inline static Display *get_display( HDC } -/* retrieve the X drawable to use on a given DC */ +/* retrieve the GLX drawable to use on a given DC */ inline static Drawable get_drawable( HDC hdc ) { - Drawable drawable; - enum x11drv_escape_codes escape = X11DRV_GET_DRAWABLE; + GLXDrawable drawable; + enum x11drv_escape_codes escape = X11DRV_GET_GLX_DRAWABLE; if (!ExtEscape( hdc, X11DRV_ESCAPE, sizeof(escape), (LPCSTR)&escape, sizeof(drawable), (LPSTR)&drawable )) drawable = 0; @@ -142,7 +148,7 @@ inline static HDC get_hdc_from_Drawable( return NULL; } -/* retrieve the X drawable to use on a given DC */ +/* retrieve the X font to use on a given DC */ inline static Font get_font( HDC hdc ) { Font font; @@ -433,6 +439,7 @@ void* WINAPI wglGetProcAddress(LPCSTR l BOOL WINAPI wglMakeCurrent(HDC hdc, HGLRC hglrc) { BOOL ret; + DWORD type = GetObjectType(hdc); TRACE("(%p,%p)\n", hdc, hglrc); @@ -449,6 +456,8 @@ BOOL WINAPI wglMakeCurrent(HDC hdc, } TRACE(" make current for dis %p, drawable %p, ctx %p\n", ctx->display, (void*) drawable, ctx->ctx); ret = glXMakeCurrent(ctx->display, drawable, ctx->ctx); + if(ret && type == OBJ_MEMDC) + glDrawBuffer(GL_FRONT_LEFT); } LEAVE_GL(); TRACE(" returning %s\n", (ret ? "True" : "False"));
Lionel Ulmer wrote:
On Tue, Oct 18, 2005 at 12:08:04AM -0700, Dan Kegel wrote:
I'm tempted to say skip the workaround, at least for the first pass, and just implement the real fix using the opengl extension. As Sippel said, people who use apps like Lightwave (and maybe Quake3 Radiant :-) tend to have the latest 3d hardware and drivers anyway.
I would tend to do the reverse. First code what works on all cards / drivers (that would be pbuffers which are pretty much supported on all cards that I know of) and then only code the 'fast path' if any.
Any feeling which would be easier to code? I had a vague feeling that using the opengl extension would be easier, but maybe I'm all wet. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
--- Dan Kegel <dank(a)kegel.com> wrote:
Lionel Ulmer wrote:
On Tue, Oct 18, 2005 at 12:08:04AM -0700, Dan Kegel wrote:
I'm tempted to say skip the workaround, at least for the first pass, and just implement the real fix using the opengl extension. As Sippel said, people who use apps like Lightwave (and maybe Quake3 Radiant :-) tend to have the latest 3d hardware and drivers anyway.
I would tend to do the reverse. First code what works on all cards / drivers (that would be pbuffers which are pretty much supported on all cards that I know of) and then only code the 'fast path' if any.
Any feeling which would be easier to code? I had a vague feeling that using the opengl extension would be easier, but maybe I'm all wet. - Dan
There's not a huge amount of difference between the possible implementations, the harder bit is compositing the different windows. I think that this should ideally be done in OpenGL with the updates asynchronous and synced to a maximum of the refresh rate of the monitor, but it's probably easier to fetch the data to a didsection. Oliver.
-- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
participants (6)
-
Dan Kegel -
Dan Kegel -
Huw D M Davies -
Lionel Ulmer -
Oliver Stieber -
Tobias Burnus