[Bug 13195] New: GLXMakeCurrent error with BadMatch ( invalid parameter attributes) in SolidWorks
http://bugs.winehq.org/show_bug.cgi?id=13195
Summary: GLXMakeCurrent error with BadMatch (invalid parameter attributes) in SolidWorks Product: Wine Version: 1.0-rc1 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: opengl AssignedTo: wine-bugs@winehq.org ReportedBy: denis.bonnenfant@diderot.org
Created an attachment (id=13020) --> (http://bugs.winehq.org/attachment.cgi?id=13020) +wgl,+opengl,+tid trace
Regression from 0.9.47 (last tested version) :
Solidworks 2007 crashes with :
0009:trace:wgl:X11DRV_wglMakeCurrent make current for dis 0x7c03e5f8, drawable 0x4400013, ctx 0x7c1d412c X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 128 (GLX) Minor opcode of failed request: 5 (X_GLXMakeCurrent) Serial number of failed request: 285350 Current serial number in output stream: 285350
when giving focus to the graphics window (i.e. when selecting a function in the menu, the screen is correctly refreshed, but then the error occurs)
I tried to do a regression test, but it is a real pain as some other bugs are preventing direct git bisect, many patches are needed, and some other issues are appearing randomly. Worse, older versions (0.9.47) known to work are not compilable with ubuntu hardy. As far as i can test, the issue was already there in versions around 0.9.55
I'm suspecting a nvidia driver problem, too, but there are no clues.
I guess that the issue is there : 0009:trace:wgl:wglGetCurrentContext returning (nil)
0009:trace:wgl:wglMakeCurrent hdc: (0xbe04), hglrc: (0x4309748) 0009:trace:wgl:X11DRV_wglMakeCurrent (0xbe04,0x4309748) 0009:trace:wgl:X11DRV_wglMakeCurrent make current for dis 0x7c03e5f8, drawable 0x4400013, ctx 0x7c1d412c X Error of failed request: BadMatch (invalid parameter attributes) ...
http://bugs.winehq.org/show_bug.cgi?id=13195
--- Comment #1 from Vitaliy Margolen vitaliy@kievinfo.com 2008-05-13 11:44:43 --- Duplicate of bug 13144
http://bugs.winehq.org/show_bug.cgi?id=13195
--- Comment #2 from denis bonnenfant denis.bonnenfant@diderot.org 2008-05-13 15:46:30 --- I just updated my sources, but there are no changes.
http://bugs.winehq.org/show_bug.cgi?id=13195
--- Comment #3 from denis bonnenfant denis.bonnenfant@diderot.org 2008-05-13 15:58:01 --- Created an attachment (id=13037) --> (http://bugs.winehq.org/attachment.cgi?id=13037) +wgl,+x11drv
http://bugs.winehq.org/show_bug.cgi?id=13195
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
--- Comment #4 from Vitaliy Margolen vitaliy@kievinfo.com 2008-05-13 23:51:52 --- Then please do the regression testing as described here: http://wiki.winehq.org/RegressionTesting
http://bugs.winehq.org/show_bug.cgi?id=13195
--- Comment #5 from Roderick Colenbrander thunderbird2k@gmx.net 2008-05-14 01:38:15 --- For some reason the wgl log is not complete. Perhaps the application uses multiple GL threads. Try to explicitly set WINEDEBUG=+wgl in your shell and then run wine again and pipe all wgl output to a log file.
Upto now it looks like no pixel format was set on hdc 0xbd04 which leads to the problem.
http://bugs.winehq.org/show_bug.cgi?id=13195
--- Comment #6 from denis bonnenfant denis.bonnenfant@diderot.org 2008-05-14 07:14:54 --- Sorry, I just truncated it because it was too large.
you can download it here :
http://denis.bonnenfant.free.fr/sw.log
http://bugs.winehq.org/show_bug.cgi?id=13195
--- Comment #7 from denis bonnenfant denis.bonnenfant@diderot.org 2008-05-15 09:15:20 --- Unfortunately, regression testing is really difficult, as most of the recent versions need lots of manual patching to be able to run sw and test this bug, and older ones doesn't compile or run anymore on ubuntu hardy. So, to restrict the problem, which dlls are potentially involved ? winex11.drv ? some other ones ?
http://bugs.winehq.org/show_bug.cgi?id=13195
--- Comment #8 from denis bonnenfant denis.bonnenfant@diderot.org 2008-05-15 10:36:51 --- Well, maybe something interesting in log, but i'm not sure to understand the mechanism of pixelformats ! :
it seems that there is a mismatch between onscreen (1 to 80) and offscreen formats ( up to 139 ) :
here 81 is a valid offscreen format, but it is tested with pixelformats=80 which is the onscreen limit ( 81 < offscreen formats < 139 )
0009:trace:wgl:X11DRV_DescribePixelFormat (0x4309990,81,40,0x32f67c) 0009:trace:wgl:ConvertPixelFormatWGLtoGLX Number of returned pixelformats=80 0009:warn:wgl:X11DRV_DescribePixelFormat unexpected iPixelFormat(81): not >=1 and <=nFormats(80), returning NULL! 0009:trace:wgl:wglCreateContext (0xb924) 0009:trace:wgl:X11DRV_wglCreateContext (0xb924)->(PF:0) 0009:trace:wgl:ConvertPixelFormatWGLtoGLX Number of returned pixelformats=139
http://bugs.winehq.org/show_bug.cgi?id=13195
--- Comment #9 from Roderick Colenbrander thunderbird2k@gmx.net 2008-05-17 05:16:19 --- Could you try the latest GIT version of Wine? Some issues related to this bug have been fixed, so perhaps your bug as well. The failure of DescribePixelFormat isn't that bad (perhaps there is a bug there but I just think the app is stupid). The most important calls are SetPixelFormat and CreateContext. CreateContext uses the pixel format set but SetPixelFormat and for some reason it sees pixel format 0 (which doesn't exist). There was a bug which caused this to happen (when a win32 window is created we don't immedeately have a X11 window and some other data structures which cause this problem).
That reminds me this bug might be a duplicate of another bug which sounded the same not sure which it was.
http://bugs.winehq.org/show_bug.cgi?id=13195
denis bonnenfant denis.bonnenfant@diderot.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |thunderbird2k@gmx.net
--- Comment #10 from denis bonnenfant denis.bonnenfant@diderot.org 2008-05-18 10:33:14 --- I tested with updated git sources, but the bug is still there.
http://bugs.winehq.org/show_bug.cgi?id=13195
--- Comment #11 from denis bonnenfant denis.bonnenfant@diderot.org 2008-05-18 10:43:20 --- maybe a duplicate of bug 11991 ?
http://bugs.winehq.org/show_bug.cgi?id=13195
Roderick Colenbrander thunderbird2k@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |DUPLICATE
--- Comment #12 from Roderick Colenbrander thunderbird2k@gmx.net 2008-05-18 11:00:05 --- Most likely it is the same issue.
*** This bug has been marked as a duplicate of bug 11991 ***
http://bugs.winehq.org/show_bug.cgi?id=13195
denis bonnenfant denis.bonnenfant@diderot.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |UNCONFIRMED Resolution|DUPLICATE |
--- Comment #13 from denis bonnenfant denis.bonnenfant@diderot.org 2008-05-28 16:22:58 --- I reopen it, as the resolution of bug 11991 didn't solve the problem. The PixelFormat=0 issue is gone but Badmatch crash is still there.
http://bugs.winehq.org/show_bug.cgi?id=13195
--- Comment #14 from Roderick Colenbrander thunderbird2k@gmx.net 2008-05-28 16:27:10 --- Create a +wgl log of SolidWorks using the latest Wine version.
http://bugs.winehq.org/show_bug.cgi?id=13195
denis bonnenfant denis.bonnenfant@diderot.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #13020|0 |1 is obsolete| | Attachment #13037|0 |1 is obsolete| |
--- Comment #15 from denis bonnenfant denis.bonnenfant@diderot.org 2008-05-28 16:32:51 --- Created an attachment (id=13440) --> (http://bugs.winehq.org/attachment.cgi?id=13440) +wgl trace
This is the trace with the current git version. The crash occurs when opening a new graphics window. It is displayed, and then it is closed.
http://bugs.winehq.org/show_bug.cgi?id=13195
--- Comment #16 from Roderick Colenbrander thunderbird2k@gmx.net 2008-05-30 13:23:17 --- There are some additional fixes in wine 1.0-rc3, perhaps your issue got fixed too. (basically there is no drawable and after reading the glXMakeCurrent docs that can cause a BadMatch)
http://bugs.winehq.org/show_bug.cgi?id=13195
--- Comment #17 from denis bonnenfant denis.bonnenfant@diderot.org 2008-05-30 14:41:56 --- (In reply to comment #16)
There are some additional fixes in wine 1.0-rc3, perhaps your issue got fixed too. (basically there is no drawable and after reading the glXMakeCurrent docs that can cause a BadMatch)
Unfortunately no. The previous tests were already done with the patch 2d9b38133b292f01661a527f7aa0974c0ebc9278 but it is not sufficient, "complex" OpenGL windows support is still broken.
http://bugs.winehq.org/show_bug.cgi?id=13195
--- Comment #18 from Roderick Colenbrander thunderbird2k@gmx.net 2008-05-30 15:58:12 --- The program does a lot of wgl pixel format related queries. Perhaps some of the info confuses it. Further I'd like to see what pixel format it wants to set on the hdc (0x14f4). To figure that out I would add a line like this to the either internal_SetPixelFormat or just X11DRV_SetPixelFormat inside dlls/winex11.drv/opengl.c. Add this: TRACE("physdev=%p, HDC=%#x, iPixelFormat=%d\n", physDev, physDev->hdc, iPixelFormat);
In the end a log of +x11drv,+wgl could be useful too.
http://bugs.winehq.org/show_bug.cgi?id=13195
denis bonnenfant denis.bonnenfant@diderot.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #13440|0 |1 is obsolete| |
--- Comment #19 from denis bonnenfant denis.bonnenfant@diderot.org 2008-05-31 05:16:56 --- Created an attachment (id=13526) --> (http://bugs.winehq.org/attachment.cgi?id=13526) +wgl log
here is the log. There is still a pixelformat=0 for hdc b448, that causes the problem. But I think that the real issue is with physdev 0x4ec4bd8, as I don't clearly understand why it appears there.
When I force pixelformat=1 (see bug 11991 ), I can draw in the window, but there is clearly a windows mismatch, as shown in 11991
http://bugs.winehq.org/show_bug.cgi?id=13195
--- Comment #20 from Roderick Colenbrander thunderbird2k@gmx.net 2008-05-31 10:48:04 --- The main issue seems to be that SetPixelFormat isn't called for HDC=b448 and that is what causes the problems (for that reason there is no X11 window for it and no pixel format). It might be related to the DescribePixelFormat call which fails. Perhaps DescribePixelFormat on Windows is buggy and does something strange for an 'invalid' pixel format. We would need a test case for that.
http://bugs.winehq.org/show_bug.cgi?id=13195
--- Comment #21 from denis bonnenfant denis.bonnenfant@diderot.org 2008-06-02 14:58:48 --- Is there a simple way to trace it under windows ?
http://bugs.winehq.org/show_bug.cgi?id=13195
--- Comment #22 from Roderick Colenbrander thunderbird2k@gmx.net 2008-06-02 15:31:48 --- You could perhaps try to let DescribePixelFormat(81) perform a DescribePixelFormat(80) and let it pass that way. Then see if the app correctly calls SetPixelFormat before calling wglCreateContext on b488.
http://bugs.winehq.org/show_bug.cgi?id=13195
--- Comment #23 from denis bonnenfant denis.bonnenfant@diderot.org 2008-06-02 17:39:43 --- When forcing DescribepixelFormat to use 80 max , it is called in an endless loop, with ipixelFormat incremented. So I guess that the app definitely wants a valid result.
http://bugs.winehq.org/show_bug.cgi?id=13195
denis bonnenfant denis.bonnenfant@diderot.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com
--- Comment #24 from denis bonnenfant denis.bonnenfant@diderot.org 2008-06-30 07:12:21 --- Tried with 1.1.0, and there are some changes :
- the pixelformat seems to be correctly set, - windows are a little bit more correctly adressed ( no windows mismatch and offsets ), - the application now crashes with a seh error, or occasionnally a badmatch error.
But the strangest thing is that the application can only be lauched once ! the second time it stops at the end of opengl initialization, before displaying splashscreen. The computer has to be physically rebooted, closing session or restarting X is not sufficient. Weird !
http://bugs.winehq.org/show_bug.cgi?id=13195
--- Comment #25 from Roderick Colenbrander thunderbird2k@gmx.net 2008-06-30 09:20:02 --- Lately the nvidia driver seems to have various glx issues. Similar issues appear so now and then using multisampling. Some of the issues don't appear on < 100.x, so you could try such a version. Further some of the issues go away when you use a composition manager like compiz. See if any of it helps. Later on we can decide whether to bug nvidia about this.
http://bugs.winehq.org/show_bug.cgi?id=13195
--- Comment #26 from denis bonnenfant denis.bonnenfant@diderot.org 2008-06-30 10:08:50 --- I don't think that the problem is related to the nvidia driver, as when I use +relay redirected to /dev/null (for speed) it works the second time !
Anyway, there is still a problem in opengl, as any window redimensionning cause a badmatch crash.
http://bugs.winehq.org/show_bug.cgi?id=13195
--- Comment #27 from denis bonnenfant denis.bonnenfant@diderot.org 2008-07-02 07:52:34 --- regression tests shows that the problem of the application only starting once is not directly related to this one, so I opened bug 14238
http://bugs.winehq.org/show_bug.cgi?id=13195
Gabriele Moabiti gabmoa@yahoo.it changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gabmoa@yahoo.it
--- Comment #28 from Gabriele Moabiti gabmoa@yahoo.it 2008-07-11 11:22:30 --- I think it's related...
Program name: MLScope Ubuntu 8.04 Scheda nvidia MX400 (chip NV11) Driver video standard: The program doesn't crash but the GL area is all black. Driver video nvidia (from restricted): The program crash with the following log: [...] X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 128 (GLX) Minor opcode of failed request: 5 (X_GLXMakeCurrent) Serial number of failed request: 34965 Current serial number in output stream: 34965 Locking assertion failure. Backtrace: #0 /usr/lib/libxcb-xlib.so.0 [0x7e07d767] #1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_lock+0x2e) [0x7e07d81e] #2 /usr/lib/libX11.so.6 [0x7ea45518] #3 /usr/lib/libX11.so.6(XESetCloseDisplay+0x31) [0x7ea288d1] #4 /usr/lib/libGL.so.1 [0x7eb5c4d5] #5 /lib/tls/i686/cmov/libc.so.6(exit+0xd4) [0xb7d4d084] #6 /usr/lib/libX11.so.6 [0x7ea3e63e] #7 /usr/bin/../lib/wine/winex11.drv.so [0x7dc571d2] #8 /usr/lib/libX11.so.6(_XError+0xfe) [0x7ea3e73e] #9 /usr/lib/libX11.so.6(_XReply+0x231) [0x7ea462f1] #10 /usr/lib/libGL.so.1 [0x7eb5ed49] #11 [0x7c192bd8] #12 [0xb71] #13 [0xd88bd845]
The program is written in VB6, the source code in the SetupPixelFormat is:
...
flags = PFD_DRAW_TO_BITMAP Or PFD_SUPPORT_OPENGL Or PFD_SUPPORT_GDI pfd.nSize = Len(pfd) pfd.nVersion = 1 pfd.dwFlags = flags pfd.iPixelType = PFD_TYPE_RGBA pfd.cColorBits = 24 pfd.cDepthBits = 16 pfd.iLayerType = PFD_MAIN_PLANE PixelFormat = ChoosePixelFormat(hDCsp, pfd) If PixelFormat = 0 Then GoTo PROC_EXIT If SetPixelFormat(hDCsp, PixelFormat, pfd) Then DescribePixelFormat hDCsp, PixelFormat, Len(pfd), pfd If pfd.dwFlags And PFD_NEED_SYSTEM_PALETTE Then ' Not supported as now GoTo PROC_EXIT End If ' Create a OpenGL context hRCsp = wglCreateContext(hDCsp) If hRCsp = 0 Then GoTo PROC_EXIT ' Setting up the current OpenGL context If wglMakeCurrent(hDCsp, hRCsp) = 0 Then GoTo PROC_EXIT
....
It uses the device-indipendent-bitmap to render.
http://bugs.winehq.org/show_bug.cgi?id=13195
--- Comment #29 from denis bonnenfant denis.bonnenfant@diderot.org 2008-07-12 07:20:21 --- can you attach a WINEDEBUG=-all,+wgl log ?
Thanks
http://bugs.winehq.org/show_bug.cgi?id=13195
--- Comment #30 from Gabriele Moabiti gabmoa@yahoo.it 2008-07-12 07:51:31 --- Created an attachment (id=14752) --> (http://bugs.winehq.org/attachment.cgi?id=14752) MLScope output (gl crash)
This is the output (tail -300) of the MLScope crash with GL (nvidia MX400, restricted driver, ubuntu 8.04)
http://bugs.winehq.org/show_bug.cgi?id=13195
--- Comment #31 from denis bonnenfant denis.bonnenfant@diderot.org 2008-07-12 07:58:14 --- please send only complete wgl trace, to see if there is pixelformat=0 somewhere, like with SolidWorks.
http://bugs.winehq.org/show_bug.cgi?id=13195
Gabriele Moabiti gabmoa@yahoo.it changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #14752|0 |1 is obsolete| |
http://bugs.winehq.org/show_bug.cgi?id=13195
--- Comment #32 from Gabriele Moabiti gabmoa@yahoo.it 2008-07-12 08:10:17 --- Created an attachment (id=14753) --> (http://bugs.winehq.org/attachment.cgi?id=14753) MLScope output gl only
new report (full gl only)
http://bugs.winehq.org/show_bug.cgi?id=13195
Gabriele Moabiti gabmoa@yahoo.it changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #14753|text/plain |application/octet-stream mime type| |
http://bugs.winehq.org/show_bug.cgi?id=13195
--- Comment #33 from denis bonnenfant denis.bonnenfant@diderot.org 2008-07-12 08:45:02 --- The problem seems to be different :
pixelformat is correctly set, but wglMakeCurrent is called without a drawable :
trace:wgl:X11DRV_wglMakeCurrent make current for dis 0x7c036ef8, drawable (nil), ctx 0x7c192380
I see no errors before, but why there is no drawable ?
What kind of application it is ? is there multiple opengl windows ?
http://bugs.winehq.org/show_bug.cgi?id=13195
--- Comment #34 from Gabriele Moabiti gabmoa@yahoo.it 2008-07-12 09:46:37 --- (In reply to comment #33)
The problem seems to be different :
pixelformat is correctly set, but wglMakeCurrent is called without a drawable :
trace:wgl:X11DRV_wglMakeCurrent make current for dis 0x7c036ef8, drawable (nil), ctx 0x7c192380
I see no errors before, but why there is no drawable ?
What kind of application it is ? is there multiple opengl windows ?
Yes, the application render in 3 DIB, is written in VB6. I traced the app and after the re-creation of the DIB there is a wglMakeCurrent and here hangs.
When I disable (2 of the 3 rendering DIB) It doesn't hang but the behaviour is the same of the the non accelerated driver, the rendering window is all back.
http://bugs.winehq.org/show_bug.cgi?id=13195
--- Comment #35 from Roderick Colenbrander thunderbird2k@gmx.net 2008-08-14 14:36:07 --- Create a new bug for this VB6 app although a BadMatch is created it has a different cause. The app is doing bitmap rendering and to be honest I'm not sure in what shape it is. Personally I have never used it. Even if the bitmap rendering worked it seems you would have had some other major problem namely pixmap rendering requires a indirect GLX context while for window rendering we use a direct one. Since it seems your app is sharing a context between the bitmap and the window this won't work on Wine unless we create a indirect context by default but in general that KILLS performance.
Regarding SolidWorks try to figure out if the remaining BadMatch is related to an Nvidia driver bug as there a couple of bugs in that area lately and in some cases the use of e.g. compiz helps (it sounds strange but sometimes it helps).
http://bugs.winehq.org/show_bug.cgi?id=13195
--- Comment #36 from denis bonnenfant denis.bonnenfant@diderot.org 2008-08-26 16:31:12 --- It looks like Solidworks viewer, a freely dowloadable app, suffers exactly the same bug. It is quite interesting, as it is small and free and works out ouf the box, so testing may be easier for developpers.
the download link is there :
http://www.solidworks.fr/pages/products/solutions/viewerdownload.html
Interestingly, edrawings viewer, another free CAD file viewer from SolidWorks, rated gold, is not impacted and UI are quite similar. So maybe it could be interesting to compare +wgl logs between the two apps.
the download link is there :
http://www.solidworks.com/pages/programs/eDrawings/e2_downloadcheck.html
Hope this help !
http://bugs.winehq.org/show_bug.cgi?id=13195
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |http://www.solidworks.fr/pag | |es/products/solutions/viewer | |download.html Keywords| |download
--- Comment #37 from Dan Kegel dank@kegel.com 2008-08-26 16:57:20 --- Adding viewer download url, keyword
http://bugs.winehq.org/show_bug.cgi?id=13195
--- Comment #38 from Roderick Colenbrander thunderbird2k@gmx.net 2008-08-29 16:28:26 --- Where to option sample files which can be loaded using the viewer? I tried some files I found somewhere but didn't get those working. I don't have any Solidworks experience, so I have no idea what is needed.
http://bugs.winehq.org/show_bug.cgi?id=13195
disturbedsaint disturbedsaint@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |disturbedsaint@gmail.com
--- Comment #39 from disturbedsaint disturbedsaint@gmail.com 2008-09-02 11:01:32 --- (In reply to comment #38)
Where to option sample files which can be loaded using the viewer? I tried some files I found somewhere but didn't get those working. I don't have any Solidworks experience, so I have no idea what is needed.
You can download some sample files from http://www.solidshack.com/category/3d-models/solidworks/
If that doesn't work please let me know, so I can create some simple models to test with.
http://bugs.winehq.org/show_bug.cgi?id=13195
--- Comment #40 from denis bonnenfant denis.bonnenfant@diderot.org 2008-09-03 16:34:51 --- Created an attachment (id=15815) --> (http://bugs.winehq.org/attachment.cgi?id=15815) sample soliworks part
this part has been modified with SolidWorks2007 under Wine ! It opens perfectly with swviewer2008
http://bugs.winehq.org/show_bug.cgi?id=13195
Guigui guigui.jab@club.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #41 from Guigui guigui.jab@club.fr 2008-12-19 05:19:28 --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=13195
--- Comment #42 from denis bonnenfant denis.bonnenfant@diderot.org 2009-01-31 08:33:23 --- The bug is still there with 1.1.15, tested with Solidworks Viewer, as SW doesn't works anymore with new gecko engine...
Anyway, the most important is that this bug may be quite easy to solve ( for someone that clearly understands Wine and OpenGL, of course !) as it affects a simple and freely downloadable application, SolidWorks Viewer.
http://bugs.winehq.org/show_bug.cgi?id=13195
denis bonnenfant denis.bonnenfant@diderot.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #43 from denis bonnenfant denis.bonnenfant@diderot.org 2009-12-04 04:24:00 --- No problem with 1.1.33. Graphic viewports are correctly displayed and refreshed, perfs are quite good. The only issue is with the property manager ( left panel ), refresh is quite slow, sometimes a black background is displayed.
http://bugs.winehq.org/show_bug.cgi?id=13195
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #44 from Alexandre Julliard julliard@winehq.org 2009-12-04 12:15:34 --- Closing bugs fixed in 1.1.34.
-
wine-bugs＠winehq.org