https://bugs.kde.org/show_bug.cgi?id=459778

Paul McAuley <k...@paulmcauley.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |k...@paulmcauley.com

--- Comment #59 from Paul McAuley <k...@paulmcauley.com> ---
(In reply to Vlad Zahorodnii from comment #53)
> My best theory is that klassy tries (or did try in the past) to change the
> shadow when kwin paints the decoration. With the current implementation,
> changing the shadow when kwin composes the output will produce
> EGL_BAD_SURFACE. On the other hand, the decoration should not mess with the
> shadow in Decoration::paint().
>
> Not sure what we can do without being able to reproduce the bug, we don't
> have enough data to act on it.

Hi Vlad,

Klassy developer here. After much investigation, I can confirm that your theory
is correct.

Klassy has the option of coloured window outlines that are drawn as part of the
shadow; these colours depend on the system colour scheme. Therefore, Klassy
triggers an update of the shadow should the system colour scheme change by
connecting the KDecoration2::DecoratedClient::paletteChanged signal. This is
how the shadow can be changed when the paint() function is executing (the
shadow is not "messed with in Decoration::paint()" directly).

The EGL_BAD_SURFACE segfault only occurs with Klassy 4.0 from Plasma 5.26 beta
onwards (did not occur in Plasma 5.25), and especially seems to be triggered
when launching applications which have their own custom colour scheme options.

As a temporary workaround, today I released Klassy 4.1 which seems to
workaround this in the majority of cases, but I'm not sure how robust a fix it
is
(https://github.com/paulmcauley/klassy/commit/972edd08184b3a416b166053a1b1a3d042d33d92).
I set a m_painting flag at the start of the decoration's paint() function and
clear it at the end of paint() to try and detect when paint() is running (is
there a better way to detect from the decoration when kwin is composing?). I
then abort any attempt to change the shadow should the m_painting flag be set.
I had also experimented with implementing delays instead of aborting, but this
did not work as I don't think my detection of the kwin composing is accurate
enough.

Would it be possible to implement something more elegant/robust within kwin so
that a call of setShadow() and paint() at the same time will not cause an
EGL_BAD_SURFACE to occur e.g. delay shadow rendering until after paint()? Or
even have that the segfault does not occur as in Plasma 5.25?

Paul

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to