Web lists-archives.com

Re: GSK review and ideas




On tor, 2016-12-15 at 13:15 -0500, Owen Taylor wrote:
> On Thu, 2016-12-15 at 16:26 +0100, Alexander Larsson wrote:
> > 
> > This combined with the fact that OpenGL makes it very hard,
> > flickerly
> > and generally poorly supported to do damage-style partial updates
> > of
> > the front buffer means we should consider always updating the
> > entire
> > toplevel each time we paint. This is what games do, and we need to
> > make that fast anyway for e.g. the resize case, so we might as well
> > always do it. That means we can further simplify clipping in
> > general,
> > because then we always start with a rectangle and only clip by
> > rects,
> > which i think means we can do the clipping on the GPU.
> 
> 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.

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.

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.


-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl@xxxxxxxxxx            alexander.larsson@xxxxxxxxx 
He's an all-American small-town senator who hides his scarred face behind 
a mask. She's a radical bisexual fairy princess who don't take no shit 
from nobody. They fight crime! 
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-devel-list