# Non-native Window resizing painful, even in JuceDemo
**URL:** https://forum.juce.com/t/non-native-window-resizing-painful-even-in-jucedemo/9168
**Category:** Linux
**Created:** [August 29, 2012, 5:13am UTC](https://forum.juce.com/t/non-native-window-resizing-painful-even-in-jucedemo/9168 "2012-08-29T05:13:01Z")
**Posts on this page:** 15
**Page:** 1
### Author:  [@TheVinn](https://forum.juce.com/u/TheVinn)
#### Post date: [August 29, 2012, 5:13am UTC](https://forum.juce.com/t/non-native-window-resizing-painful-even-in-jucedemo/9168/1 "2012-08-29T05:13:01Z")
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.
---
### Author:  [@jules](https://forum.juce.com/u/jules)
#### Post date: [August 29, 2012, 6:55am UTC](https://forum.juce.com/t/non-native-window-resizing-painful-even-in-jucedemo/9168/2 "2012-08-29T06:55:06Z")
Resizing windows all works just fine for me in Ubuntu… (both native or juce-style title bars)…
---
### Author:  [@TheVinn](https://forum.juce.com/u/TheVinn)
#### Post date: [August 29, 2012, 8:33am UTC](https://forum.juce.com/t/non-native-window-resizing-painful-even-in-jucedemo/9168/3 "2012-08-29T08:33:01Z")
> [@jules](#):
>
> 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.
---
### Author:  [@jules](https://forum.juce.com/u/jules)
#### Post date: [August 29, 2012, 8:39am UTC](https://forum.juce.com/t/non-native-window-resizing-painful-even-in-jucedemo/9168/4 "2012-08-29T08:39:33Z")
Which distro?
---
### Author:  [@TheVinn](https://forum.juce.com/u/TheVinn)
#### Post date: [August 29, 2012, 9:33am UTC](https://forum.juce.com/t/non-native-window-resizing-painful-even-in-jucedemo/9168/5 "2012-08-29T09:33:23Z")
> [@jules](#):
>
> Which distro?
Ubuntu 12.04 Desktop i386
---
### Author:  [@jules](https://forum.juce.com/u/jules)
#### Post date: [August 29, 2012, 9:35am UTC](https://forum.juce.com/t/non-native-window-resizing-painful-even-in-jucedemo/9168/6 "2012-08-29T09:35:53Z")
Same as me! That’s kind of odd.
---
### Author:  [@Bruce\_Wheaton](https://forum.juce.com/u/Bruce_Wheaton)
#### Post date: [August 29, 2012, 5:57pm UTC](https://forum.juce.com/t/non-native-window-resizing-painful-even-in-jucedemo/9168/7 "2012-08-29T17:57:10Z")
Does one of you have some kind of compositing switched on, and the GPU is doing the work?
Bruce
---
### Author:  [@falkTX](https://forum.juce.com/u/falkTX)
#### Post date: [August 29, 2012, 7:28pm UTC](https://forum.juce.com/t/non-native-window-resizing-painful-even-in-jucedemo/9168/8 "2012-08-29T19:28:35Z")
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.
---
### Author:  [@TheVinn](https://forum.juce.com/u/TheVinn)
#### Post date: [August 29, 2012, 8:25pm UTC](https://forum.juce.com/t/non-native-window-resizing-painful-even-in-jucedemo/9168/9 "2012-08-29T20:25:30Z")
> [@falkTX](#):
>
> my theory is that Juce is requesting a repaint everytime the window is resized.
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.
---
### Author:  [@jules](https://forum.juce.com/u/jules)
#### Post date: [August 29, 2012, 8:45pm UTC](https://forum.juce.com/t/non-native-window-resizing-painful-even-in-jucedemo/9168/10 "2012-08-29T20:45:57Z")
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.
---
### Author:  [@falkTX](https://forum.juce.com/u/falkTX)
#### Post date: [August 29, 2012, 8:55pm UTC](https://forum.juce.com/t/non-native-window-resizing-painful-even-in-jucedemo/9168/11 "2012-08-29T20:55:37Z")
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`
---
### Author:  [@TheVinn](https://forum.juce.com/u/TheVinn)
#### Post date: [August 29, 2012, 9:30pm UTC](https://forum.juce.com/t/non-native-window-resizing-painful-even-in-jucedemo/9168/12 "2012-08-29T21:30:20Z")
[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.
---
### Author:  [@jules](https://forum.juce.com/u/jules)
#### Post date: [August 30, 2012, 9:36am UTC](https://forum.juce.com/t/non-native-window-resizing-painful-even-in-jucedemo/9168/13 "2012-08-30T09:36:05Z")
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.
---
### Author:  [@falkTX](https://forum.juce.com/u/falkTX)
#### Post date: [August 30, 2012, 10:16am UTC](https://forum.juce.com/t/non-native-window-resizing-painful-even-in-jucedemo/9168/14 "2012-08-30T10:16:37Z")
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.
---
### Author:  [@jules](https://forum.juce.com/u/jules)
#### Post date: [August 30, 2012, 10:31am UTC](https://forum.juce.com/t/non-native-window-resizing-painful-even-in-jucedemo/9168/15 "2012-08-30T10:31:00Z")
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.