From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23241 invoked by alias); 25 Mar 2014 15:59:15 -0000 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 Received: (qmail 23230 invoked by uid 89); 25 Mar 2014 15:59:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: Ishtar.tlinx.org Received: from ishtar.tlinx.org (HELO Ishtar.tlinx.org) (173.164.175.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 25 Mar 2014 15:59:11 +0000 Received: from [192.168.4.12] (Athenae [192.168.4.12]) by Ishtar.tlinx.org (8.14.7/8.14.4/SuSE Linux 0.8) with ESMTP id s2PFx4XH065241 for ; Tue, 25 Mar 2014 08:59:07 -0700 Message-ID: <5331A7C7.6020100@tlinx.org> Date: Tue, 25 Mar 2014 15:59:00 -0000 From: Linda Walsh User-Agent: Thunderbird MIME-Version: 1.0 To: cygwin-xfree Subject: Re: problem with opengl (glxgears) running on cygwin .... References: <532AA9AD.4070306@tlinx.org> <53318D38.5050409@dronecode.org.uk> In-Reply-To: <53318D38.5050409@dronecode.org.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-03/txt/msg00022.txt.bz2 Jon TURNEY wrote: > Since [1], glxgears turns at a constant 70 degrees per second. --- 70 degress/s? How is that important? > > glxSwapBuffers does not block when used with indirect rendering, which means > that lots of frames can be rendered almost instantly, with no apparent > rotation, since the elapsed time between frames is very small. ---- According to the text in the starting window it is rendering at 30FPS. -- I.e. it is sync'ed with my monitor's refresh rate (except for the 1st iteration when it acted unsynced).... ... I.e. in starting window this was displayed: Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 45623 frames in 6.4 seconds = 7166.903 FPS 834 frames in 27.4 seconds = 30.428 FPS 822 frames in 28.8 seconds = 28.542 FPS ---- With all X-window response degraded (Xserver process was peg'ed@100%cpu), virtually no network traffic -- dropped from a norm of 200-400KB/s down to between 1KB-80KB/s. > glxgears is a very basic test that GLX is functioning, and definitely not a > benchmark. Real GLX clients should have a better mechanism for ensuring their > animation rate doesn't outrun the vsync frequency. ---- I thought it was the most basic. It claims (except for the 1st iteration) that it is not outruning my monitor's refresh rate. > > If you have any problems with real GLX clients, I would be interested to hear > them. ---- I'd be interested in finding any that work and proves that it works locally. While my initial use was to try remote GLX, I reverted to trying it localling -- just to verify it worked as it used to. Thats what brought this on. > What is the OS of the remote system? --- linux (opensuse 13.1). No one else on that list was able to see normal response... some got really sluggish response, others saw no movement or nothing. It was only after I ran glxgears locally that I figured I might also have a problem in Cygwin's X, in addition to any other problem I have w/remote display. > I think this is because glxgears will send frames as fast as it can, and can > saturate the X server. ---- The demo claims to sync at the same rate the monitor is refreshing. i.e -- 30 FPS. -- 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/