For the record, I wouldn't mind if someone who is in a better position to test it commandeered this revision. I think I mentioned that on irc.

• Rebase on master
• Limit the line length to 100 characters.

In D25611#569457, @zzag wrote:

In D25611#569453, @fredrik wrote:

The decoration parts should already be padded. The commit message in the commit that introduced the atlas (6ad4c775d7840e64a07e27d6719a3ea7c3ee5eb8) even says so:
"The images are separated by a row of transparent texels to minimize artifacts from oversampling."

Yes, it does and that's the problem since the transparent texels contribute to the final output value. Am I missing something?

The decoration parts should already be padded. The commit message in the commit that introduced the atlas (6ad4c775d7840e64a07e27d6719a3ea7c3ee5eb8) even says so:
"The images are separated by a row of transparent texels to minimize artifacts from oversampling."

Rebase on master.

Use a fence to ensure that all rendering is complete before swapping buffers.

In D23881#535167, @romangg wrote:

In D23881#529634, @ekurzinger wrote:

Also, apart from the above two comments, any thoughts to how this relates to Roman's pending re-work of a lot of the GLX code https://phabricator.kde.org/D23105?

@fredrik: I would be interested in this as well. This change allows to schedule buffer swaps like we do with swap events at some point before the vblank and then get an event through second thread when the thread is unblocked again i.e. when the swap has been completed, right? This should also work with my rework patches only providing a single path with an event after swap (or a fallback timer if such an event is not available on the hardware).

Only disable sRGB configurations on LLVMpipe when the default depth is 16.

This code doesn't actually have anything to do with triple-buffering. Its sole function is to detect whether glXSwapBuffers() blocks; the (incorrect) assumption being that if it doesn't, then the driver uses triple-buffering.
But this information is only used to decide whether to call glXSwapBuffers() in prepareRenderingFrame() or endRenderingFrame(). KWin doesn't try to render more than one frame per swap interval regardless.

In D23105#514634, @romangg wrote:

In D23105#514201, @fredrik wrote:

In D23105#512099, @romangg wrote:

In D23105#511957, @fredrik wrote:

NVIDIA doesn't support the OML extensions. They can't be implemented efficiently on their hardware IIRC.
[...]

That's good to know. Thanks! I believe we can let in some of these extensions again without increasing the complexity too much as long as the SGI ones is ignored and we have no manual control of vsync. The complexity in the old code came mostly from that.

That would leave the user without a way to override the driver's default vsync setting.

I want KWin to run v-synced always. I don't think it makes sense to make this configurable by the user. It's the default in our Wayland session and on X11 the compositor should always run v-synced as well. Or is there a valid use case for running it async in your opinion?

By the way, you are partially duplicating work already done in this branch:
https://cgit.kde.org/kwin.git/log/?h=fredrik/swap-event-wip2

In D23105#512099, @romangg wrote:

In D23105#511957, @fredrik wrote:

NVIDIA doesn't support the OML extensions. They can't be implemented efficiently on their hardware IIRC.
[...]

That's good to know. Thanks! I believe we can let in some of these extensions again without increasing the complexity too much as long as the SGI ones is ignored and we have no manual control of vsync. The complexity in the old code came mostly from that.

NVIDIA doesn't support the OML extensions. They can't be implemented efficiently on their hardware IIRC.

In D22153#489729, @zzag wrote:

... also please change blur: to [effects/blur] in the subject line

In D21916#488817, @romangg wrote:

There are now two open reviews and a merged patch to 5.16 that wasn't merged back to master (now merged back by Vlad) and apparently induces a regression on openQA. The merged patch didn't reference its review. All open reviews don't reference each other.

What I mean by that: It's difficult for me and probably other people as well to have an overview of which patch does what and how they are all connected with each other. Please create an overview task where you describe the overall goal of these patches and the intend of each patch singularly. Reference all patches in the task and in between each other when it makes sense.

Make sure that the default framebuffer is bound when checking the color encoding.

To ssh://git.kde.org/kwin
61956025f..3d384f3c9 Plasma/5.16 -> Plasma/5.16

In D21916#482561, @zzag wrote:

This happens on all platforms with Intel.

In D21916#482461, @zzag wrote:

Now eglCreatePlatformWindowSurface fails with EGL_BAD_MATCH.

So this is kind of embarrassing, but it turns out that EGL_NONE is not defined to 0.

