D4990: Update Aurorae Shadow when we copy the buffer, not one frame after painting
This revision was automatically updated to reflect the committed changes. Closed by commit R108:ec4359926b69: Update Aurorae Shadow when we copy the buffer, not one frame after painting (authored by davidedmundson). REPOSITORY R108 KWin CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D4990?vs=12332&id=12633 REVISION DETAIL https://phabricator.kde.org/D4990 AFFECTED FILES plugins/kdecorations/aurorae/src/aurorae.cpp plugins/kdecorations/aurorae/src/aurorae.h To: davidedmundson, #plasma, graesslin Cc: graesslin, plasma-devel, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol
D4990: Update Aurorae Shadow when we copy the buffer, not one frame after painting
graesslin accepted this revision. graesslin added a comment. This revision is now accepted and ready to land. Hah, due to the render control the rendering became smarter than it used to be. Now after re-reading the existing code I see how your change helps. Looks like a good solution, thanks! BRANCH scaling_final REVISION DETAIL https://phabricator.kde.org/D4990 To: davidedmundson, #plasma, graesslin Cc: graesslin, plasma-devel, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol
D4990: Update Aurorae Shadow when we copy the buffer, not one frame after painting
davidedmundson added a comment. > I think the call is deferred to get the correct areas repainted in the compositor. Right that's another reason. We both absolutely agree updating the shadow during the compostior pass would break stuff. The old code did a defer to get the shadow updated outside of the compositor pass. This code moves it earlier so the shadow gets updated outside of the compositor pass. setShadow is still called the same number of times. REVISION DETAIL https://phabricator.kde.org/D4990 To: davidedmundson, #plasma, graesslin Cc: graesslin, plasma-devel, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol
D4990: Update Aurorae Shadow when we copy the buffer, not one frame after painting
graesslin requested changes to this revision. graesslin added a comment. This revision now requires changes to proceed. I think part of your analysis is wrong. At least I cannot remember that I did the deferring for that reason. I think the call is deferred to get the correct areas repainted in the compositor. If we get a repaint from the decoration it does not include the shadow. So when we are in the compositor pass and render the shadow directly we might not have the shadow area in the to be rendered quads at all. It might be clipped away. That's in my opinion why it used a deferred call to ensure that another compositor repaint is triggered from the setShadow call. REVISION DETAIL https://phabricator.kde.org/D4990 To: davidedmundson, #plasma, graesslin Cc: graesslin, plasma-devel, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol
D4990: Update Aurorae Shadow when we copy the buffer, not one frame after painting
davidedmundson created this revision. Restricted Application added a project: Plasma. Restricted Application added a subscriber: plasma-devel. REVISION SUMMARY In the current code we update the shadows during the decoration paint. Because this is called in the middle of the Scene::paintWindow and we have already painted the shadows/built quads, the setShadow() was deferred to avoid the obvious bugs updating the shadow would cause. This sucks because it means we're always out by one frame, and it means we always do two updates. As the shadow is taken from the buffer, we can solve that problem by updating the shadow before any painting at the same time that we update the buffer. This means we don't need the deferring hack. This patch also fixes a related issue that m_padding could have changed after the buffer is rendered, but before painting. This would lead to rendering a mess. This patch caches the relevant padding at the time the buffer is created. @Notmart, this is subtly different from the patch I showed you last night, for me it fixes things without your other patch, but I don't know. If it doesn't it's still (IMHO) a lot cleaner. TEST PLAN Ran an Aurorae theme Maximised, restored, resized. Everything. BRANCH scaling_final REVISION DETAIL https://phabricator.kde.org/D4990 AFFECTED FILES plugins/kdecorations/aurorae/src/aurorae.cpp plugins/kdecorations/aurorae/src/aurorae.h To: davidedmundson, #plasma Cc: plasma-devel, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol
