Update Aurorae Shadow when we copy the buffer, not one frame after painting

Authored by davidedmundson on Mar 9 2017, 5:21 PM.



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

@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.

Diff Detail

R108 KWin
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.
davidedmundson created this revision.Mar 9 2017, 5:21 PM
Restricted Application added a project: Plasma. · View Herald TranscriptMar 9 2017, 5:21 PM
Restricted Application added a subscriber: plasma-devel. · View Herald Transcript
graesslin requested changes to this revision.Mar 10 2017, 6:13 AM
graesslin added a subscriber: graesslin.

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.

This revision now requires changes to proceed.Mar 10 2017, 6:13 AM

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.

graesslin accepted this revision.Mar 10 2017, 2:57 PM

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!

This revision is now accepted and ready to land.Mar 10 2017, 2:57 PM
This revision was automatically updated to reflect the committed changes.