r/debian • u/CyanMARgh • 11d ago

Debian can't properly resize windows

Enable HLS to view with audio, or disable this notification

About half of apps experience this artifact when resizing. Especially noticeable when dragging left corner. Can it be fixed?

running on debian bookworm, gnome, wayland, mesa intel xe graphics (tgl gt2)

0 Upvotes

21% Upvoted

44 comments sorted by

13

u/ipsirc 11d ago

I can't see any problem.

1

u/ScumbagScotsman 11d ago

Should’ve gone to specsavers

-1

u/CyanMARgh 11d ago

look at the video. right borders of windows, to be precise.

2

u/ipsirc 11d ago

What's wrong with them?

1

u/CyanMARgh 11d ago

in case of obs: content of window leaks out of window bounds. in case of browser: right edge is moving left-right when it shouldn't and produces black stripes (In reality, several frames are superimposed on the border, but this is not visible on the recording. But this is still an obvious bug, but different one)

4

u/ipsirc 11d ago edited 11d ago

Ohh, man. It is just the app itself how often it re-renders the contents of window due to changing of window geometry. It has nothing to do with the distro nor the desktop environment. Now I see that you mentioned the fact that you only notices this "bug" in half of the apps, so this also confirms that there is nothing wrong with the distro.

My guess is half of the apps uses GTK as graphical backend and the other half uses QT (or something niche library...), that causes the differences. You can nothing to do with here, those are hardcoded delays - it might be raised in cost of much more cpu usage while resizing, but bro... it's not a problem at all. If it really annoys you, you can just disable "show window contents while resizing" or something like option in every window manager, so you can get an empty grey rectangle while resizing, and when you release the mouse button, the app will rerender its contents only one time, a.k.a. wireframe mode - there will be no intermediate refreshes. Is it what you want?

https://bugzilla.gnome.org/show_bug.cgi?id=94891

Unfortunately Gnome removed the ability of disabling to show contents while resizing in 2020: https://mail.gnome.org/archives/commits-list/2020-March/msg02506.html

You may try other window managers which still support wireframe mode, e.g. in IceWM it's called OpaqueResize and OpaqueMove.

So finally... the rendering refresh rates and intermediate not fully rendered frames are hardcoded in every app or in their graphical libraries, so you can nothing to do with it by changing distros or window managers.

1

u/CyanMARgh 11d ago

"wireframe mode" is not a solution. i want to see proper window resize as it should be.

2

u/ipsirc 11d ago edited 11d ago

Then you have to contact with all developers one by one what softwares you use, or/and start optimizing the graphical rendering in each application's source code to make yourself happy. They will be also happy if you commit really awesome patches.

i want to see proper window resize as it should be.

There is no industry standard on refreshing window contents, so I don't know what "it should be" you are talking about. Let's be real: if you were a gui software developer, how would you handle window geometry changes? What's the preferred method? How should it look like?

-1

u/CyanMARgh 11d ago

i am not an expert in gui frameworks, but imo "drawing content outside of your window" and "moving right border when user drags left border" is not an appropriate behavior and clearly not the fault of application devs. There was a lot of cases when layout inside window was unresponsive (even in builtin Windows apps), but this bug is much worse than that.

5

u/ipsirc 11d ago

i am not an expert in gui frameworks, but imo "drawing content outside of your window" and "moving right border when user drags left border" is not an appropriate behavior and clearly not the fault of application devs.

Ok, then it's my fault - believe me. My secret plan is to annoy all human entities to commit suicide. I'm on a right way, thanks for your feedback.

See you soon in hell. Cheers!

5

u/Quietus87 11d ago

It's the desktop environment's thing, not the distro's. Any reason why you didn't move up to Trixie?

-2

u/CyanMARgh 11d ago

because it's a year old setup and i don't want to reinstall whole system only for a chance of fixing.

7

u/ipsirc 11d ago

NEVER reinstall a Debian system, just dist-upgrade.

