Buffer Damage

[Carsten Haitzler]

On Mon, 4 Jan 2021 15:05:12 +0200 Vlad Zahorodnii <vlad.zahorodnii at kde.org>
said:

> On 1/4/21 2:48 PM, Simon Ser wrote:
> > OK, this still doesn't explain which/how/why existing clients would
> > benefit from the optimization, and how much performance will really
> > improve in practice.
> > 
> 
> This will benefit only the compositor.
> 
> If buffer data is being uploaded to a texture asynchronously, you can't
> use the texture since you are most likely going to see junk. Every 
> buffer must be attached to a separate texture.
> 
> On the other hand, the surface damage cannot be used to decide what 
> parts of the texture must be updated because it doesn't include the area 
> of the buffer that got repaired. Either the client has to indicate the 
> buffer damage or the compositor has to determine it by itself, e.g. by 
> accumulating surface damages.

Just accumulate surface damages over N frames (where N is based on the client
using single/double/triple etc. buffering). It's good enough. Other solutions
exist on the client side:

Qt could move to a fully "GL/vulkan" accelerated rendering model for ye olde Qt
widgets... if it wanted to. It'd be a chunk of work but it's possible. It'd
have to implement everything on top of GL client-side with a layer there
instead of software rendering.

Qt could also do its own PBO/texture uploads client-side and then use GL just
as a compositing step, doing these uploads async on the client-side. It also
could use DMABUFs to render to in software (EFL does this with SW rendering if
it can). Even if it's just a final "memcpy" from a tmp CPU-side memory buffer
to the DMABUF to bypass any cache performance issues in the DMABUF. It would
equate in the end to the same thing the compositor has to do, but client-side.

So I see other possibly better solutions to this done client-side and for
"everything else" the accumulation would be good enough IMHO.

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