Maybe you could add an explanation of what the HPC actually does and why it only affects OpenGL?

In D13382#274808, @fvogt wrote:

Maybe you could add an explanation of what the HPC actually does and why it only affects OpenGL?

Someone can put many small subtextures into one big texture so called a texture atlas. By doing that way, he/she/it can avoid calling multiple times glBindTexture. But there is a problem when using linear filter. If we scale the atlas, neighboring texels will be sampled. Sampling neighbors near edges of the subtextures can cause so known texture bleeding.
One way to fix the texture bleeding is by using an array texture. I think that's not possible to use array textures in KWin right now.
Another ugly solution is the half pixel correction. With that, we add/subtract "0.5"(half texel size) to/from texture coordinates to snap them to pixel centers. By doing that, only desired pixels will be sampled.
Yet another solution is to pad the subtextures. Depending on what decoration borders are (are they solid? are they gradients?), it may produce not quite the best results.

It affects only OpenGL because that's specific only to OpenGL, I believe we don't need HPC for XRender.

I might be wrong so I will be glad if someone correct me.

Just for comparison.

Before

After

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

@zzag: I meant putting it into the description - I already know what this is about :D

It seems to me like this breaks rendering of some applications sometimes - sometimes yakuake appears blurry on unhide and every second redraw after that is also blurry.

In D13382#275632, @fredrik wrote:

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

Agree, in this particular case, it wouldn't help.

In D13382#275725, @fvogt wrote:

@zzag: I meant putting it into the description - I already know what this is about :D

Oh, sorry. :D

It seems to me like this breaks rendering of some applications sometimes - sometimes yakuake appears blurry on unhide and every second redraw after that is also blurry.

Yeah, I've noticed similar bug, but only when resizing system settings to a minimum possible size (with mouse). I'll dig what's causing that.

In D13382#275726, @zzag wrote:

Yeah, I've noticed similar bug, but only when resizing system settings to a minimum possible size (with mouse). I'll dig what's causing that.

It seems like it's caused by the Resize Window effect.

Update

The resize window effect sets PAINT_WINDOW_TRANSFORMED. If PAINT_WINDOW_TRANSFORMED is set, linear filter will be used.

Furhter considerations

Move half pixel correction stuff to scene_opengl.cpp, e.g.

WindowQuad withHalfPixelCorrection(const WindowQuad &quad)
{
    WindowQuad newQuad(quad.type());
    if (quad.uvAxisSwapped()) {
        newQuad[0] = WindowVertex(...);
        // ....
    } else {
        // ...
    }
    return newQuad;
}

and use it when filling leaves, e.g.

void SceneOpenGL2Window::performPaint(int mask, QRegion region, WindowPaintData data)
{
    // ...
    foreach (const WindowQuad &quad, data.quads) {
        switch (quad.type()) {
        case WindowQuadDecoration:
            quads[DecorationLeaf].append(withHalfPixelCorrection(quad));
            break;
        // ...
        }
    }
    // ...
}

And at this point, I'm out of ideas. Because the problem with the linear filter is still there (content/decoration quads are blurry when they don't have to be). The most straightforward way to fix the problem is to adjust vertices, but that's unacceptable solution.

Any other ideas how to fix the seams?

Hm. How does the linear filtering in combination with this patch cause the blurryness?

Also, I have the impression that this patch changes the appearance of windows just slightly, fonts appear sharper. Is that actually possible or is it just a placebo?

@zzag
I'm a bit lost as to what you're saying the status of this is. Are we saying this does cause bluriness?

If there are any drawbacks, we could avoid doing the half pixel correction on the Window Contents. They're not in an atlas so standard clamp to edge will work just fine.

In D13382#277916, @fvogt wrote:

Hm. How does the linear filtering in combination with this patch cause the blurryness?

In D13382#277917, @davidedmundson wrote:

@zzag
I'm a bit lost as to what you're saying the status of this is. Are we saying this does cause bluriness?

My assumption why window content looks blurry: a part of a texture that is being mapped onto content rect is a little bit smaller(by 1px), so linear filter kicks in and "blurs" content.

If there are any drawbacks, we could avoid doing the half pixel correction on the Window Contents. They're not in an atlas so standard clamp to edge will work just fine.

So, here's window content without half pixel correction:

It looks like OpenGL scene clamps textures to edge by default. https://github.com/KDE/kwin/blob/master/plugins/scenes/opengl/scene_opengl.cpp#L1512

@davidedmundson

Clamp to edge won't help on X11, because as WindowPixmap::contentsRect docs state

The geometry of the Client's content inside the pixmap. In case of a decorated Client the
pixmap also contains the decoration which is not rendered into this pixmap, though. This
contentsRect tells where inside the complete pixmap the real content is.

It looks like this on X11

Content of dolphin window texture on X11.

On Wayland, it seems to be a different case:

Content of kate window texture on Wayland.

So, half pixel correction makes sense only on Wayland, right?

In D13382#277916, @fvogt wrote:

Also, I have the impression that this patch changes the appearance of windows just slightly, fonts appear sharper. Is that actually possible or is it just a placebo?

Are you using subpixel rendering?

In D13382#277983, @zzag wrote:

In D13382#277916, @fvogt wrote:

Also, I have the impression that this patch changes the appearance of windows just slightly, fonts appear sharper. Is that actually possible or is it just a placebo?

Are you using subpixel rendering?

Yes.

In D13382#277984, @fvogt wrote:

Yes.

The worst case: the half pixel correction(to be precise the nearest neighbor filter) messed fonts.
The best case: your mind plays tricks on you. :D

Need to check how fonts are rendered with/without HPC.

If it indeed messes fonts, the only viable solution is padding, I guess.

I'll try to implement the approach with padding. Does Qt have something to clamp QImages to edge? Currently, I'm thinking about implementing QImage pad(const QImage &src, int padding).

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.

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?

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?

It depends on whether we want it as a temporary solution.