Re: Doubts about GPeriodic

[Havoc Pennington <hp pobox com>]

Hi,

On Fri, Oct 22, 2010 at 9:56 PM, Paul Davis <paul linuxaudiosystems com> wrote:
> you guys are working out an incredibly complex and potentially baroque
> solution when the elegant and arguably "correct" one has already been
> implemented several times in different contexts. what's the point?
>

There's a lot of text in this thread but I think the resulting code at
issue is not large, dev time measured in days. Well what we're arguing
about is just a small patch once there's a paint clock. The paint
clock itself somewhat larger but still hopefully days. (Developer days
not calendar days.) We have significant prior art (clutter master
clock, litl shell, gnome shell, etc.) so it isn't from scratch, that's
part of why people have stuff to say about it. Heck I'm sure Ryan has
already finished the thing while we're discussing it here.

Changing over to having threaded rendering and GL-composited layers is
comparatively huge by 10x or 100x I would think, and hasn't even been
prototyped out by anyone. I could be wrong, as I said I haven't tried
to work it through other than idly thinking about it a little. Maybe
there is a simple version.

An important problem is more or less addressed by just the paint
clock, which is to be able to sync to hardware refresh and have a
tween timestamp related to that syncing. It's possible to get smooth
animation by just adding the paint clock.

As a practical matter what I'm going for is to get GTK to be sensible
when in-process with Clutter. The other stuff I listed at
http://log.ometer.com/2010-10.html#18 is part of that too. I just feel
like it sucks to continue the "to use Clutter you have to reinvent all
the GTK wheels" situation until GTK 4 and that it might not be such a
huge task to make GTK behave itself.

It may be that a possible approach to a render thread is to have
clutter in one thread and GTK in another thread.... layers are clutter
actors that GTK renders to... just idly thinking again ;-)  honestly I
have no idea how all this should work. Another question that keeps
popping up for me is why each process should have its own compositor
and then there's also an X compositing manager.

Havoc