<table><tr><td style="">graesslin requested changes to this revision.<br />graesslin added a comment.<br />This revision now requires changes to proceed.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D4990" rel="noreferrer">View Revision</a></tr></table><br /><div><div><p>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.</p></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D4990" rel="noreferrer">https://phabricator.kde.org/D4990</a></div></div><br /><div><strong>To: </strong>davidedmundson, Plasma, graesslin<br /><strong>Cc: </strong>graesslin, plasma-devel, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol<br /></div>