Can someone please try to build my LayerEffects application and let me know if window resizing is wonky (or if it fails to build)? I’m running it in a VirtualBox instance under Ubuntu:
Thanks!
Can someone please try to build my LayerEffects application and let me know if window resizing is wonky (or if it fails to build)? I’m running it in a VirtualBox instance under Ubuntu:
Thanks!
Nice to see someone giving some attention to Linux.
the build spits out a warning:
In file included from ../../VFLib/modules/vf_core/vf_core.cpp:77:0:
../../VFLib/modules/vf_core/native/vf_posix_FPUFlags.cpp:4:66: note: #pragma message: ../../VFLib/modules/vf_core/native/vf_posix_FPUFlags.cpp(4) : WARNING: Missing platform-specific implementation
I enabled the drop shadow effect and did a resize… it is painfully slow, and makes CPU go to the max.
It doesn’t matter if desktop effects are enabled or not, it’s still massively slow.
I also noticed some messages during execution:
JUCE Assertion failure in ../../VFLib/modules/vf_unfinished/graphics/vf_Pixels.h, line 345
JUCE Assertion failure in ../../VFLib/modules/vf_unfinished/graphics/vf_BevelEmbossStyle.cpp, line 36
(repeatead 4 more times)
I’m running a custom Ubuntu 12.04 64bit system here, KDE4 desktop.
PS: I run Linux 100% of the time I use my laptop, and I’m usually on IRC in #Juce channel, just in case. I’ll be glad to help any linux related issues.
Just tried it with:
and resizing works much better somehow… :?
(the gui still takes a lot of CPU to refresh itself though)
maybe Juce is doing something wrong here?
my theory is that it’s 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.
JuceDemo has the same resizing problems with the JUCE title bar. Setting the native title bar fixes it (but causes other problems).