From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13752 invoked by alias); 17 Oct 2012 12:45:15 -0000 Received: (qmail 13740 invoked by uid 22791); 17 Oct 2012 12:45:13 -0000 X-SWARE-Spam-Status: No, hits=-3.0 required=5.0 tests=AWL,BAYES_00,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; Wed, 17 Oct 2012 12:45:09 +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; 17 Oct 2012 13:45:07 +0100 Message-ID: <507EA862.6070803@dronecode.org.uk> Date: Wed, 17 Oct 2012 12: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: Tim Edwards 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> <507DC4BD.1070100@opencircuitdesign.com> In-Reply-To: <507DC4BD.1070100@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/msg00012.txt.bz2 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/