Hi, On Sat, Oct 23, 2010 at 3:37 PM, Owen Taylor <otay...@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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
