Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Gtk4 window gets clipped within container #6223

Closed
keis opened this issue Apr 24, 2021 · 9 comments · Fixed by #6229
Closed

Gtk4 window gets clipped within container #6223

keis opened this issue Apr 24, 2021 · 9 comments · Fixed by #6229
Labels
bug Not working as intended renderer Related to Sway's renderer

Comments

@keis
Copy link

keis commented Apr 24, 2021

Please fill out the following:

output * bg /usr/share/backgrounds/default.png fill
exec "gtk4-demo"
  • Description:
    In a regression from sway 1.5 Gtk4 windows (in my example the gtk4-demo) render with a weird clipping within the sway container.

I was able to git bisect to this commit a6544f5

20210424_11h13m10s_grim
@keis keis added the bug Not working as intended label Apr 24, 2021
@emersion emersion added the renderer Related to Sway's renderer label Apr 24, 2021
@emersion
Copy link
Member

Probably related to a confusion between window geometry and surface geometry.

@kennylevinsen
Copy link
Member

The window seems placed wrong, look at how close the upper left corner button is to the edge compared to the right.

@emersion
Copy link
Member

I think it's not mis-placed, but it's just clipped? The close button is cut in the middle.

@keis
Copy link
Author

keis commented Apr 24, 2021

Indeed. For reference this is what the demo window looks like when floating

20210424_14h40m57s_grim

@kennylevinsen
Copy link
Member

Ah true, thought a thick margin was intended, didn't see a close button was cut.

@nagisa
Copy link

nagisa commented Apr 24, 2021

May be relevant to this: at some point I reported a similar issue (shadows part of window decoration not disappearing when window is tiled) to #gtk on IRC and was told that gtk4 does not yet implement the xdg-shell protocol or something along those lines.

@emersion
Copy link
Member

GTK4 does implement xdg-shell, that's the only way they can display a window on screen. Maybe they don't implement the tiled states, but that would be surprising since GNOME uses them as well.

@nagisa
Copy link

nagisa commented Apr 25, 2021

Screenshot showing shadows from a gtk4 window being drawn over other windows tiled to the top and left of the gtk4-demo window

For reference the the image for what I'm talking about: notice the shadows being drawn over the windows tiled to the left and top of the gtk4-demo window. You can also notice that it retains a rounded corner on the top left corner of the window. This is not as visible in the other screenshots due to the dark backgrounds in use.

@kennylevinsen
Copy link
Member

screenshot

Indeed, gtk4 does not seem to react to tiling (although it may be fixed already), and we end up not accounting for the positive x/y toplevel geometry.

kennylevinsen added a commit to kennylevinsen/sway that referenced this issue Apr 25, 2021
@kennylevinsen
desktop/render: Pass explicit clip box to render
fab0c20 
render_surface_iterator previously deduced the clip box from an optional
container passed with render data. This causes problems when offsets in
view geometry need to be compensated for in the clip dimensions.

Instead, prepare the clip box in render_view_toplevels where the offsets
are being applied, and compensate for them immediately.

A similar compensation is applied to render_saved_view.

Closes: swaywm#6223
@kennylevinsen kennylevinsen mentioned this issue Apr 25, 2021
Merged
emersion pushed a commit that referenced this issue Apr 26, 2021
@kennylevinsen @emersion
desktop/render: Pass explicit clip box to render
4e6f515 
render_surface_iterator previously deduced the clip box from an optional
container passed with render data. This causes problems when offsets in
view geometry need to be compensated for in the clip dimensions.

Instead, prepare the clip box in render_view_toplevels where the offsets
are being applied, and compensate for them immediately.

A similar compensation is applied to render_saved_view.

Closes: #6223
RagnarGrootKoerkamp pushed a commit to RagnarGrootKoerkamp/sway that referenced this issue Jun 17, 2021
@kennylevinsen @RagnarGrootKoerkamp
desktop/render: Pass explicit clip box to render
af67fb2 
render_surface_iterator previously deduced the clip box from an optional
container passed with render data. This causes problems when offsets in
view geometry need to be compensated for in the clip dimensions.

Instead, prepare the clip box in render_view_toplevels where the offsets
are being applied, and compensate for them immediately.

A similar compensation is applied to render_saved_view.

Closes: swaywm#6223
emersion pushed a commit to emersion/sway that referenced this issue Jun 23, 2021
@kennylevinsen @emersion
desktop/render: Pass explicit clip box to render
4ef6023 
render_surface_iterator previously deduced the clip box from an optional
container passed with render data. This causes problems when offsets in
view geometry need to be compensated for in the clip dimensions.

Instead, prepare the clip box in render_view_toplevels where the offsets
are being applied, and compensate for them immediately.

A similar compensation is applied to render_saved_view.

Closes: swaywm#6223
(cherry picked from commit 4e6f515)
emersion pushed a commit to emersion/sway that referenced this issue Jun 24, 2021
@kennylevinsen @emersion
desktop/render: Pass explicit clip box to render
14522df 
render_surface_iterator previously deduced the clip box from an optional
container passed with render data. This causes problems when offsets in
view geometry need to be compensated for in the clip dimensions.

Instead, prepare the clip box in render_view_toplevels where the offsets
are being applied, and compensate for them immediately.

A similar compensation is applied to render_saved_view.

Closes: swaywm#6223
(cherry picked from commit 4e6f515)
emersion pushed a commit that referenced this issue Jun 24, 2021
@kennylevinsen @emersion
desktop/render: Pass explicit clip box to render
2660c0c 
render_surface_iterator previously deduced the clip box from an optional
container passed with render data. This causes problems when offsets in
view geometry need to be compensated for in the clip dimensions.

Instead, prepare the clip box in render_view_toplevels where the offsets
are being applied, and compensate for them immediately.

A similar compensation is applied to render_saved_view.

Closes: #6223
(cherry picked from commit 4e6f515)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Not working as intended renderer Related to Sway's renderer
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix offset toplevel geometry issue kennylevinsen/sway
4 participants
@keis @kennylevinsen @emersion @nagisa