Best practices for client side buffer management

Carsten Haitzler raster at
Wed Jun 24 11:42:26 UTC 2020

On Wed, 24 Jun 2020 14:28:18 +0300 Pekka Paalanen <ppaalanen at> said:

> On Wed, 24 Jun 2020 10:58:41 +0100
> Carsten Haitzler (The Rasterman) <raster at> wrote:
> > you keep a sliding window of the last 2 frames with of rect regions you
> > union (merge with) the current frame's update rects... then render that.
> > you can play tricks like copy back some regions from a previous frame
> > instead of re-rendering them (as it's a read from, not a write to that
> > buffer it's safe..
> Yes, copying from a busy buffer is safe.
> > but beware that readbacks may have issues especially if regions are not
> > mapped as non-cachable because they are being scanned out/displayed for
> > example. it depends on hardware entirely so the safe thing is to their
> > shadow them and make a copy before you display or just re-render them. it
> > turns out the just re-render is simpler to do and generally performant).
> You said you were going to cover only software-rendering, but here you
> go. ;-)

you can software render to hardware mappable buffers... quite common if you
have a system with no GPU - just a simple display processor with a single
fraembuffer output or maybe a few layers/sprites or perhaps just a 2d
accel unit (blitter funtimes)... :) my point was more that you have explicit
control over the ABC buffer ordering as opposed to going via gl (egl) where you
don't have control and have to query and hope for sanity... :)

> IOW, the caching thing applies to hardware buffers (some of which can
> be written to by CPU). But a usual desktop application or a toolkit
> should not use hardware buffers for software rendering. The performance
> hit you refer to can also happen in the compositor!

correct. so it depends on the situation, but also how to map the buffer at the
time and other hardware constraints. i've had to beat some interesting hardware
into shape before. if 99% of the time the compositor just displays a frame
(assigns the buffer to a hw scanout) then the readback problem is not bad and
only hits you sometimes. it's a whole ymmv and just something to know about if
you are poking around in this world. :)

------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - raster at

More information about the wayland-devel mailing list