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