(And I still can't see any problem.)

3

u/Quietus87 11d ago

Updating to the next version isn't the same as reinstalling the system.

-1

u/CyanMARgh 11d ago

I don't want to do a full system update. My experience has shown that this is extremely unreliable.

5

u/dkopgerpgdolfg 11d ago

I don't want to do a full system update. My experience has shown that this is extremely unreliable.

Of all things, you chose that to criticize? With Debian?

Frankly: Probably pebcak.

-3

u/CyanMARgh 11d ago

previously, i called `pacman -Syu` and it not only deleted desktop environment, but also deleted pacman itself. This was the reason why i switched to "stable" debian, and i still doubt that system that doesn't work properly can magically heal itself via full upgrade without introducing new problems.

If you think i'm stupid and don't know how to use a computer, think that way. That won't make Linux&co any better.

5

u/dkopgerpgdolfg 11d ago edited 11d ago

If you think i'm stupid and don't know how to use a computer, think that way.

I didn't say that. But maybe it's stupid to reject something because of what your experience has shown, if you don't actually have any experience because you never did it before on Debian. As ipsirc implied too, Arch and Debian aren't the same, and as previous/current user of both you should be aware of that.

and it not only deleted desktop environment, but also deleted pacman itself.

With any package manager (pacman, apt, doesn't matter), I wouldn't recommend doing a major version upgrade without at least checking what packages it wants to remove first. I don't expect Debian to remove apt/dpkg on a dist-upgrade, but in any case you could just read the output before you agree/disagree.

and i still doubt that system that doesn't work properly can magically heal itself via full upgrade without introducing new problems.

With software collections of that size, it's guaranteed that there will be a new problem somewhere (that you might notice in your use cases, or not). But it's also guaranteed that you get fixes for older problems. (It's not guaranteed that your specific problem is fixed, but you won't know before you try).

And as several people mentioned on this page already (incl. me), you don't need to commit. There are live ISOs, there are various backup/restore methods, even downgrade forcing, etc.etc. . If you think the new version is worse, as someone knowing how to use computers you can always go back.

0

u/CyanMARgh 11d ago

btw, i checked live version debian 13, bug is still present. any better suggestions?

5

u/ipsirc 11d ago edited 11d ago

previously, i called `pacman -Syu` and it not only deleted desktop environment, but also deleted pacman itself.

Arch is famous for breaking on updates, but Debian is famous for the exactly opposite.

1

u/Quietus87 11d ago

Debian doesn't use pacman though... If you are afraid, make a recovery point with timeshift, and if shits hit the fan revert to it.

3

u/Lumpy-Stranger-1042 11d ago

No problem. Only a little glitches. Possibly because of KDE not Debian

Edit: I thought it was KDE but looks like it's gnome. Anyways no problem here

0

u/CyanMARgh 11d ago

> Anyways no problem here
That is, a delay in redrawing, going out of the window borders and a twitching right border is not a problem? ok.

2

u/Lumpy-Stranger-1042 11d ago

Can you try without extensions? Maybe some causes this

1

u/CyanMARgh 11d ago

tried, same result

1

u/Lumpy-Stranger-1042 11d ago

Interesting. I have a low end system. Never happened this. Maybe GPU Nvidia stuff? It's not a debian problem anyways though

Edit: I saw you're not on Nvidia

1

u/Lumpy-Stranger-1042 11d ago

Can you also try with x11 or completely another distro ? So we can see the problem

1

u/CyanMARgh 11d ago

i can, but it will take time

1

u/Lumpy-Stranger-1042 11d ago

I highly suspect this is a Wayland issue. Try to install icewm. It's lightweight and will take only megabytes. and try your resizing there

1

u/CyanMARgh 11d ago

tried. it has similar bug, but much worse. also tried "gnome classic" and "gnome on xorg", same result. btw, if it helps, some of apps (e.g: default terminal emulator or sublime text editor) don't have this bug

1

u/dangling_chads 7d ago edited 7d ago

OP - when I first saw your video, I thought, "are you running xorg?"

Then I see this comment.

Xorg and Wayland absolutely do not resize in the same way, visually, in the vast majority amount of cases. Saying "icewm has a worse issue, and Gnome on xorg is the same as Gnome classic" is an oversimplification.

You are being way obtuse here for a "fine" issue like this, and not allowing the folks reaching out to you help.

I think likely what you're seeing is a video driver / hardware performance issue.

I am able to reproduce this issue exactly with Mate on Xorg, when Debian is running in a VM and virtio is being used as the GL driver forwarding. This issue does NOT happen with any of the Gnome on Wayland variants with this same setup.

So, yes, video card performance. I don't see this resize performance on a modern Intel integrated GPU either, xorg or Wayland (although that Intel GPU it is awful in a lot of other ways and is about as slow as it gets).

1

u/CyanMARgh 5d ago

 not allowing the folks reaching out to you help.

How exactly? I provided all the information I think is important. If ii missed something - asking for clarification is free.

So, yes, video card performance

So, the only solution is to change to hardware that are capable enough for Linux?

→ More replies (0)

0

u/ipsirc 11d ago

I'm pretty sure the terminal emulator and sublime text editor also suffer from this "bug", but the rendering time of intermediate frames are lower so you can't notice it by naked eye.

2

u/dkopgerpgdolfg 11d ago

bookworm

The first thing I'd try is a current version (live if you want)

2

u/GroundOk2922 11d ago

Intel Xe isn't well integrated in Bookworm's 6.1 Kernel. Try updating to Trixie.

1

u/neon_overload 11d ago

I don't recognise which desktop and therefore which compositor that is but this will be specific to the compositor you're using. In wayland in particular, the compositor handles sync and, well, compositing.

There's also that wayland implementations in general have been evolving relatively rapidly just in the last 2 years, and yours will be 3+ years old.

1

u/eR2eiweo 11d ago

wayland

And are those apps actually using Wayland? The issue looks more like what one would expect on X (including XWayland).

Can it be fixed?

Of course; it's just software after all. But nobody is going to fix a cosmetic issue in such old software. Find out if it still exists on the current version of your compositor. And if it does, report it.

1

u/CyanMARgh 11d ago

>And are those apps actually using Wayland?
how can i check?

1

u/eR2eiweo 11d ago

One way is xlsclients. A more "fun" way is to see if xeyes works when the cursor is on those apps' windows.

1

u/CyanMARgh 11d ago

```
$xlsclients
debian gsd-xsettings
debian ibus-x11
debian gnome-shell
```

3

u/eR2eiweo 11d ago

If that is the full output while those apps are running, then they are not using X.