The simple “LuaBridge Demo” window, whose content component contains only two TextEditor objects, resizes in a very clunky and slow way. Other X11 Windows in Ubuntu resize fine. Try it out (There’s a Makefile):
I’ve seen this happen here too, it’s very random.
Usually I go for native titlebar, which works just fine.
Yep, that helped a ton. Jules?
Yep, that helped a ton. Jules?[/quote]
Hehe, sorry about that.
From what I’ve seen it doesn’t happen in all the systems. Different Window Managers give different results.
Multiple monitors also influence this.
Sadly my X11 knowledge is pratically 0, so I never got to try to fix this issue.
Which Ubuntu are you using? Remember, Unity has a bunch of weird extensions, which is why the native toolbar generally works better (especially for things like dragging between multiple monitors).
If you mean the weird black screen / garbage while size dragging, on the 11.xx Ubuntus, I’ve generally tracked that behavior back to actual focus. A quick test is:
Switch to native tool bar.
Maximize.
Drag the mouse to the top of the screen and see if you can minimize.
If you can’t, then, repeat the test with two windows open (you and another app), toggle between them before maximizing. Once the component related to the peer has focus, the problem is generally gone, and resize/redraw works much better. Personally, I’ve found focus to be an ongoing oddness in Juce. Not just under Linux. I can almost always force the behavior I want, but it is something I run into in every app.
Sorry for reviving an old thread, but this is still a big problem and I think I’ve found a clue about how to solve this.
I believe the problem is that NET_WM_SYNC_REQUEST isn’t implemented. Here is a video of chrome running with and without NET_WM_SYNC_REQUEST: Chrome resize without and with _NET_WM_SYNC_REQUEST - YouTube
Here is an explanation I found in the Chrome source code:
1. Desktop compositor sends client message _NET_WM_SYNC_REQUEST to notify
about the incoming resize
2. Desktop compositor WM resizes chrome browser window.
3. Desktop compositor waits on an alert on value change of a XSYNC counter
on chrome window.
4. Chrome handles the ConfigureNotify event, and renders a new frame.
5. Chrome increases the XSYNC counter on chrome window.
6. Desktop compositor gets the alert of counter change, and draws a new
frame with new content from chrome.
7. Desktop compositor responses user mouse move events, and starts a new
resize process, go to step 1.
(source: 84c7124e087d5dbfa5459b23c01c6aabf9bb7473 - chromium/src - Git at Google)
I attempted to implement this myself (using Qt as a reference), but my X11 knowledge isn’t good enough. I was wondering if anyone else, or maybe the JUCE team could fix this.
4 Likes
I can confirm that @timothyschoen is correct. _NET_WM_SYNC_REQUEST (along with _NET_WM_SYNC_REQUEST_COUNTER) will stop the window manager from compositing frames that are not ready to be displayed.
Here is a quick test I put together…
Here is the test app for reference, with my JUCE fork as a submodule:
2 Likes
Oh my God, thank you. I changed OS as soon as I had to test window resizing.
1 Like