Re: gtk clutter tearing
Many thanks for the information Kimmo. At least I know which way to go now - this seems to be similar to how iPhone apps behave and I guess this will allow me to port to other OpenGL devices quite easily. - Original message - > On Tue, 2009-12-29 at 16:17 +0100, Tamminen Eero (Nokia-D/Helsinki) > wrote: > > Hi, > > > > ext Mark Clarkson wrote: > > > I have made a simple animation using a clutter timeline with > > > clutter-gtk-0.10 and clutter-1.0 but there is excessive tearing when the > > > animation plays making the animation look terrible. > > > > > > I have tried none, dri and glx values for the CLUTTER_VBLANK environment > > > variable but this seems to have no effect at all. > > > > > > Is there a way to fix this? > > > > Screen update isn't yet synched to LCD refresh. Please file a bug about > > it to bugs.maemo.org (it needs support from kernel display driver, X > > server, SGX driver, Clutter and hildon-desktop compositor, but I guess > > you could file it against Official platform -> Core -> X). > > Don't hold your breath with this one. At the moment it seems a proper > vsync support is not going to be implemented in Maemo 5. There is a > possibility to use a vsync even now, but the implementation is not good > enough: if you enable the current vsync, the OpenGL application is > blocked on glSwapBuffers until vsync comes, which prevents the > application to prepare the next frame (and drops FPS too low). > > I think doing like Bounce does is the best you can do: use fullscreen > window and disable the compositor (in hildon-desktop). Recent > hildon-desktop versions disable compositing automatically for fullscreen > windows, unless you use HildonStackableWindow (which requires the > sliding animation). > > -Kimmo > > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: gtk clutter tearing
On Mon, 2010-01-11 at 18:58 +0100, Tamminen Eero (Nokia-D/Helsinki) wrote: > Hi, > > ext Frantisek Dufka wrote: > >> Recent > >> hildon-desktop versions disable compositing automatically for fullscreen > >> windows, unless you use HildonStackableWindow (which requires the > >> sliding animation). > > > > I wonder what happens to translucent information messages (charger > > attached/removed, ...) in fullscreen SDL applications, are these not > > shown when compositing is off or are they done in different way and > > still shown? > > hildon-desktop automatically switches to composited mode when needed. > > (Making this transition without a temporary user visible visual > "glitch", has taken quite a bit of effort, AFAIK including fixes to > upstream X server too.) Yes, Daniel Stone did an impressive job to get this to work. We can switch between compositing/non-compositing mode without requiring the applications to repaint their windows. -Kimmo > > > - Eero > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: gtk clutter tearing
Hi, ext Frantisek Dufka wrote: Recent hildon-desktop versions disable compositing automatically for fullscreen windows, unless you use HildonStackableWindow (which requires the sliding animation). I wonder what happens to translucent information messages (charger attached/removed, ...) in fullscreen SDL applications, are these not shown when compositing is off or are they done in different way and still shown? hildon-desktop automatically switches to composited mode when needed. (Making this transition without a temporary user visible visual "glitch", has taken quite a bit of effort, AFAIK including fixes to upstream X server too.) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: gtk clutter tearing
Kimmo Hämäläinen wrote: Recent hildon-desktop versions disable compositing automatically for fullscreen windows, unless you use HildonStackableWindow (which requires the sliding animation). I wonder what happens to translucent information messages (charger attached/removed, ...) in fullscreen SDL applications, are these not shown when compositing is off or are they done in different way and still shown? Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: gtk clutter tearing
Hi, ext Michael Cronenworth wrote: Eero Tamminen on 12/30/2009 04:09 AM wrote: Incorrect. I guess there's some illegal black magic happening in-between compiz and apps regardless of UI toolkit libraries. Apps such as dasher that present rectangles and text at fast speeds do not present any tearing when I have the *compositor* set to vsync. Firefox with the SmoothWheel extension for liquid smooth scrolling is tear free until I turn vsync off on the *compositor*. If the related toolkit updates gets into same boxed XDamage event going to the compositor and compositor blocks X updates to the composite buffer while compositing it to screen, you don't get tearing. In practice this may be enough, especially on faster machines, but I think it's more due to fortunate co-incidences than something really being guaranteed by the (current Gtk) toolkit. > My own apps are tear free until I turn off.. > you get the point, I hope. Try for example pannable Gtk treeview with your own cell renderer and add some suitable wait into that renderer to make sure that your renderers' window update gets timewise separated from rest of the treeview update and see whether you get tearing. Of course, I could get into a technical acronym-fest with you, but that wouldn't be very helpful as real world examples would. > If application updates to it's composite buffer aren't > in sync with the compositor display updates, there's obviously > a possibility for tearing. I don't think you understand how X works. :) Hm. Do you? :-) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: gtk clutter tearing
On Tue, 2009-12-29 at 16:17 +0100, Tamminen Eero (Nokia-D/Helsinki) wrote: > Hi, > > ext Mark Clarkson wrote: > > I have made a simple animation using a clutter timeline with > > clutter-gtk-0.10 and clutter-1.0 but there is excessive tearing when the > > animation plays making the animation look terrible. > > > > I have tried none, dri and glx values for the CLUTTER_VBLANK environment > > variable but this seems to have no effect at all. > > > > Is there a way to fix this? > > Screen update isn't yet synched to LCD refresh. Please file a bug about > it to bugs.maemo.org (it needs support from kernel display driver, X > server, SGX driver, Clutter and hildon-desktop compositor, but I guess > you could file it against Official platform -> Core -> X). Don't hold your breath with this one. At the moment it seems a proper vsync support is not going to be implemented in Maemo 5. There is a possibility to use a vsync even now, but the implementation is not good enough: if you enable the current vsync, the OpenGL application is blocked on glSwapBuffers until vsync comes, which prevents the application to prepare the next frame (and drops FPS too low). I think doing like Bounce does is the best you can do: use fullscreen window and disable the compositor (in hildon-desktop). Recent hildon-desktop versions disable compositing automatically for fullscreen windows, unless you use HildonStackableWindow (which requires the sliding animation). -Kimmo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fw: Re: gtk clutter tearing
Eero Tamminen on 12/30/2009 04:09 AM wrote: > Is there some way that this will help me - the original poster? Unfortunately, no. I have not, yet, investigated too far into the compositor Nokia is using. My app references were to compiz, the compositor found on most Linux desktop distributions. > Does clutter bypass the compositor by making its opengl calls? OpenGL apps can only bypass a compositor if they are fullscreen otherwise they are still being painted into offscreen pixmaps. Plus the compositor has to allow full screen apps to be rendered directly instead of offscreen, but it seems this is enabled as Bounce, and other people creating 3D apps, do not have tearing issues. > Do I need to somehow render clutter output to an offscreen buffer and > let the compositor smooth things for me as I blit them back on screen? This is what is already happening transparently to you. You would be duplicating functionality. Before I go any further, I do not believe I have seen any tearing effects on my N900. The cases that I have seen flicker seem to be where the device is simply not able to display fast enough. Do you have your app in a .deb I could install to see what you are seeing? You can attach it via private mail if you don't have a web site for it. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: gtk clutter tearing
- Original message - > You could try playing with the CLUTTER_VBLANK env var (set it to "none", > "dri" or "glx") to see if it helps. No joy with that one - makes no difference at all. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fw: Re: gtk clutter tearing
On Wed, 2009-12-30 at 15:40 +, Mark Clarkson wrote: > > - Original message - > > > off on the *compositor*. My own apps are tear free until I turn off.. > > Ah. Is there some way that this will help me - the original poster? > Does clutter bypass the compositor by making its opengl calls? Do I > need to somehow render clutter output to an offscreen buffer and let > the compositor smooth things for me as I blit them back on screen? That's true. You could try playing with the CLUTTER_VBLANK env var (set it to "none", "dri" or "glx") to see if it helps. Xav ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Fw: Re: gtk clutter tearing
> - Original message - > > off on the *compositor*. My own apps are tear free until I turn off.. Ah. Is there some way that this will help me - the original poster? Does clutter bypass the compositor by making its opengl calls? Do I need to somehow render clutter output to an offscreen buffer and let the compositor smooth things for me as I blit them back on screen? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: gtk clutter tearing
Eero Tamminen on 12/30/2009 04:09 AM wrote: > Incorrect. I guess there's some illegal black magic happening in-between compiz and apps regardless of UI toolkit libraries. Apps such as dasher that present rectangles and text at fast speeds do not present any tearing when I have the *compositor* set to vsync. Firefox with the SmoothWheel extension for liquid smooth scrolling is tear free until I turn vsync off on the *compositor*. My own apps are tear free until I turn off.. you get the point, I hope. Of course, I could get into a technical acronym-fest with you, but that wouldn't be very helpful as real world examples would. > If application updates to it's composite buffer aren't > in sync with the compositor display updates, there's obviously > a possibility for tearing. I don't think you understand how X works. :) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: gtk clutter tearing
Hi, ext Xavier Bestel wrote: >> But where inside the application process they happen (app or Gtk code) >> is not so important. The issue is that Gtk (AFAIK) has no mechanism to >> synchronize this drawing with the compositor and doesn't offer >> applications any mechanism for it either. If painting/redrawing >> takes too long (there's some delay between the X draw commands due >> to what application does internally), it doesn't go the the same boxed >> XDamage event to the compositor. > > AFAIK GTK+ redraws are double-buffered, so if it takes too long to > redraw a frame it's simply delayed until the next one. That double buffering overhead is used to get rid of flickering resulting from successive clear+draw operations, (AFAIK) it's not whole window buffer (for obvious memory usage reasons), so it's not relevant for the tearing issue. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: gtk clutter tearing
On Wed, 2009-12-30 at 14:44 +0200, Eero Tamminen wrote: > Hi, > > ext Claudio Saavedra wrote: > > El mar, 29-12-2009 a las 17:17 +0200, Eero Tamminen escribió: > >> This is not really > >> fixable due to how Gtk painting is arranged, parts of the window are > >> painted in application callbacks. > > > > This is not totally correct. Application callbacks can only cause GTK+ > > to *invalidate* regions. In sane code, redrawing *never* happens in a > > user callback but only in expose event callbacks, which are triggered by > > GTK+ *only* when the time for redrawing comes. > > Application (expose event) callbacks implement painting for > application's own widgets and treeview cell renderers. > > But where inside the application process they happen (app or Gtk code) > is not so important. The issue is that Gtk (AFAIK) has no mechanism to > synchronize this drawing with the compositor and doesn't offer > applications any mechanism for it either. If painting/redrawing > takes too long (there's some delay between the X draw commands due > to what application does internally), it doesn't go the the same boxed > XDamage event to the compositor. AFAIK GTK+ redraws are double-buffered, so if it takes too long to redraw a frame it's simply delayed until the next one. Xav ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: gtk clutter tearing
Hi, ext Claudio Saavedra wrote: > El mar, 29-12-2009 a las 17:17 +0200, Eero Tamminen escribió: >> This is not really >> fixable due to how Gtk painting is arranged, parts of the window are >> painted in application callbacks. > > This is not totally correct. Application callbacks can only cause GTK+ > to *invalidate* regions. In sane code, redrawing *never* happens in a > user callback but only in expose event callbacks, which are triggered by > GTK+ *only* when the time for redrawing comes. Application (expose event) callbacks implement painting for application's own widgets and treeview cell renderers. But where inside the application process they happen (app or Gtk code) is not so important. The issue is that Gtk (AFAIK) has no mechanism to synchronize this drawing with the compositor and doesn't offer applications any mechanism for it either. If painting/redrawing takes too long (there's some delay between the X draw commands due to what application does internally), it doesn't go the the same boxed XDamage event to the compositor. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: gtk clutter tearing
El mar, 29-12-2009 a las 17:17 +0200, Eero Tamminen escribió: > This is not really > fixable due to how Gtk painting is arranged, parts of the window are > painted in application callbacks. This is not totally correct. Application callbacks can only cause GTK+ to *invalidate* regions. In sane code, redrawing *never* happens in a user callback but only in expose event callbacks, which are triggered by GTK+ *only* when the time for redrawing comes. Nevertheless, there are still issues with GTK+ and synchronization of events. See [1] and [2] for a good explanation of these. Claudio [1] http://blog.fishsoup.net/2009/05/28/frames-not-idles/ [2] http://blog.fishsoup.net/2009/06/02/timing-frame-display/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: gtk clutter tearing
Hi, ext Michael Cronenworth wrote: > Eero Tamminen on 12/29/2009 09:17 AM wrote: >> because Gtk doesn't have any support for Vsync. > > Gtk doesn't need to support Vsync. Qt won't magically fix this problem > either. > > Only the compositor needs to support Vsync. Once it does then *all* 2D > operations will be tear-free. Gtk, Qt, terminal-based, etc. Incorrect. If application updates to it's composite buffer aren't in sync with the compositor display updates, there's obviously a possibility for tearing. In practice, if application callbacks paint their own parts fast enough after Gtk does window scroll, they get in to same boxed XDamage event and usually everything looks fine. If they don't, there's tearing. If Gtk happens to draw to its backbuffer while HW is compositing (as requested by compositor), there's also tearing (whether it's visible to user, depends on what's drawn). I think compositor does either input or server grab while compositing, so this might not be a problem. Former can be though. In summary, all of these three steps need to be synchronized for tearing to be completely eliminated: app -> composite buffer -> framebuffer -> LCD Synchronization means waiting / extra buffers so it will slow down screen updates to some extent. Any extra copying done for this would have a large effect on performance because the device is memory bandwidth constrained (like all computers nowadays), buffer swapping is better in this respect. But extra buffers mean increased memory consumption (800x...@16-bit RGB surface is 750kB, at 32-bit RGBA it's 1.5MB). - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: gtk clutter tearing
Eero Tamminen on 12/29/2009 09:17 AM wrote: > because Gtk doesn't have any support for Vsync. Gtk doesn't need to support Vsync. Qt won't magically fix this problem either. Only the compositor needs to support Vsync. Once it does then *all* 2D operations will be tear-free. Gtk, Qt, terminal-based, etc. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: gtk clutter tearing
- Original message - > > > > Is there a way to fix this? > > Screen update isn't yet synched to LCD refresh. Please file a bug about > it to bugs.maemo.org (it needs support from kernel display driver, X > server, SGX driver, Clutter and hildon-desktop compositor, but I guess > you could file it against Official platform -> Core -> X). I just tried the Bounce Evolution game and that synchs perfectly so I guess this means full screen OpenGL works fine (as it does with general transition effects). Does this mean that full screen clutter will work well too? Would the Qt 4.6 Animation Framework work smoothly non-fullscreen? What are the chances of this 'bug' being a high priority and getting fixed soon? I guess that smooth non-fullscreen animation is something many developers would want and end-users would expect to see. I'll get off and file this bug... Cheers Mark ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: gtk clutter tearing
Hi, ext Mark Clarkson wrote: > I have made a simple animation using a clutter timeline with clutter-gtk-0.10 > and clutter-1.0 but there is excessive tearing when the animation plays > making the animation look terrible. > > I have tried none, dri and glx values for the CLUTTER_VBLANK environment > variable but this seems to have no effect at all. > > Is there a way to fix this? Screen update isn't yet synched to LCD refresh. Please file a bug about it to bugs.maemo.org (it needs support from kernel display driver, X server, SGX driver, Clutter and hildon-desktop compositor, but I guess you could file it against Official platform -> Core -> X). After this I think things should look fine in Clutter when app does things right. E.g. panning in normal applications can still tear though because Gtk doesn't have any support for Vsync. This is not really fixable due to how Gtk painting is arranged, parts of the window are painted in application callbacks. If application callback is fast enough that it gets into same boxed damage event from X server (to compositor) as the internal Gtk pannable area scroll, there's no tearing, if it gets drawn later, then update for that part of the window goes to screen on next compositor screen update. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
