My first post! Been trolling the forums looking for an answer…
I’ve been working on a multi-band equalizer using biquads over the holidays using JUCE. Whenever I compile it using /O1, /O2 or /Ox, I get a blank Editor component. The example plug-in does the same. /Od does just fine. However, the equalizer chews up about twice the CPU time. Now I can optimize specific, key source files, skipping the editor source file, and it works, but I get numerous warnings. Ideally, I think I’d like to be able to simply set /Ox and be done with it. Ideas?
Black and it does respond to events… Whenever a component has focus, there is a white border around the component. Modifying the parameters from the host (in this case, VSTHost) affects the filter, but has no discernible affect on the Editor component.
I had a suspicion the other day about recent builds - but I have no evidence yet - I looked at the sizes of the .obj files and found the debug objs to be smaller than the release ones!
(Admittedly VSC++2005 Express - not 2008) - but I wondered if something’d gone screwy, somewhere!
I had the same problem… Dunno where it comes from (I use amalgamated juce), but I know, that disabling ‘Enhanced Instruction Set’ (not using /arch:SSE2 or /arch:SSE flags) for juce, gets rid of this problem (atleast for me - I’m using vc++ 2005).
We had similar problem with using SSE/SSE2 extensions on VC2008. When they are enabled the plugin’s editor is totally black.
Somehow these extensions collide with optimizations like /O2,/OX and with fpu model /fp:fast. When optimizations are not used or fpu model is set to /fp:precise everything is ok with gui but then the code is too slow eliminating SSE from use.
I had a similar but not identical issue so I’ll give you something to look at but it may not be what you need.
I have two projects, JUCE and my plug-in. The JUCE project builds a library and I left it set to it’s default project settings which include C++ optimizations of “link time code generation” If that is set (and I think it is good to have it set) you should make sure that in your dll project you have the linker optimizations set to remove unreferenced data/functions (/OPT: REF) and Remove Redundant COMDATs (/OPT:ICF).
The /OPT: REF linker optimization in one project linking to another project built with “link time code generation” seemed to make the linker hook things up incorrectly and I had specific issues in the png lib.
Don’t know if this is related to what you are doing, but it’s worth looking at.
Yes, it is definitely pnglib related problem but it may be caused by the way how c++ compiler works in VC2008. It’s mentioned in msdn about possible differences in resulting code (for arithmetical operations) when SSE/SSE2 is used. So if we eg. compile JuceDemo with SSE2 turned on we’ll see that almost all the GUI is displayed wrong except the background. The controls work properly when you hit on the place where they should be - so there’s only redrawing issue.
However it’s also related to optimization level. In Debug when optimization is disabled everything is ok. In Release when optimization is set to /O2 or /Ox the errors appear.
I checked it also on Mac compiling with the gcc compiler. Everything seems to be fine when SSE3 extensions are used no matter what optimization level is used together with them.
So I guess that some parts of source code in pnglib are compiled with bugs when we do it with SSE2 extensions on VC2008 compiler. I don’t know if someone managed with this problem already…
Indeed I forgot about this, damn !!! Exactly when I switched off the SSE2 for the file containing pnglib sources or even switched it to SSE everything seems to be fine.
The best way how it should be done would be with some kind of inline switch affecting only the pnglib part of juce. Otherwise one has to switch it off for the hole juce_amalgamated file (when of course uses amalgamated version)