In D21908#482184, @ngraham wrote:

In D21908#482152, @fredrik wrote:

Yeah, I somehow had the idea that we always use GLES on Wayland, which would have made it unaffected by the bug.
It will need a similar patch.

Does D21916 take care of it, or is that patch for something else?

In D21908#482053, @sbergeron wrote:

Is the code here common between X11 and Wayland sessions? Or is there other code involved for Wayland that needs to be addressed separately? 408594 is reproduceable for me on Wayland as well as X11, which is why I ask.

EDIT: a user on the bug report confirmed this works on X11 but the bug is still present on Wayland session, feel free to disregard the original question

In D18377#480824, @zzag wrote:

In D18377#480776, @anemeth wrote:

I just downloaded the KDE Neon 5.16 iso from the website, installed it and updated it

You need an Intel graphics card to reproduce this bug.

A display typeface is a typeface optimized for large headings and billboards.
So the term "display" has nothing to do with computer displays.

In D19867#462617, @davidedmundson wrote:

That'd be a nice easy fix at least.

Here's a patch: https://phabricator.kde.org/P385

I think it might tear because we have the threaded render loop so it's got no reason to be in sync with kwin/anything - but it looks to me to work fine.

Do we actually want the QtQuick rendering to sync to vblank in this case?
If not, the solution could be to set the swap interval for those drawables to zero.

Looks good to me.

In D18377#400445, @zzag wrote:

May it cause issues on GLES?

In D18377#400171, @anemeth wrote:

I tried experimenting what fredrik suggested without luck so far.
@fredrik @zzag is this the correct approach? This gives the exact same result as not using sRGB textures.

In D18377#398821, @zzag wrote:

Hmm, it looks like during each render pass we'll be wasting resources on "sRGB - linear RGB" conversions. Intermediate results should be in linear colorspace.

In D13575#366344, @zzag wrote:

So, if I understand you correctly, we could have either WindowQuadShadow/WindowQuadContents/WindowQuadDecoration/WindowQuadSubSurface or WindowQuadComposite(which is the union of the previously mentioned quads), depending on what an effect would like to do, right?

In D13575#366246, @zzag wrote:

Another way to fix this problem is to render an untransformed window into an off-screen texture, then map it on the screen. The problem with this method is that we probably would need to get rid of different window quad types (e.g. WindowQuadShadow, WindowQuadDecoration, etc), which might break some effects, like the Screenshot. This would probably also fix T4441. We could maybe introduce different flags to control what parts of windows(e.g. shadows, etc) are rendered.

Difficult.

It would be easy to change WindowForceBlurRole from a bool to an int, and have effects increment/decrement the value though.

In D13382#279309, @zzag wrote:

In D13382#279308, @fredrik wrote:

My preferred long term solution to this problem would be to render the window untransformed to a texture, and transform that texture instead of the individual parts. This is something kwin will have to do anyway to implement wayland sub-surfaces in a conformant manner.

Yeah, it sounds better and would work for both X11 and Wayland. So, we don't need D13575, right?

My preferred long term solution to this problem would be to render the window untransformed to a texture, and transform that texture instead of the individual parts. This is something kwin will have to do anyway to implement wayland sub-surfaces in a conformant manner.

Array textures wouldn't help in this case, because all layers must have the same size.

Looks good to me, but I'd also check with @davidedmundson.

@ervin I think you are confusing me with someone else here.

In D10747#237235, @romangg wrote:

Regarding the "drm_fourcc.h" file: do we want to copy it in KWayland's code base or could we use the system one? It's only available on Linux? In this case could we include it as a dummy only on non-Linunx systems? This way we could use the system one on Linux.

Fix issues pointed out by romangg.

In D10750#224860, @romangg wrote:

In D10750#216337, @fredrik wrote:

An issue that this patch does not fully address is switching compositing backends at runtime.

Do we support that at all? The backend is set at startup. Don't think you can change this later on.

Rebase on master.

In D10251#227092, @broulik wrote:

What's the state of this? Bug 391915 just cropped up

Import the context.

Import the context.

An issue that this patch does not fully address is switching compositing backends at runtime.

In D10750#211784, @graesslin wrote:

Concerning the tests: the ones requiring OpenGL work best if module vgem is loaded. That normally makes them pass. The tests regarding keyboard layout need env variable XDG_DEFAULT_LAYOUT being unset or on us.