| davidedmundson |
| KWin |
With the new interface in KWayland we can add support for viewports. Here the
specified viewport is being respected by setting the texture coordinates when
rendering with OpenGl and setting the source rectangle with QPainter.
The destination size is already implicitly respected through the size of the
KWayland SurfaceInterface.
Tested with weston-scaler.
| Lint Errors | Excuse: unrelated code |
| Severity | Location | Code | Message |
|---|---|---|---|
| Error | input.h:310 | Cppcheck | unknownMacro |
| Error | input.h:310 | Cppcheck | unknownMacro |
| Error | input.h:310 | Cppcheck | unknownMacro |
| No Unit Test Coverage |
| Buildable 20551 | |
| Build 20569: arc lint + arc unit |
| plugins/scenes/qpainter/scene_qpainter.cpp | ||
|---|---|---|
| 298–303 | QPainter compositing is Wayland only and for internal clients Toplevel::isClient() returns false. The only danger to crash could come from an XWayland window without a surface but with damage. If I remember the XWayland code correctly this can't happen though. Damage is always sent through the surface We can add a guard of course but since QPainter backend is more our "experimentation field" than our workhorse I would go without precautionary guards. I can add a comment to the code though to explain the rational. | |
| 311 | In case the source rect is of invalid size there might still be a destination size being specified. That means there is still a difference between vertex positions and texture coordinates what both need to be set correctly in the GL case. In QPainter we don't deal with texture coordinates so it simplifies to only painting from the image to the buffer geometry. | |
What's our plan for deleted windows?
I suspect right now once a window close animation starts the buffer will suddenly jump to be the uncropped version.
I tested with slowed down disappear animation and it worked fine on OpenGl. Don't know a relevant effect working on QPainter backend.
I don't see how the deleted things can work without glitching. I'm sure we'll end up needing to cache the sourceRect.
Maybe Vlad can comment, effects are his area. In general +1.
Don't know a relevant effect working on QPainter backend.
Right now there don't seem to be any. The raster based effects are pretty limited.
Though if any do (or if any 3rd party effect does) we'll crash when we call surface()->
| plugins/scenes/qpainter/scene_qpainter.cpp | ||
|---|---|---|
| 306–312 | I missed this call though, which crashes indeed for internal clients. Thanks. | |
Only if for some reason the window quads cache is invalidated right before X11Client or XdgShellClient gets replaced with Deleted.
Speaking of caches, I think we need to invalidate the window quads cache when the source rectangle has changed.
Effects
Ok, then I withdraw my comment. That sounds like it's going to be good enough.
Speaking of caches, I think we need to invalidate the window quads cache when the source rectangle has changed.
That's a valid point. If we address this, I'll happily hit accept.