Re: GtkGlArea render fps is different than monitor frame rate
- Date: Sat, 4 Feb 2017 23:32:01 +0000
- From: Emmanuele Bassi <ebassi@xxxxxxxxx>
- Subject: Re: GtkGlArea render fps is different than monitor frame rate
On 4 February 2017 at 22:54, Ferenc Engárd <ferenc.engard@xxxxxxxxx> wrote:
> Thanks for the answers!
> I have found the root cause in my code: I realized that GtkGlArea render
> calls are not called automatically for each screen refresh, and the observed
> ~40Hz was coming from my program (a timer I already forgot triggered redraw
> with this rate).
GtkGLArea works exactly like the rest of GTK+: you're supposed to tell
the widget that you need to redraw its contents.
Ideally, GTK+ is driven by the compositor - automatically, under
Wayland; and if the compositor implements the appropriate frame sync
protocol, under X11. I'm not sure whether Unity/Compiz works like that
(GNOME Shell does, though), so GTK+ may default to a less reliable
16.67 timeout. Additionally, this kind of relies on the compositor
being locked to the screen refresh rate.
In any case, nothing automatically causes your UI to refresh itself
every time the screen refreshes; what GTK+ does is, though, use the
timing information coming from the compositor so that it can redraw
itself and submit the new frame for the compositor right after the
previous screen refresh, and before the next refresh cycle.
> What is the common way to request rendering for every screen refresh? Now I
> have added a gtk_widget_queue_draw() into my render callback itself; is this
> the best technique?
The appropriate way to render with GTK+ is always to draw as fast as
possible, and let the toolkit and the compositor present the content
of the window to the user - ideally using the screen refresh rate.
> With this, I got ~59.2Hz, what seems ok, but also indicates that I have
> significant frame drops (>1%), even with reniced -19 priority process... As
> I mentioned, my rendering is very fast, <1ms.
Renicing doesn't do anything: you're submitting frames to the compositor.
Additionally, "60 fps" doesn't mean anything; screen refresh rates are
usually around 59.something Hz, not a perfect round number. On top of
that, there's definitely overhead in the whole process, so it entirely
depends on what you're trying to achieve.
> It would be desirable if I could get info about the current frame counter,
> i.e., similar to one in page_flip_handler's sequence in DRM world, because
> I would like to use some optimizations based on that. Is it possible to get
> this info?
You can get timing information from the GdkFrameClock that is
associated to the GtkWidget; it's not guaranteed that those numbers
are mapped to something coming from the hardware, as the compositor is
in charge of providing that timing information to the toolkit.
If you need to access things like DRM data and deeper timing
information, then I strongly suspect you should not be using GTK+ at
all, since it seem you're writing something like a game.
> On Sat, Feb 4, 2017 at 10:04 AM, Tarnyko <tarnyko@xxxxxxxxxxx> wrote:
>> Your program's rendering is slower than the monitor nominal refresh rate,
>> which is perfectly possible if your scenes are heavy.
>> Please note that it could also render _faster_ (FPS higher than refresh
>> Scenes FPS are not directly tied to your monitor, unless you enable what
>> we call "VSync" : i.e. your FPS are higher than 60, but you programmatically
>> force it down to 60. The benefit is avoiding what we call "tearing", which
>> is a display artifact that your eye could notice.
>> Ferenc Engárd writes:
>>> I have a strange issue with GtkGlArea under linux: it seems my program
>>> with a different fps than the monitor's refresh rate. (The rendering
>>> is fast, faster than 1ms.)
>>> I use a 60Hz monitor mode, and the rendering fps is around 39.5Hz. I
>>> verified my monitor refresh rate with xrandr, and even with another --
>>> X11-EGL based -- program; it is really 60Hz.
>>> I also measured the time interval between two render calls, and the min
>>> max is around 22ms and 28ms, so it seems that I even do not drop a frame.
>>> I do not set anything special in GtkGlArea or opengl (glSwapInterval or
>>> Did you encounter with such an issue? Any idea what can be the problem?
>>> Ubuntu 16.04, unity, gtk+ 3.18.9
> gtk-devel-list mailing list
[@] ebassi [@gmail.com]
gtk-devel-list mailing list