Hi, On Fri, Oct 22, 2010 at 9:56 PM, Paul Davis <p...@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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
