Reload Shm texture when buffer size changes
ClosedPublic

Authored by romangg on Jan 22 2019, 11:13 AM.

Details

Summary

Shm textures via Gl must be reloaded in case their size changes.

Test Plan

testShmBufferSizeChangeOnSubSurface passes.

Diff Detail

Repository
R108 KWin
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
romangg created this revision.Jan 22 2019, 11:13 AM
Restricted Application added a project: KWin. · View Herald TranscriptJan 22 2019, 11:13 AM
Restricted Application added a subscriber: kwin. · View Herald Transcript
romangg requested review of this revision.Jan 22 2019, 11:13 AM
davidedmundson added inline comments.
scene.cpp
1083 ↗(On Diff #50055)

It's a bit weird to do all the adding/removing/subtree/changes from all other events in updateBuffer but handle resizing in a special case way.

We should be able to just compare size here.
And hook sizes changes up to subSurfaceTreeChanged on the wayland side

romangg added inline comments.Jan 22 2019, 1:38 PM
scene.cpp
1083 ↗(On Diff #50055)

Yea, that's a good idea. Then we also don't need the QObject parent.

romangg updated this revision to Diff 50074.Jan 22 2019, 5:22 PM

I realized it only affects the Gl shm case. Decided to go less nuclear on it
and just reload the texture in case of size mismatch.

romangg retitled this revision from Delete WindowPixmaps of resized sub-surfaces to Reload Shm texture when buffer size changes.Jan 22 2019, 5:25 PM
romangg edited the summary of this revision. (Show Details)
romangg marked 2 inline comments as done.
romangg added inline comments.
scene.cpp
1083 ↗(On Diff #50055)

Decided to do it in a different way.

graesslin accepted this revision.Jan 22 2019, 5:33 PM
This revision is now accepted and ready to land.Jan 22 2019, 5:33 PM

Could this be our firefox issue?

Could this be our firefox issue?

That would be nice, but I'm afraid not. It's nothing in the rendering code, we can see they just stop sending us frames.
I tried it anyway, no luck :(

romangg added a dependent revision: D18465: [platforms/wayland] Multi output support.

They don't seem dependent.

romangg marked an inline comment as done.Jan 23 2019, 12:59 PM

romangg added a dependent revision: D18465: [platforms/wayland] Multi output support.

They don't seem dependent.

You can apply them independently to the code base, but if you try to grab a pointer and then the cursor size changes in the nested session, without this patch, your host session will crash.

If dependent means: apply one after the other to code base, they are not dependent.

Could this be our firefox issue?

That would be nice, but I'm afraid not. It's nothing in the rendering code, we can see they just stop sending us frames.

I have one more idea for this: WindowPixmap keeps the buffer referenced as long as it's alive. So we basically block two buffers all the time. Maybe we could change the behavior to deep copy a used buffer, so that we can release them faster.

This revision was automatically updated to reflect the committed changes.