When opening mks for an already running VM, the QEMU dbus backend has no
way to tell to the VM refresh the display and submit a new UpdateDMABuf.
So by the time size_allocate is called, the height and width of the paintable are
still set to 0.
This should fix the size allocate warning we see now until we figure out a proper
fix from the QEMU side.
Always creating the texture even if the app is not being displayed
(minimized / different virtual monitor) or
if the GdkFrameClock drops a frame we end up doing a comparison with a
very old frame causing full redraws in certain cases or even artifacts
in others.
Instead, we only build the texture once snapshot is called and accumulate
the damage area until that happens to avoid updating the wrong area
The current approach makes use of
- A tiled rendering to work around gdk_texture_diff only doing pointer
comparaison
- Assumes that we would only recieve a scanout cmd followed by multiple
flush ones
In reality, with virtio-gpu at least, the scanout cmd is always
submitted followed by a flush one containing the damaged region.
With the assumption currently made, we end up creating a new paintable
for every scanout cmd causing a full redraw instead
of only redrawing the damaged areas.
Isntead we create the paintable once and call import whenever
we receive a flush cmd (UpdateDMABUF) so we can properly
pass the damage area when creating a GdkGLTexture making
the tiled rendering no longer needed.
This just starts on the DMA-BUF code and abstracts MksPaintable so it can
encapsulate both MksDmabufPaintable and MksCairoFramebuffer.
Currently, the dmabuf just tailes everything (fully) but we can fix that
with snapshot work stil. Either way, want to get the abstraction landed
first before we dive deeper into that.