Best practices for client side buffer management

[Pekka Paalanen]

On Wed, 24 Jun 2020 10:58:41 +0100
Carsten Haitzler (The Rasterman) <raster at rasterman.com> 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. ;-)

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!


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20200624/db581f42/attachment.sig>