Under Linux, resizing a Juce window that does not have a native title bar is slow, painful, and suffers from bad flickering. It’s practically unusable.
This is reproducible in an unmodified JuceDemo application.
Resizing windows all works just fine for me in Ubuntu… (both native or juce-style title bars)…
That’s strange because someone else was able to reproduce the problem as well. The JUCE window turns completely black and only moves 1 pixel at a time, slowly, towards the new size.
Which distro?
Ubuntu 12.04 Desktop i386
Same as me! That’s kind of odd.
Does one of you have some kind of compositing switched on, and the GPU is doing the work?
Bruce
I tested it under Ubuntu 12.04 64bit (custom build, KXStudio), using the KDE desktop.
With or without desktop effects the problem remains - it’s painfully slow to resize a window, cpu goes to the max. (50% here because of DualCore)
I say the same as in the other thread:
my theory is that Juce is requesting a repaint everytime the window is resized. If true, I think it should instead wait a little bit (1/4 of a second ?) and then trigger a repaint.
I see that under a native titlebar the window doesn’t resize automatically (KDE’s kwin), but waits a little bit after the user action to repaint the window, thus my theory^ there.
I haven’t tried in any other desktops, but I can do that if required.
I don’t think that’s the cause. It seems like there is some kind of “feedback loop” having to do with component notification messages during the resize. I’m totally crippled on Linux though, I have no idea how to debug, set a break point, or do anything useful (compared to Visual Studio) so I’m at a loss how to even proceed.
Yeah, there’s definitely no problem with repainting each time it changes.
Most likely this is the window manger fighting against the app’s attempts to move the window, but I’m really not sure how to track it down either. The fact that I have no problems could mean that it’s just some kind of WM setting.
Just tried with metacity (juce titlebar), same thing.
NOTE: the resize issues only happen when some effects are in place.
The LayerEffects app firstly resizes just fine, but when I enable some fx it gets really sluggish resize.
EDIT: the more effects I apply, the more sluggish the resize becomes.
Metacity prints some warning messages when the LayerEffects app is launched:
Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x1800007 (Layer Effe)
Window manager warning: meta_window_activate called by a pager with a 0 timestamp; the pager needs to be fixed
[quote=“falkTX”]The LayerEffects app firstly resizes just fine, but when I enable some fx it gets really sluggish resize.
EDIT: the more effects I apply, the more sluggish the resize becomes.
[/quote]
Well that makes sense because most of the effects are unoptimized and they can become slow at large sizes.
I think going forward, we should do tests with JuceDemo, or better yet find out if it can be reproduced in a simple empty application that has only a DocumentWindow.
Re; that _NET_ACTIVE_WINDOW warning - I’ve just checked in a version now that should get the timestamp correct… However, on my system, it never showed that warning, and doesn’t actually provide a timestamp value, so I guess it’s only some WMs that care about this. I’d be interested to hear whether what I’ve changed removes the warning for you.
just checked, same thing happens.
for the record the exact message is:
Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x3a00006 (JUCE Demo!)
Window manager warning: meta_window_activate called by a pager with a 0 timestamp; the pager needs to be fixed.
that message is printed when I start JuceDemo and everytime I do a mouse-click on it.
Well I’m a bit stumped then. I added a method getUserTime which AFAICT should work, but if it doesn’t then I’ve no idea how the WM expects that time to be correct.