Answers to some comments about frame synchronization

[Owen Taylor <otaylor redhat com>]

Benjamin pasted these comments (along with some trivial stuff that I
just fixed) to me on IRC, wanted to respond to them here.

- typedef struct _GdkFrameClock GdkFrameClock; should probably go in
  gdktypes.h so the #include of gdkframeclock.h gets unnecessary (iw
  in gdkwindow.h)

>- Should gtk_style_context_set_frame_clock() be public? If so, we want
>  to disallow people overriding the frame clock if it's a widget's
>  frame clock (people do weird things to style contexts :( ),
>  otherwise we should just assume priv->widget->frame_clock or
>  NULL. Though I like making style contexts animatable for
>  non-widgets, so the API should probably stay.

If style contexts are supposed to be usable for non-widgets, it seems to
me that they should animate as well. That's why I wanted a public
ability to specific the paint clock for a style context. It should be
noted that gtk_style_context_should_animate() currently returns FALSE
if there is no widget for the style context ... I didn't change that,
but didn't want to encode that current limitation in the API - it
doesn't seem motivated by essential considerations.

>- Is using ids the currently accepted way to handle callback
>  connections? I'd have expected gtk_widget_remove_tick_callback
> (widget, tick_callbck, user_data) API. But that might be using
>  g_signal_handlers_disconnect_by_func() instead of using ids.

Removing by function isn't easily bindable by language bindings. Signals
don't work because tick callbacks aren't just notification, they also
have the semantic to run the frame clock and produce ticks. (And also
because they would require walking the entire widget tree on every
update and emitting signals on every widget.) It seemed to me  that
copying the pattern of g_timeout_add(), etc, was the way to go. We could
add g_tick_callback_remove_by_func() for C convenience as well, but
that's probably API bloat.

>  - Multiple tick callbacks is a good idea? I think it probably is,
> just thought I'd ask.

As an example, if I had done GtkStyleContext animations using tick
callbacks, that shouldn't block the widget the an application from also
using tick callbacks as well.

> - recomputing the style should be done in GDK_FRAME_CLOCK_PHASE_UPDATE
>  and we don't want a separate GDK_FRAME_CLOCK_PHASE_STYLE? Because if
>  UPDATE hides/shows widgets, that might trigger restyling due to the
>  CSS tree changing...

In the branch, style recomputation is done in the LAYOUT phase. It can't
be in the UPDATE phase because, as you say, UPDATE can do things that
will cause CSS tree updates. (Style animation is done in the UPDATE
phase.)

I don't have any strong reason for not having a separate COMPUTE_STYLES
phase other than it didn't end up being necessary in the GtkContainer
implementation.

- Owen