I think you can do it without copying the image by just copying the relevant parts of the image as multiple uploads in renderPart

i.e

QPoint mainTexturePoint = (geo.topLeft() - partRect.topLeft() + offset) * image.devicePixelRatio());
 m_texture->update(image, texturePos; //main contents

//upload the top line of the image again slightly above the main GL texture
 m_texture->update(image, (texturePos - QPoint(padding,0), QRect(0,0,image.width(), padding);
//left
 m_texture->update(image, (texturePos - QPoint(0,padding)), QRect(0,0,padding, image.height());
//right
 m_texture->update(image, (texturePos - QPoint(image.width(),padding)), QRect(image.width(),0,padding, image));
//bottom
...

Completely untested and arguably the corners would be slightly wrong, but I think it would work out cleaner and faster

In D13575#279112, @davidedmundson wrote:

I think you can do it without copying the image by just copying the relevant parts of the image as multiple uploads in renderPart

i.e

QPoint mainTexturePoint = (geo.topLeft() - partRect.topLeft() + offset) * image.devicePixelRatio());
 m_texture->update(image, texturePos; //main contents

//upload the top line of the image again slightly above the main GL texture
 m_texture->update(image, (texturePos - QPoint(padding,0), QRect(0,0,image.width(), padding);
//leftBecause there's 
 m_texture->update(image, (texturePos - QPoint(0,padding)), QRect(0,0,padding, image.height());
//right
 m_texture->update(image, (texturePos - QPoint(image.width(),padding)), QRect(image.width(),0,padding, image));
//bottom
...

Completely untested and arguably the corners would be slightly wrong, but I think it would work out cleaner and faster

Good point. I think corners would be okay (padding is just 1px).

After thinking for a while, I'm not sure whether uploading each side would work out well. FWIW, pad() is cache friendly and decoration parts are usually small. So, that's not really clear whether uploading relevant parts would be faster. Also, to get correct corners one need to call m_texture->upload() 8 times.

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.

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.

I don't think we need to get rid of anything, but we would need to add a WindowQuadComposite type that would be a union of all the other quads.
The texture coordinates in these quads would be coordinates in the offscreen texture.
Effects that transform quads (wobbly windows, etc.) would need to be changed to split and transform only the composite quads.

In D13575#366324, @fredrik wrote:

I don't think we need to get rid of anything, but we would need to add a WindowQuadComposite type that would be a union of all the other quads.
The texture coordinates in these quads would be coordinates in the offscreen texture.
Effects that transform quads (wobbly windows, etc.) would need to be changed to split and transform only the composite quads.

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#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?

I think all quad types need to be present in the quad list, but:

• Effects are only allowed to transform WindowQuadComposite quads.
• If the window or screen is transformed in any way (except for translations), or if the window has sub-surfaces, the WindowQuadComposite quads will be used to render the window. Otherwise the normal quads are used.

We could also add a flag to force the use of the composite quad type.