D27788: Implement EGL_KHR_partial_update and EGL_EXT_swap_buffers_with_damage
Vlad Zahorodnii
noreply at phabricator.kde.org
Mon Mar 16 08:33:51 GMT 2020
zzag added a comment.
The key point about EGL_KHR_partial_update is that the compositor know what parts of the back buffer are going to be updated. So the compositor could specify the damage region _beforehand_ recording command buffers. If the compositor doesn't have a sophisticated effects pipeline, e.g. weston, then it's pretty trivial to determine the buffer damage, but that's not the case for us, unfortunately.
Ideally, a compositing cycle must be split into several phases - pre paint, paint, and maybe post paint. In the pre paint phase, the compositor would do necessary bookkeeping so we know what the damage region for the next frame is.
I really like the idea of having a hook that is called when the scene is about to start recording a command buffer for the next frame, but given the current design of the effects pipeline I am starting to think that we cannot support EGL_KHR_partial_update at the moment. The dirty region for the next frame is computed too late and I don't see how we can fix it because effects have the final say in what area of the screen will be repainted. :/
I would love to be proven wrong, though.
REPOSITORY
R108 KWin
REVISION DETAIL
https://phabricator.kde.org/D27788
To: apol, #kwin, #plasma:_mobile
Cc: mwolff, zzag, davidedmundson, kwin, Orage, cacarry, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, fbampaloukas, GB_2, mkulinski, ragreen, jackyalcine, iodelay, crozbo, bwowk, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, hardening, romangg, jensreuterberg, abetts, sebas, apol, ahiemstra, mart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kwin/attachments/20200316/8d80044d/attachment.html>
More information about the kwin
mailing list