On Fri, Oct 22, 2010 at 4:20 PM, Havoc Pennington <h...@pobox.com> wrote:
> If I have a spinner animation and that paints flat-out as fast as
> possible without a "yield gap" to let other sources run, then that
> _also_ starves a superfast main loop source that just sits there
> grabbing messages and then throwing them elsewhere, just as much as it
> starves a super slow main loop source. Speed is not the problem, it's
> whether the source runs at all.
[ ... ]
starting from scratch, and thinking about the parallels with a
pull-model realtime audio design, it seems to me that if you were
designing this entirely from scratch you wouldn't serialize painting
and other source handling. you'd double buffer everything and run the
paint/expose/vblank cycle in a different thread. whenever the
non-paint/expose/vblank threads were done with refilling a new buffer,
it would be pushed (preferably lock free) into a place where it could
be used by a compositor and blitted to the h/w during the
paint/expose/vblank iteration.
with this design, the fast painters always get fast redraws because
their new buffers are always ready at each iteration of the
paint/expose/vblank cycle. the slow painters or the ones that get
blocked by slow sources or whatever simply get their natural frame
rate reduced because they haven't pushed a new buffer by each
iteration.
any similarity to JACK is entirely coincidental :)
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
