Hi,
More on tearing/VSYNC issues...
===== GENERAL PURPOSE VSYNC INFORMATION =====
i finally understood some about using VSYNC with 2 physical screens, might
be useful to someone.
I put up some test file displaying 6 video streams simultaneously on 2
screens using Nvidia TwinView. With VSYNC disabled, it runs around 150 fps.
Without, it runs at 60 fps. Both perfectly fluid.
Here's the FPS stdout print example:
*** FPS: 61 ***
*** FPS: 61 ***
*** FPS: 61 ***
*** FPS: 61 ***
*** FPS: 60 ***
If i run the app without using VSYNC, i get occasional tearing artifacts on
both screens (although hardly noticeable).
If i run the app using VSYNC (both by letting CLUTTER_VBLANK untouched, to
True or __GL_SYNC_TO_VBLANK=1) , the left screen is nicely rendered (no
tearing), and the right one (secondary) has tearing artifacts.
If i want to sync on the secondary device, the __GL_SYNC_DISPLAY_DEVICE'] =
'CRT-1' only works if i use the __GL_SYNC_TO_VBLANK env var.
Which sets a definite point to this tearing issue in dual monitor mode using
nvidia: if you wanna sync on a secondary display, you should use the
__GL_SYNC_DISPLAY_DEVICE with __GL_SYNC_TO_VBLANK environment variables.
===== REAL USE CASE =====
However, with my real application, which is becoming somewhat monstruous
(there's twisted using the loop as well but when it's idle there's no
change, we have lots of layout computing but not during runtime), i can't
make use of VSYNC: the framerate, around 140 fps without VSYNC, is reported
around 60 fps with VSYNC, but :
* the video playback is VERY sluggish
* animations like e.g. a rotating logo freezes slightly, could be for every
FPS print on STDOUT (weird !) -- even when it's not printed out
* the FPS count seems a bit unstable, c.f. below
*** FPS: 58 ***
*** FPS: 52 ***
*** FPS: 59 ***
*** FPS: 55 ***
*** FPS: 58 ***
*** FPS: 57 ***
*** FPS: 57 ***
*** FPS: 57 ***
*** FPS: 43 ***
*** FPS: 55 ***
*** FPS: 61 ***
I tried raising the clutter-gst texture upload priority by setting
clutter_threads_add_idle_full's priority to G_PRIORITY_DEFAULT in
clutter-gst-video-sink.c, without noticeable effect.
Another hint: since the small animation seems to freeze on FPS count print,
this may indicate that there's something that's freezing the app here:
if (g_timer_elapsed (timer, NULL) >= 1.0)
{
g_print ("*** FPS: %i ***\n", timer_n_frames);
timer_n_frames = 0;
g_timer_start (timer);
}
In short, all of this may indicate that there's a bottleneck somewhere, and
this bottleneck might well be that of the main glib loop. But why ONLY when
using VSYNC ?
As bpeel suggested on the IRC, doing the glXSwapBuffers calls inside a
separate thread could be of help (after all, is the FPS counts' instability
suggesting a bad FPS counting or a glXSwapBuffers-related bandwidth/process
limitation ?).
Also, if the entire scene is redrawn for every actor change, is this also
the case for FBO actors ? (will the group be redrawn or the children actors
as well ?) Would using FBOs lighten the 3D engine's work ?
I looked at clutter's debug messages (using CLUTTER_DEBUG=all), but i found
no errors nor warnings whatsoever.
More importantly, i cannot seem to reproduce the problem with a heavy video
displaying application. I'm working on a more stressfull testing
application.
I'm looking for :
* ways to debug the glib loop (like, queue messages management related to
video texture uploads)
* information about clutter's VSYNC handling and related possible glib
features utilization; for instance, in VSYNC mode, are some draw() grouped ?
In a heavily loaded Glib loop, could the video textures transfer be too long
for the 60fps constraint ? When using clutter's vblank, the log indicates
the activation of glXSwapIntervalSGI (setup success), when using nvidia's or
no vblank "vblank sync: disabled at user request" -- is this a normal
behaviour ?
* any ideas :)
More on the context:
* no manual/custom threading instructions
* no heavy processing in the app itself
* no changing actors except video textures
* 681 actors (doh !) -- but not very deep tree (9 levels at most)
* using latest clutter stable distribution
(pyclutter-0.6.2,clutter-cairo-0.6.2, clutter-gst-0.6.1)
* our pyclutter overlay (http://candies.ubicast.eu) doesn't do anything
low-level like forced redraws etc...
* nvidia 9600GT on steroids (behaviour also seen on other nvidia devices) --
mallum's "try bigger hardware" suggestion didn't change a thing ;) --
173.14.12 driver
* Ubuntu 8.04 (also seen on 7.10) 32 bits regular desktop
* TwinView mode (1280x1024+1024*768 or less)
* intel quad core processor
* lots of gstreamer threads (in overall, 17 threads... 3 main video decoding
threads for gst taking around 15% CPU time, 1 for clutter, taking 75-85% of
a processor with VSYNC, 85-95% without)
I can provide full debug logs for 3 use cases (clutter VBLANK, nvidia
VBLANK, no VBLANK) if it's of any help, or please just tell me messages i
should be looking for (all are 100k+ long lines of debug... my eye might
have slipped the good ones).
Thanks in advance for helping us push clutter to it's limits :)
Regards,
Florent
