Bug 354741

Created attachment 95267 [details]
Support information

Created attachment 95268 [details]
Video

It also happens on XRender, OpenGL 2, OpenGL3 with both EGL and GLX

The window eelvation is broken on the cancel, the overlay indication thus on top while it fades out.

Ping?

So, the root of the problem is the Fade effect. The outline window should not be animated by any of current effects. (if we want it to fade in/out, then we have to have dedicated effect for that)

On X11, that's not really easy to fix this bug.

On Wayland, things are a little bit better. We can lower the outline window. So, during fade out animation, it will stay below its "parent" window.

PoC: https://github.com/zzag/kwin/commit/0c56c1febf543ae228cea556119ddfe805be2d0f

Please notice this is just a PoC. Adding internal clients to stacking orderis probably not the greatest thing to do.

Here's potential solution:

* We need to have an explicit class for internal clients, e.g. Internal;
* That class should allow setting anchors, e.g.

   enum class Relationship {
       Below,
       Above
   }

   Toplevel *Internal::anchor() const;
   Relationship Internal::anchorRelationship() const;
   void Internal::setAnchor(Toplevel *toplevel, Relationship relationship);

   (... or maybe just use transientFor?)

* Also, maybe, extend window types (so we can have a dedicated effect that animates the appearing/disappearing of outline), e.g.

   bool EffectWindow::isOutline() const;

   void FadeOutlineEffect::slotWindowAdded(EffectWindow *w)
   {
       if (!w->isOutline()) {
           return;
       }

       // Setup animation data.
   }

   void FadeOutlineEffect::slotWindowClosed(EffectWindow *w)
   {
       if (!w->isOutline()) {
           return;
       }

       // Setup animation data.
   }

* In layers.cpp, after we've got the constrained stacking order, we append internal clients to it [to the constrained stacking order] and then do something similar to what we do with transients in constrainedStackingOrder:

    - if Internal::anchor() returns nullptr, move to the next internal client;
    - otherwise, find position of the anchor in the stacking order;
    - if position is equal to -1, move to the next internal client;
    - otherwise, move the internal client to that position depending on the relationship.

* Add to the Outline class a show method that receives an AbstractClient and also maybe relationship (should the outline be above or below the client). Composited outline would keep track of outline for each window. With compositing being off, the anchor can be ignored, I guess;

* Adjust AbstractClient::setElectricBorderMaximizing, so it passes itself as the anchor.


.... that's just an idea.

*** Bug 401635 has been marked as a duplicate of this bug. ***

I see that also on KWin 5.24.2 Wayland.

I don't see that anymore under Plasma 5.27.5 on Wayland. Can you still reproduce it Kai?

I still see this issue:

Operating System: Fedora Linux 38
KDE Plasma Version: 5.27.5
KDE Frameworks Version: 5.107.0
Qt Version: 5.15.10
Kernel Version: 6.3.7-200.fc38.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 8 × AMD Ryzen 5 3550H with Radeon Vega Mobile Gfx
Memory: 13.6 GiB of RAM
Graphics Processor: AMD Radeon Vega 8 Graphics
Manufacturer: BESSTAR TECH LIMITED
Product Name: UM350

Created attachment 159724 [details]
Flicker in 5.27.5

Created attachment 159725 [details]
reupload

Here's a gif because the site was saying the mp4 is corrupt

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

Git commit b2ff46549075343710bc0e106b9e80085eae7823 by Xaver Hugl.
Committed on 07/06/2024 at 12:46.
Pushed by zamundaaa into branch 'master'.

workspace,window: don't elevate windows during electric border tiling / maximizing

Instead, move the outline below the window, so that the visual order of things stays the
same. This also fixes a visual glitch, where the outline is visible for a moment after
maximization, and is above the no-longer-elevated window
Related: bug 436466

M  +3    -2    src/window.cpp
M  +6    -0    src/workspace.cpp

https://invent.kde.org/plasma/kwin/-/commit/b2ff46549075343710bc0e106b9e80085eae7823

Git commit c0ca01317594dbbaa6fd8c8d86c79c86886b15c2 by Xaver Hugl.
Committed on 07/06/2024 at 13:27.
Pushed by zamundaaa into branch 'Plasma/6.1'.

workspace,window: don't elevate windows during electric border tiling / maximizing

Instead, move the outline below the window, so that the visual order of things stays the
same. This also fixes a visual glitch, where the outline is visible for a moment after
maximization, and is above the no-longer-elevated window
Related: bug 436466


(cherry picked from commit b2ff46549075343710bc0e106b9e80085eae7823)

Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com>

M  +3    -2    src/window.cpp
M  +6    -0    src/workspace.cpp

https://invent.kde.org/plasma/kwin/-/commit/c0ca01317594dbbaa6fd8c8d86c79c86886b15c2

*** Bug 488230 has been marked as a duplicate of this bug. ***