From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26826 invoked by alias); 16 Oct 2012 13:45:48 -0000 Received: (qmail 26809 invoked by uid 22791); 16 Oct 2012 13:45:47 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_50,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mercury.karoo.kcom.com (HELO smtpout.karoo.kcom.com) (212.50.160.61) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 16 Oct 2012 13:45:41 +0000 Received: from 213-152-38-55.dsl.eclipse.net.uk (HELO [192.168.1.103]) ([213.152.38.55]) by smtpout.karoo.kcom.com with ESMTP; 16 Oct 2012 14:45:33 +0100 Message-ID: <507D650A.3060808@dronecode.org.uk> Date: Tue, 16 Oct 2012 13:45:00 -0000 From: Jon TURNEY Reply-To: cygwin-xfree User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: cygwin-xfree@cygwin.com CC: tim@opencircuitdesign.com Subject: Re: Probable bug in WGL implementation (AIGLX) of GLX calls in XWin -wgl References: <506A0C64.2070906@opencircuitdesign.com> In-Reply-To: <506A0C64.2070906@opencircuitdesign.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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/msg00009.txt.bz2 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/