fyne-io
Window periodically misdraws into a smaller area on startup
Checklist
- [X] I have searched the issue tracker for open issues that relate to the same problem, before opening a new one.
- [X] This issue only relates to a single bug. I will open new issues for any other problems.
Describe the bug
Seems to only happen on Linux, and on Ubuntu 24.04 it happens up to 50% of the time, much more often than 22.04, according to Supersonic user reports. When this happens the window canvas also isn't responsive to mouse events at all.
I'm really tempted to mark this as a blocker since it is a huge negative to the UX of Fyne apps on Linux, at least on whatever distros are affected. Though manually resizing the window does fix it when it gets in this state.
How to reproduce
Launch a Fyne app on Ubuntu 24.04 until it shows up misdrawn
Screenshots
Screenshot from a Supersonic user:
Example code
n/a
Fyne version
develop
Go compiler version
n/a
Operating system and version
Linux (especially Ubuntu 24.04)
Additional Information
No response
I'll just share my incredibly hacky workaround here (which replaced my previous, ineffective attempt at a workaround) in case anyone else is affected: https://github.com/dweymouth/supersonic/commit/2736fe9955006444eb3bb58181b5e6b1bee68c61
I send a resize event through X11 shortly after the window is shown, so that if it ends up in the misdrawn state it will be forced out of it
I can also confirm this is happening on Windows as well. Not created a workaround yet.
This also happens with native Wayland builds (go build -tags wayland) according to user reports
marking this as blocker since it happens quite frequently to a lot of users of Fyne apps, and apparently not just on Linux either
System info from an affected user. They seem to see the issue on 10-20% of startups (and all of my attempted workarounds in app code have been at best partially effective)
I'm experiencing the same issue. In my setup, I have AdaptiveGrid with 2 lists inside. List items randomly appear too narrow. Reproducible in both wayland & X.
EDIT: I noticed this only happens when list widgets are wrapped inside a custom struct.
That may be an unrelated issue... If you are extending a widget and don't do it currently the renderer can fail to get Resize right - did you call ExtendBaseWidget?
@andydotxyz yes, I can reproduce it with and without ExtendBaseWidget:
type myList struct {
*widget.List
// same behavior when extending `widget.List`
}
// ...
l := myList{widget.NewListWithData(...)}
l.ExtendBaseWidget(l)
// This works fine:
l := widget.NewListWithData(...)
Resizing the window does not fix list's width.
Behavior without custom struct (and 90% of time with custom struct):
Behavior with custom struct 10% of time:
(Please don't be confused by Windows-like path on screenshot, this is a Linux app that communicates with another Windows client app)
Your code is creating two lists (or two list pointers, depending on the setup) - this will confuse things. Try this instead:
type myList struct {
widget.List
// same behavior when extending `widget.List`
}
// ...
l := myList{}
l.Bind(...)
l.ExtendBaseWidget(l)
If you call a widget constructor inside your widget constructor then (to simplify a complex problem) the UI does not know which of the two you are rendering. Instead instantiate your struct with the parent widget embedded directly (not with a pointer) and then configure it using the inherited methods or fields.
@dweymouth for what it's worth I wasn't able to reproduce the hacky fix in my environment (X.Org X Server 1.21.1.14). I used it to resize to the same dimensions I started with at least, and had the same half-sized startup pretty frequently.
Resizing to the same size will be a no-op because the window layout won't be called.
I just tried adding 1 to both the width and height with no change, still am able to reproduce. It looked like the example didn't change the size which is why that was my first try. I had to change one line of the C though because my compiler was complaining about an incompatible pointer type on the windows argument to find_windows_by_pid, so actually that might be my issue.
One last test - create the window larger, and then resize it down in the workaround delay - I think I also saw a resize up not make a difference on one test app...
We are going to try and resolve this in 2.5.x but there is a suspicion it gets resolved with 2.6.0 updates which we are trying to bring forward...
Good catch @andydotxyz, per our discussion elsewhere I tried to avoid C and just added
go func() {
time.Sleep(100 * time.Millisecond)
mainWindow.Resize(fyne.NewSize(defaultWidth, defaultHeight-1))
}()
and that seems to be an effective (and cross platform, presumably) workaround
I spoke too soon, while this was an improvement I'm still seeing this issue, just less frequently. I suspect sometimes 100ms isn't enough, but I'm not confident what the root cause is.
It would be interesting to test this against develop now that we have begun the threading changes...
In my tests this seems to be resolved with the new threading :)
Please do re-open with an easy reproduction step if you see this again!
I am going to reopen this since it seems to still happen with -tags wayland (though it does seem to be fixed for other platforms in my testing)
It seems to me a different issue (but with similar outcome). The former was a race condition for any Linux systems, but the latter maybe more reliably produced but only on Wayland.
That said I have not been able to recreate it using Weston.
OK in further testing it does seem to be resolved on wayland for me, somewhere in between the first alpha for 2.6 and the final release something must have fixed it. I still have #5357 but we can finally close this one out.