Probable bug in WGL implementation (AIGLX) of GLX calls in XWin -wgl

Probable bug in WGL implementation (AIGLX) of GLX calls in XWin -wgl

[Tim Edwards]

[-- Attachment #1: Type: text/plain, Size: 2288 bytes --]

Hello Cywgin-X developers:

    I have a tool I maintain called "magic", a VLSI layout editor.  One
of its nicer features is a graphics mode based on OpenGL.  Occasionally
I generate Cygwin versions of it, and was delighted to discover on my
last update of Cygwin that there is a support for hardware-accelerated
OpenGL using some translation between GLX and WGL calls at the level
of the X server.  I tried using this with my Cygwin version of magic,
and for the most part it works.  But it does have the strange effect
of overwriting the OpenGL window with contents of other windows.

    My setup is very non-standard but works under Linux and OS-X.  The
application is built as an extension of Tcl/Tk.  Because the application
makes all the OpenGL calls from C routines, it generates a generic
window using a call to Tk_CreateWindow(), and maps it using Tk_MapWindow().
The returned window is then passed to glXMakeCurrent().  All of this
works fine.

    The window that is used for the OpenGL rendering is framed by
scrollbars on the side and bottom that are "canvas" windows in Tk.
What I am seeing is that any time the scrollbars are redrawn, the
OpenGL window is over-drawn, looks like with the default Tk background
gray color.  A similar thing happens if I pop a window on top of the
OpenGL window;  when I pop it down, the image of the window remains
in the OpenGL window.  I presume that in the way GLX is supposed to
work, X11 has reserved pixmap space somewhere for the window, but
once the call to glXMakeCurrent() has been made, the contents of this
pixmap should not show up on the screen.  Yet that is what I am seeing.
Any clue as to what might be going on?

    One I tarball up this version of magic, I can send a pointer to
where it can be obtained if anybody wants to download it and test
for the bug.

					Thanks,
					Tim

+--------------------------------+-------------------------------------+
| Dr. R. Timothy Edwards (Tim)   | email: tim@opencircuitdesign.com    |
| Open Circuit Design, Inc.      | web:   http://opencircuitdesign.com |
| 22815 Timber Creek Lane        | phone: (301) 528-5030               |
| Clarksburg, MD 20871-4001      | cell:  (240) 401-0616               |
+--------------------------------+-------------------------------------+

[-- Attachment #2: XWin.0.log --]
[-- Type: text/x-log, Size: 4418 bytes --]

Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.12.4.0
OS: CYGWIN_NT-6.1-WOW64 TEDWARDS-L01 1.7.16(0.262/5/3) 2012-07-20 22:55 i686
OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (WoW64)
Package: version 1.12.4-1 built 2012-08-31

XWin was started with the following command line:

XWin -multiwindow -wgl +bs 

ddxProcessArgument - Initializing default screens
winInitializeScreenDefaults - primary monitor w 1600 h 900
winInitializeScreenDefaults - native DPI x 96 y 96
[436241.757] (II) xorg.conf is not supported
[436241.757] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information
[436241.757] LoadPreferences: /home/TEdwards/.XWinrc not found
[436241.757] LoadPreferences: Loading /etc/X11/system.XWinrc
[436241.757] LoadPreferences: Done parsing the configuration file...
[436241.773] winDetectSupportedEngines - DirectDraw installed, allowing ShadowDD
[436241.773] winDetectSupportedEngines - Windows NT, allowing PrimaryDD
[436241.773] winDetectSupportedEngines - DirectDraw4 installed, allowing ShadowDDNL
[436241.773] winDetectSupportedEngines - Returning, supported engines 0000001f
[436241.773] winSetEngine - Multi Window or Rootless => ShadowGDI
[436241.773] winScreenInit - Using Windows display depth of 32 bits per pixel
[436241.788] winAllocateFBShadowGDI - Creating DIB with width: 1600 height: 900 depth: 32
[436241.788] winFinishScreenInitFB - Masks: 00ff0000 0000ff00 000000ff
[436241.788] winInitVisualsShadowGDI - Masks 00ff0000 0000ff00 000000ff BPRGB 8 d 24 bpp 32
[436241.788] winInitMultiWindowWM - Calling pthread_mutex_lock ()
[436241.788] winMultiWindowXMsgProc - Calling pthread_mutex_lock ()
[436241.788] MIT-SHM extension disabled due to lack of kernel support
[436241.804] XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel
[436241.835] GL_VERSION:     3.0.0 - Build 8.15.10.2321
[436241.835] GL_VENDOR:      Intel
[436241.835] GL_RENDERER:    Intel(R) HD Graphics Family
[436241.835] (II) AIGLX: enabled GLX_SGI_make_current_read
[436241.835] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
[436241.835] (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control
[436241.835] (II) AIGLX: enabled GLX_SGIX_pbuffer
[436241.835] (II) AIGLX: enabled GLX_ARB_multisample and GLX_SGIS_multisample
[436241.835] (II) 60 pixel formats reported by wglGetPixelFormatAttribivARB
[436241.835] (II) AIGLX: Set GLX version to 1.4
[436241.835] (II) 39 fbConfigs
[436241.835] (II) GLX: Initialized Win32 native WGL GL provider for screen 0
[436241.835] [dix] Could not init font path element /usr/share/fonts/OTF/, removing from list!
[436241.960] winPointerWarpCursor - Discarding first warp: 800 450
[436241.960] (--) 3 mouse buttons found
[436241.960] (--) Setting autorepeat to delay=500, rate=31
[436241.960] (--) Windows keyboard layout: "00000409" (00000409) "US", type 7
[436241.960] (--) Found matching XKB configuration "English (USA)"
[436241.960] (--) Model = "pc105" Layout = "us" Variant = "none" Options = "none"
[436241.960] Rules = "base" Model = "pc105" Layout = "us" Variant = "none" Options = "none"
[436241.960] winBlockHandler - pthread_mutex_unlock()
[436241.960] winInitMultiWindowWM - pthread_mutex_lock () returned.
[436241.960] winInitMultiWindowWM - pthread_mutex_unlock () returned.
[436241.960] winMultiWindowXMsgProc - pthread_mutex_lock () returned.
[436241.960] winInitMultiWindowWM - DISPLAY=:0.0
[436241.960] winMultiWindowXMsgProc - pthread_mutex_unlock () returned.
[436241.960] winProcEstablishConnection - winInitClipboard returned.
[436241.960] winMultiWindowXMsgProc - DISPLAY=:0.0
[436241.960] winClipboardProc - DISPLAY=:0.0
[436241.960] winInitMultiWindowWM - XOpenDisplay () returned and successfully opened the display.
[436241.960] winMultiWindowXMsgProc - XOpenDisplay () returned and successfully opened the display.
[436241.960] winClipboardProc - XOpenDisplay () returned and successfully opened the display.
[436245.548] winGetWindowInfo: forcing window to exist
[437037.846] winWindowProc - WM_DISPLAYCHANGE - new width: 1600 new height: 900 new bpp: 32
[437037.955] winWindowProc - WM_DISPLAYCHANGE - new width: 1600 new height: 900 new bpp: 32
[437045.817] winGetWindowInfo: forcing window to exist
[443449.674] winGetWindowInfo: forcing window to exist
[443565.879] [mi] Increasing EQ size to 512 to prevent dropped events.


[-- Attachment #3: Type: text/plain, Size: 223 bytes --]

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

Re: Probable bug in WGL implementation (AIGLX) of GLX calls in XWin -wgl

[Jon TURNEY]

On 01/10/2012 22:34, Tim Edwards wrote:
>    I have a tool I maintain called "magic", a VLSI layout editor.  One
> of its nicer features is a graphics mode based on OpenGL.  Occasionally
> I generate Cygwin versions of it, and was delighted to discover on my
> last update of Cygwin that there is a support for hardware-accelerated
> OpenGL using some translation between GLX and WGL calls at the level
> of the X server.  I tried using this with my Cygwin version of magic,
> and for the most part it works.  But it does have the strange effect
> of overwriting the OpenGL window with contents of other windows.
> 
>    My setup is very non-standard but works under Linux and OS-X.  The
> application is built as an extension of Tcl/Tk.  Because the application
> makes all the OpenGL calls from C routines, it generates a generic
> window using a call to Tk_CreateWindow(), and maps it using Tk_MapWindow().
> The returned window is then passed to glXMakeCurrent().  All of this
> works fine.
> 
>    The window that is used for the OpenGL rendering is framed by
> scrollbars on the side and bottom that are "canvas" windows in Tk.
> What I am seeing is that any time the scrollbars are redrawn, the
> OpenGL window is over-drawn, looks like with the default Tk background
> gray color.  A similar thing happens if I pop a window on top of the
> OpenGL window;  when I pop it down, the image of the window remains
> in the OpenGL window.  I presume that in the way GLX is supposed to
> work, X11 has reserved pixmap space somewhere for the window, but
> once the call to glXMakeCurrent() has been made, the contents of this
> pixmap should not show up on the screen.  Yet that is what I am seeing.
> Any clue as to what might be going on? 

Yes, unfortunately.

The current implementation of GLX using WGL takes a few shortcuts, basically
anything that is drawn with OpenGL isn't composed into the screen, it's just
drawn on top of it.

This works well enough when the GLX window is a top-level window, or is
non-top-level and has no occluding relatives and is drawn after anything it
occludes, but mis-renders in more complex scenarios.

This is discussed a bit more in [1]

As mentioned there I have done a bit of work fix the mis-rendering in some
cases.  I can't quite tell from you description exactly what's going wrong, so
I am not sure if those changes are going to help in this particular case.

I have built a test release including the changes discussed there, available
at [2], if you would like to test if it makes things better/worse/no difference.

The proper solution is probably something like rendering the OpenGL to an
offscreen buffer, and then composing it into the un-occluded area of the
window, but that is considerably more complex to implement.

>    One I tarball up this version of magic, I can send a pointer to
> where it can be obtained if anybody wants to download it and test
> for the bug.

Thanks.  This would be useful as a test case for any future work to improve this.

[1] http://sourceware.org/bugzilla/show_bug.cgi?id=10472
[2] ftp://cygwin.com/pub/cygwinx/XWin.20121012-git-3807fe48a7282459.exe.bz2

-- 
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

Re: Probable bug in WGL implementation (AIGLX) of GLX calls in XWin -wgl

[Tim Edwards]

Hello Jon,

Thanks for the detailed response.

> The current implementation of GLX using WGL takes a few shortcuts, basically
> anything that is drawn with OpenGL isn't composed into the screen, it's just
> drawn on top of it.

I wouldn't want to sound too peevish, as I was quite happy to find that
OpenGL hardware acceleration was even possible, as it was not on the
previous version of Cygwin that I had downloaded.  That it fails in
obscure applications is sort of to be expected.

> This works well enough when the GLX window is a top-level window, or is
> non-top-level and has no occluding relatives and is drawn after anything it
> occludes, but mis-renders in more complex scenarios.
>
> This is discussed a bit more in [1]
>
> As mentioned there I have done a bit of work fix the mis-rendering in some
> cases.  I can't quite tell from you description exactly what's going wrong, so
> I am not sure if those changes are going to help in this particular case.
>
> I have built a test release including the changes discussed there, available
> at [2], if you would like to test if it makes things better/worse/no difference.

I downloaded the link, ran the X server, ran my application, and get no
difference in the behavior.

> The proper solution is probably something like rendering the OpenGL to an
> offscreen buffer, and then composing it into the un-occluded area of the
> window, but that is considerably more complex to implement.

The two problems with this approach are that (1) I have found more
buggy implementations in OpenGL servers by doing offscreen rendering;
and (2) this particular tool is a VLSI layout editor and must be
rendered directly on the front buffer.  The general approach is to
render everything as fast as possible and always be willing to break
on key interrupt to start over.  And I have misappropriated the back
buffer for backing store purposes. . .

The issue here is that I have the whole tool running as an extension
of Tcl/Tk.  I make a low-level call to Tk to give me an X11 window,
which is a simple frame window in Tk but also part of a grid of
sub-windows that includes a menu on top and scrollbars on side and
bottom.  I make a GLX call to render into the window I get from Tk.

There are two occasions when the window gets rudely overdrawn,
apparently by Tk (that is, the X server appears to know when not
to draw into the OpenGL window except when the drawing requests
come from the same process):  One is that if I raise the Tk console
window to obscure part of the OpenGL window, and then lower it behind
the OpenGL window, the interior contents (not the frame, therefore,
only those drawing requests sent to the server by Tk) continue to be
drawn onto the OpenGL window.  The second case is a little bit strange
to me, in that Tk apparently wants to draw the background of the left-
side scrollbar as a gray rectangle that covers not just the scrollbar
window but most of the OpenGL window, too.  It may be a Tk error that
it draws outside the bounds of its own sub-window, but in a correctly
working X server, it does not take precedence over the OpenGL window
contents.  I have found that if I disable the scrollbar, the effect
disappears.  So I can manage to work around everything (if necessary)
except for the obscuring window problem.

>>     One I tarball up this version of magic, I can send a pointer to
>> where it can be obtained if anybody wants to download it and test
>> for the bug.
>
> Thanks.  This would be useful as a test case for any future work
> to improve this.

The program (Cygwin version) is a two-part install that includes an
X11-based version of Tcl/Tk for Cygwin:

	http://opencircuitdesign.com/cygwin

Where "tcltk_x11_w7.tgz" is the 64-bit version that I was using when
I found the problem, and the VLSI layout tool is

	http://opencircuitdesign.com/cygwin/magic.html

where the 64-bit Windows 7 version is "magic-8.0.116w7.tgz".  The
direct download URLs are

	http://opencircuitdesign.com/cygwin/archive/tcltk_x11_w7.tgz
	http://opencircuitdesign.com/cygwin/archive/magic-8.0.116w7.tgz

The latter one installs a shell script /usr/local/bin/magic that
launches the layout tool.  Use "magic -d OGL" from a Cygwin xterm to
get the OpenGL-based version.  The error can be seen by alternately
raising the Tk console window and the layout window, with the contents
of the console window continuing to be drawn after the window is pushed
under the OpenGL window.
						Regards,
						Tim

+--------------------------------+-------------------------------------+
| Dr. R. Timothy Edwards (Tim)   | email: tim@opencircuitdesign.com    |
| Open Circuit Design, Inc.      | web:   http://opencircuitdesign.com |
| 22815 Timber Creek Lane        | phone: (301) 528-5030               |
| Clarksburg, MD 20871-4001      | cell:  (240) 401-0616               |
+--------------------------------+-------------------------------------+

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/

Re: Probable bug in WGL implementation (AIGLX) of GLX calls in XWin -wgl

[Jon TURNEY]

On 16/10/2012 21:34, Tim Edwards wrote:
>> The current implementation of GLX using WGL takes a few shortcuts, basically
>> anything that is drawn with OpenGL isn't composed into the screen, it's just
>> drawn on top of it.
> 
> I wouldn't want to sound too peevish, as I was quite happy to find that
> OpenGL hardware acceleration was even possible, as it was not on the
> previous version of Cygwin that I had downloaded.  That it fails in
> obscure applications is sort of to be expected.
> 
>> This works well enough when the GLX window is a top-level window, or is
>> non-top-level and has no occluding relatives and is drawn after anything it
>> occludes, but mis-renders in more complex scenarios.
>>
>> This is discussed a bit more in [1]
>>
>> As mentioned there I have done a bit of work fix the mis-rendering in some
>> cases.  I can't quite tell from you description exactly what's going wrong, so
>> I am not sure if those changes are going to help in this particular case.
>>
>> I have built a test release including the changes discussed there, available
>> at [2], if you would like to test if it makes things better/worse/no
>> difference.
> 
> I downloaded the link, ran the X server, ran my application, and get no
> difference in the behavior.

Ok. Thanks for testing, anyhow.

> 
>> The proper solution is probably something like rendering the OpenGL to an
>> offscreen buffer, and then composing it into the un-occluded area of the
>> window, but that is considerably more complex to implement.
> 
> The two problems with this approach are that (1) I have found more
> buggy implementations in OpenGL servers by doing offscreen rendering;
> and (2) this particular tool is a VLSI layout editor and must be
> rendered directly on the front buffer.  The general approach is to
> render everything as fast as possible and always be willing to break
> on key interrupt to start over.  And I have misappropriated the back
> buffer for backing store purposes. . .

Sorry, I wasn't clear here.  I'm not suggesting that the application should be
changed.  I'm just describing a possible approach to fixing this problem in
the X server.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/