Re: GSK review and ideas

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

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

- 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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]