Hi Gerd, > > > Any other ideas as to how to eliminate that Blit cleanly? > > Well, "cleanly" pretty much implies "supported by toolkit". [Kasireddy, Vivek] I was kind of hoping you'd not draw that implication :) > > gtk glarea for example sets up a framebuffer and expects the application > render to that > framebuffer. So qemu glarea code does a fb-to-fb blit. [Kasireddy, Vivek] Right, that is how it works today but we'd like to not have that blit and instead submit the Qemu application buffer (i.e Guest FB) directly to the compositor -- so that it can be placed on a hardware plane should the compositor decide to do so. Only then it'd be absolute zero-copy but the compositor may decide to composite it which would mean another blit that we cannot avoid.
I am trying to make a concerted effort to accomplish this using GTK/GLArea: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3410 But I get a feeling that it is inadequate as GTK/GLArea does not manage the wl_buffers submitted to the compositor -- EGL does. I suspect we either need to use a new GTK mechanism -- that perhaps does not exist yet -- or not use GTK at all for this. I do understand that adding a new purely Wayland backend would make it redundant given that GTK, SDL, Spice, etc already support Wayland; however, I do not see any good options available for eliminating that blit. Thanks, Vivek > > Other reasons are scaling and cursor rendering. Not all reasons apply to all > UIs. I think > when using spice qemu doesn't blit (not fully sure what happens inside > spice-server), but it > could very well be that the spice-client does the blit instead, i.e. we just > shift the issue to > another place ... > > take care, > Gerd
