public inbox for
help / color / mirror / Atom feed
From: Linda Walsh <>
To: cygwin-xfree <>
Subject: Re: problem with opengl (glxgears) running on cygwin ....
Date: Tue, 25 Mar 2014 15:59:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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

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:
Problem reports:

  reply	other threads:[~2014-03-25 15:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-20  8:41 Linda Walsh
2014-03-25 14:05 ` Jon TURNEY
2014-03-25 15:59   ` Linda Walsh [this message]
2014-03-27  6:28   ` Yaakov (Cygwin/X)
2014-03-27  7:33     ` remote desktop /session bus woes...(was Re: problem with opengl (glxgears) running on cygwin ....) Linda Walsh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).