On Fri, 2016-12-16 at 09:05 +0100, Alexander Larsson wrote: > On tor, 2016-12-15 at 13:15 -0500, Owen Taylor wrote: > > [...] > > Just because we need to be able to repaint the whole toplevel > > quickly for resizing and other animations, and just because games > > repaint the whole scene - that should not drive an assumption that > > there is no value to clipped updating. Clipped updating is not done > > for speed - it's done to reduce power consumption and to leave > > resources (GPU, CPU, memory bandwidth) for other usage. > > > > If a copy of Evolution in the background is using only 25% of > > system resources to update a small progress bar at 60fps, that's > > not "60fps success!", that's "2W of power - fail!" > > Well, things are not always so clear cut. Fundamentally, OpenGL > doesn't have great primitives for clipping to a region of unbounded > complexity. > > First of all, generally you have to supply entire buffers that have > valid content everywhere. If you're lucky you can use extensions like > buffer age so that you can track which part of the back buffer is up- > to-date, but that requires double or tripple buffering, which itself > brings up the memory use and possibly the the power use.
I don't think we need to count on luck to have the buffer age extension - it is widely available on Xorg and Wayland and we have the ability to fix cases where it is missing. Yes, we want to run on GL on Windows/Mac too, but we shouldn't tie our efficiency hands behind our back because there might be some place where we have to redraw full frames. Reusing old buffers shouldn't increase memory usage - you decide if you are double buffering or triple buffering, and either way, once a frame has finish being composited or scanned out, you simply reuse it instead of freeing it. > Secondly, if you're painting to an old buffer where you want to > update only the damage region, then you need to guarantee that all > your drawing is completely clipped to the damage region. If this is a > complex region, or just say two small rects far from each other, then > scissoring is not good enough to do clipping for you. The alternative > then is something like stencil buffers, but that means clipping on > the pixel level, so you have to do a lot of work anyway, submitting > geometry that you don't know will be clipped or not. I think there's a lot of value in just updating the bounding rectangle of the damage. While pathological cases exist (two progressbars, one in each corner of the window!), most of the time a minor update to a window - whether a progress indicator or a blinking cursor - are actually very confined. My inclination is to track the full damage regions - the region implementation is darn efficient when compared to modern hardware - and only reduce to a bounding rectangle at the end. This maintains flexibility and allows the possibility of using things like https://www.khronos.org/registry/egl/extensions/KHR/EGL_KHR_swap_b uffers_with_damage.txt - Owen P.S. - when thinking about power consumption, not only does clipping allow actually not processing pixels, if you combine it with culling, you greatly reduce the number of objects you are walking over and the amount of setup that is being sent to the rendering API. > Still, I guess we should try to do this as well as we can, especially > if we want to keep any decent performance for the software fallback > case. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
