Re: Doubts about GPeriodic

[Havoc Pennington <hp pobox com>]

Hi,

On Sat, Oct 23, 2010 at 3:37 PM, Owen Taylor <otaylor redhat com> wrote:
>  - We should not start painting the next frame until we are notified
>   the last frame is complete.

Does frame-complete arrive when "we just did the vsync" i.e. last
frame is just now on the screen?

We can dispatch "other stuff" while we wait for this, right? Does the
time between sending off the buffer swap, and getting the frame
complete back, count as time spent doing other stuff? I guess that
would roughly mean "if paint finishes earlier than it had to, get
ahead on other stuff in the meantime" - the wait-for-frame-complete is
a way to take advantage of any time in the 50% designated for painting
that we didn't need.

I mean, presumably while waiting for frame-complete the main loop is
going to run, the question is just whether that time gap factors into
any of the time calculations.

>  paint time    other time      fps   work fraction
>  ==========    ==========      ===   =============
>  1ms           15ms             60   94%
>  8ms            8ms             60   50%
>  10ms          22ms             30   68%
>  17ms          15ms             30   47%
>  20ms          12ms             30   38%
>  24ms           8ms             30   33%
>  40ms          10ms             20   20%
>  55ms          11ms             15   20%
>  90ms          10ms             10   10%
>
> But what this does mean is that there is a cliff across different
> systems here that's even worse than it looks from above. Take a very
> non-extreme example - if I'm testing my app on my laptop, maybe painting
> is taking 20ms, and I'm getting a reasonable 30fps. I give it to someone
> with a netbook where CPU and GPU are half the speed and painting takes
> 40ms. The framerate drops only to 20fps but the time for a background
> operation to finish increases by 3.8x. The netbook user has half the CPU
> and we're using only half that half to do the background work.

Good breakdown, a detail, at some point animations are just unusable.
I think you need a pretty smooth / reliable 15-20fps-ish for an
animation to be even worth doing, really. If you average a rate like
that but have some big hang at the start or end, or if you average a
really bad rate like 5-10fps, my experience is that people say "this
is slow and sucks" and also the animations don't usually achieve the
UI feedback goal because people don't perceive motion, they perceive
an annoying artifact.

I don't know exactly how to deal with that. It doesn't really matter
for the tree view thing, that's not an animation. But I do wonder if
we could automatically make an animation drop all frames, if it's only
going to have 4 frames anyway, or whatever. I guess this is a side
issue / additional elaboration.

> So, there's some appeal to actually base it on measured frame times.
> Using just the last frame time is not a reliable measure, since frame
> painting times (using "painting" to include event process and relayout)
> are very spiky. Something like:

I had awful luck with this. (I did try the averaging over a window of
a few frames. I didn't try minimum.)
It's just really lumpy. Say you're transitioning from one screen to
another, on the first frame maybe you're laying out the new screen and
uploading some textures for it, and then you have potentially very
different repaint times for the original screen alone, both screens at
once during transition, and the final screen. And especially on crappy
hardware, maybe you only get a few frames in the whole animation to
begin with. Minimum might be more stable than average. Another issue
with animation is you don't know the average until you're well into
the animation.

Now in the tree view case, rather than an animation case, I'd expect
very uniform paint times.

Here's a direction of thought: do things differently when there's an
animation active vs. when we're doing a "regular" paint. litl shell
actually does track this. The problem with it (maybe obviously) is if
you have any continuous/persistent animations.

>  - Average time over last three frames
>  - Minimum time over last three frames
>  - Average time over last three frames where only motion events were
>   delivered

I wonder if some kind of synthetic benchmark would end up working more
predictably. Sort of like that "performance score" Windows will
compute for you. Maybe they even store that somewhere and base stuff
on it, who knows.

Though as long as we're only using this for a *max* time to do "other
stuff," rather than setting a timeout or simply blocking, it isn't
exactly the end of the world if we get this wrong.

> Basically yes. I can't see us ever doing video in gnome-shell - we just
> have to be able to smoothly composite video someone else is playing.

(to be clear, that's what we do also.)

> But I'm not really thinking about gnome-shell here, I'm really thinking
> more about a "standard" application .... perhaps Evolution or Rhythmbox.
> Whether written in GTK+ or in Clutter or some hybrid.

Agree the default should plan for those, however, I would hope there's
a way to do the compositor without a GTK patch.

> This may indicate a need to have tuning parameters. A knob to turn
> between not starving background processes and not dropping frames.

I wonder if the right tuning knob is:

 paint_clock_push_paint_percentage(clock, 0.5)

where essentially the 50/50 split can be messed with. This is useful
in the litl type case with fixed hardware (a not uncommon use of
Clutter, for sure).
But it might also be useful if you are doing the treeview thing:

// no point at all updating the screen super often during this, give GTK a hint
push_paint_percentage(0.3)
fill tree view
pop_paint_percentage()

An elaboration of this might be to cut off the nonpaint if we get user
interaction. (Hmm. Is that the right thing to do in general? Maybe any
motion/button/key event that either queues a paint or happens with one
already pending, causes us to start the paint as soon as the event
queue is drained, instead of dispatching non-event non-paint sources?)

Alternatively, the tuning could be via environment variable. Could be
expressed as paint percentage, or even as FPS:

 GTK_TARGET_FPS=30

where the idea is, if I know 30fps is about what ought to be happening
if stuff is working, I just set that and GTK sets it up to work well
for 30fps. In this scenario tuning is just for people coding for
dedicated hardware, or for knowledgeable Linux users who want to tune
for their netbook.

> The expander animation really isn't my concern. It will end soon enough
> no matter how many items the treeview has. My concern is the scrollbar -
> the scrollbar will continually need repainting until the treeview is
> full.

This is a situation where special-casing transition animations could
be a win, as long as "everpresent" effects don't trigger the special
case.

Havoc