Re: bug 2398: OpenGL, child windows, and wine
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)
Re: bug 2398: OpenGL, child windows, and wine
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
[EMAIL PROTECTED]
? 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 - 1.22
+++ dlls/x11drv/init.c 21 Oct 2005 10:39:55 -
@@ -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 - 1.64
+++ dlls/opengl32/wgl.c 21 Oct 2005 10:39:56 -
@@ -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"));
Re: bug 2398: OpenGL, child windows, and wine
On 10/20/05, Lionel Ulmer <[EMAIL PROTECTED]> 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
Re: bug 2398: OpenGL, child windows, and wine
> 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/
Re: bug 2398: OpenGL, child windows, and wine
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.
Re: bug 2398: OpenGL, child windows, and wine
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/
Re: bug 2398: OpenGL, child windows, and wine
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 <[EMAIL PROTECTED]> > 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.
Re: bug 2398: OpenGL, child windows, and wine
> 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 <[EMAIL PROTECTED]> 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/
Re: bug 2398: OpenGL, child windows, and wine
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
Re: bug 2398: OpenGL, child windows, and wine
> 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/
Re: bug 2398: OpenGL, child windows, and wine
--- Dan Kegel <[EMAIL PROTECTED]> 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
Re: bug 2398: OpenGL, child windows, and wine
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
Re: bug 2398: OpenGL, child windows, and wine
--- Lionel Ulmer <[EMAIL PROTECTED]> 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
Re: bug 2398: OpenGL, child windows, and wine
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/
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
