From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28712 invoked by alias); 16 Oct 2012 20:34:19 -0000 Received: (qmail 28571 invoked by uid 22791); 16 Oct 2012 20:34:18 -0000 X-SWARE-Spam-Status: Yes, hits=5.4 required=5.0 tests=AWL,BAYES_50,BOTNET,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_NO,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from vms173007pub.verizon.net (HELO vms173007pub.verizon.net) (206.46.173.7) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 16 Oct 2012 20:34:13 +0000 Received: from stravinsky.tim.linglan.net ([unknown] [96.255.242.213]) by vms173007.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0MC000J1Q6GTLRW2@vms173007.mailsrvcs.net> for cygwin-xfree@cygwin.com; Tue, 16 Oct 2012 15:34:06 -0500 (CDT) Message-id: <507DC4BD.1070100@opencircuitdesign.com> Date: Tue, 16 Oct 2012 20:34:00 -0000 From: Tim Edwards User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-version: 1.0 To: Jon TURNEY Cc: cygwin-xfree Subject: Re: Probable bug in WGL implementation (AIGLX) of GLX calls in XWin -wgl References: <506A0C64.2070906@opencircuitdesign.com> <507D650A.3060808@dronecode.org.uk> In-reply-to: <507D650A.3060808@dronecode.org.uk> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-xfree-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-xfree-owner@cygwin.com Reply-To: cygwin-xfree@cygwin.com Mail-Followup-To: cygwin-xfree@cygwin.com X-SW-Source: 2012-10/txt/msg00010.txt.bz2 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/