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 al...@redhat.com alexander.lars...@gmail.com 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@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list