Version 1.38

Ok folks, it’s new version time. Nothing particularly shiny in this one, it’s mostly just bugfixes - changes are:

*  Windows: mouse cursors and taskbar icons now use a full 8-bit alpha channel when running on WinXP
* Fixed some SVG bugs and made the parser more efficient
* got rid of the Component::setDragRepeatInterval() method and replaced it with a static method beginDragAutoRepeat(). This makes it easier for a parent component to enable auto-repeat when its children are clicked.
* bugfixes for some keyboard codes on Windows, RelativeTime rounding accuracy, Linux opengl repainting, mac window repainting, BWAV history chunk parsing, Table components, Mac fonts, Mac CoreAudio built-in device pairing, nested modal state return values, full-screen windows using native title bars, linux filenames with extended character sets.
* Windows: updated the network MAC address function, which wasn't correctly finding all network cards on some systems
* changes to allow a 64-bit build on Windows, including greater use of compiler intrinsics
* two new header files: juce_WithoutMacros.h and juce_DefineMacros.h (in the juce/src directory) - these make it easy to include juce.h without it defining macros that may conflict with other 3rd party header files. See the comments in these files for more info.
* tidied up the SystemStats operating system detection detection, to use an enum instead of strings, added Windows Vista detection, and renamed some of the methods. If you use these, you'll probably have to change the method you're calling, but it's not difficult.
* added an option to TreeView to set the indent size
* updated the build instructions for Windows compilers

I see you changed all linux file related stuff to use UTF-8, but I couldn’t find neither something in the code that sets the locale to use UTF-8 nor some hint in the documentation to do so on linux. Perhaps I missed something or didn’t look carefully enougth and haven’t found it.

I also want to mention some small things I noticed but didn’t post yet:

The include of juce_Config.h in juce_linux_Windowing.cpp seems to be broken. In my opinion it has to be changed from this:

[code]#include “juce_Config.h”
#if JUCE_BUILD_GUI_CLASSES

#include “linuxincludes.h”
#include <X11/Xlib.h>
#include <X11/Xutil.h>
#include <X11/Xatom.h>
#include <X11/Xmd.h>
#include <X11/keysym.h>
#include <X11/cursorfont.h>

#include “…/…/…/juce_Config.h”

#if JUCE_USE_XINERAMA
#include <X11/extensions/Xinerama.h>
#endif[/code]
to this:

[code]#include “…/…/…/juce_Config.h”
#if JUCE_BUILD_GUI_CLASSES

#include “linuxincludes.h”
#include <X11/Xlib.h>
#include <X11/Xutil.h>
#include <X11/Xatom.h>
#include <X11/Xmd.h>
#include <X11/keysym.h>
#include <X11/cursorfont.h>

#if JUCE_USE_XINERAMA
#include <X11/extensions/Xinerama.h>
#endif[/code]

The next thing is the reformated SystemStats class. In SystemStats::getOperatingSystemName() the WinVista value is missing in the switch.

The last thing is about the DSoundAudioIODevice. In general all channels that aren’t done yet get call their service methode 3 times in a row follow by a sleep(1). This repeats until all channels are done. With this sleep(1) after 3 service attemps the thread is producing a massive amount of context-switches (in my case ~600 context-switches per second), that is bad. This happens because it takes in general much longer than 1ms for the channels until they get enought free buffer space so they can do a successful service.
With the default values for directsound the latency is ~11ms, so the service methodes of the channels will get call ~10 times unsuccessfully. If the buffersize gets bigger it’s doing even more unsuccessfully attempts.

So I changed the following:

if (--count <= 0) { Sleep (1); count = maxCount; }
to this:

if (--count <= 0) { sleep (latencyMs * 0.75); count = maxCount; }
(notice the change in case of the sleep methode)

This reduced the context-switches from ~600 to ~40 per second and I haven’t notice any changes in the audio-output.
I didn’t test it with recording and I’m not really familiar with directsound. Perhaps I missed some bad/ugly things that can happen due to this change.

I also changed the thread-priority from 9 to 10 because if I scroll in firefox or in some editor the thread gets to few timeslices and resyncs the channels often, this makes the sound stuttering.

Thanks for that. I didn’t add a setlocale() call because that would mess up all conversions from 8-bit to unicode, including ones from embedded c-strings and other places that people may be using a locale. Instead I explicitly converted the strings to utf-8 in the file handling code, same as on the Mac, and it seems to work nicely.

Thanks for spotting the missing WinVista case - I wrote that on a train the other day so wasn’t paying 100% attention! No idea how the juce_Config.h include actually compiled the way it is, but you’re right that it should be changed.

The DSound thing is quite tricky - e.g. if the audio rendering needs more than 50% of the CPU and it sleeps for 75% of the latency at just the wrong moment, then it’ll glitch. Your longer sleep would be fine for very simple playback, but this is used in sequencer apps too. Ideally I’d write some clever timing code that can estimate how long it’s got and sleep for the appropriate amount, but it seems a bit of overkill for DSound. Are context switches actually causing problems for you?

For the priority thing, it’s better to set the whole process to high priority if playback is important, using Process::setPriority()

Now I’m confused about the locale stuff. I’ll have to test some things.

About directsound: The context switches don’t produce messurable peformanceloss on my pc, so it’s not so important. I came across this thing, as I run the demo and saw it producing 10x more context switches than any other process that was running. This seemed unnormal to me and I took a deeper look at it.
But you are right, I only tested it with simple playback and my changes will probably break anything that is more sophisticated than this.

[quote=“photon”]Now I’m confused about the locale stuff. I’ll have to test some things.

About directsound: The context switches don’t produce messurable peformanceloss on my pc, so it’s not so important. I came across this thing, as I run the demo and saw it producing 10x more context switches than any other process that was running. This seemed unnormal to me and I took a deeper look at it.
But you are right, I only tested it with simple playback and my changes will probably break anything that is more sophisticated than this.[/quote]

Yes, probably best to leave the DSound stuff as it is - tracktion seems to work, and I don’t want to break that!

An other little thing that just showed up again as I build JUCE on Windows with MinGW in debug-mode is the include of crtdbg.h in juce_StandardHeader.h:

#if defined (JUCE_WIN32) && defined (JUCE_DEBUG) #include <crtdbg.h> #endif
crtdbg.h is MSVC specific, so it should be changed to this:

#if defined (JUCE_MSVC) && defined (JUCE_DEBUG) #include <crtdbg.h> #endif
You may also change the #ifdef JUCE_WIN32 to #ifdef JUCE_MSVC in juce_FlacAudioFormat.cpp and juce_OggVorbisAudioFormat.cpp for the auto-linking to the format-libraries. This only works with MSVC and produces warnings with MinGW.

I think you missed some _WIN32, _MSC_VER (no, I don’t speak of #if _MSC_VER >= 1300) and LINUX, while you replaced these defines by JUCE_WIN32, JUCE_MSVC and JUCE_LINUX in the sourcecode.

In juce_Socket.cpp the line #pragma warning (disable : 4127 4389 4018) may be wrapped in a #ifdef JUCE_MSVC … #endif to reduce compile-warnings with MinGW, because this is again MSVC specific stuff.

I hope you’r not too annoyed about me digging out all these things :slight_smile: .

[quote=“photon”]An other little thing that just showed up again as I build JUCE on Windows with MinGW in debug-mode is the include of crtdbg.h in juce_StandardHeader.h:

#if defined (JUCE_WIN32) && defined (JUCE_DEBUG) #include <crtdbg.h> #endif
crtdbg.h is MSVC specific, so it should be changed to this:

#if defined (JUCE_MSVC) && defined (JUCE_DEBUG) #include <crtdbg.h> #endif
You may also change the #ifdef JUCE_WIN32 to #ifdef JUCE_MSVC in juce_FlacAudioFormat.cpp and juce_OggVorbisAudioFormat.cpp for the auto-linking to the format-libraries. This only works with MSVC and produces warnings with MinGW.

I think you missed some _WIN32, _MSC_VER (no, I don’t speak of #if _MSC_VER >= 1300) and LINUX, while you replaced these defines by JUCE_WIN32, JUCE_MSVC and JUCE_LINUX in the sourcecode.

In juce_Socket.cpp the line #pragma warning (disable : 4127 4389 4018) may be wrapped in a #ifdef JUCE_MSVC … #endif to reduce compile-warnings with MinGW, because this is again MSVC specific stuff.

I hope you’r not too annoyed about me digging out all these things :slight_smile: .[/quote]

Thanks, I’m certainly not annoyed - it’s great to have someone keeping an eye up on me! That’s all good stuff, keep it coming!

Which version of mingw are you using to get these warnings? I always try building in dev-cpp and haven’t seen any problems with that.

That’s good to hear!

I’m using the latest stable version of MinGW including GCC 3.4.5, but I don’t build JUCE with DevCpp (I don’t like DevCpp), I use makefiles generated by premake.

The difference seems to be that I compile with -Wall and you don’t. With -Wall I get the warnings reported above and some other warning-types like:

  • variable x may be used uninitialized in this function
  • comparison beteen signed and unsigned integer expressions
  • class x has virtual functions but non-virtual destructor
  • variable x will be initialized after

The last one is caused by a class structure like this:

class Foobar { public: Foobar() : a(1), c(3), b(2) { } int a, b, c; };

Notice that the member variables are initialized in a different order than they were defined.

I just tested to build with DevCpp, but it fails to build due to errors finding included files like:

#include "../../../../juce_core/containers/juce_ReferenceCountedObject.h"

in juce_Typeface.h produces an “No such file or directory”-error. But this only happend with DevCpp, if I build with my own makefiles or even with VC6 it compiles without errors (only some warnings due to -Wall).

ok, I’ll try cranking up the warning level and do some tidying up. The include error is this one:
http://www.rawmaterialsoftware.com/juceforum/viewtopic.php?t=927&highlight=include+path+length

Argh, you’r right about the include error. I had read the thread a while ago, but forgot about it until now. I also had changed the way premake generates makefiles to circumvent paths that are to long for the limited windows console.
But it’s strange that it wont build with DevCpp even if I put JUCE to c:\juce. Anyway DevCpp isn’t important to me, JUCE builds on windows and linux just fine with makefiles generated by premake.

It would be nice if there was a virtual void Component::isShowingChanged()

Or is there a way to do that currently?

[quote=“G-Mon”]It would be nice if there was a virtual void Component::isShowingChanged()

Or is there a way to do that currently?[/quote]

This already exists: Component::visibilityChanged()

[quote=“photon”][quote=“G-Mon”]It would be nice if there was a virtual void Component::isShowingChanged()

Or is there a way to do that currently?[/quote]

This already exists: Component::visibilityChanged()[/quote]

But that doesn’t get called if the parent changes visibility.

True, I should really add a method like that.

I,m trying to compile juce 1.38 in xcode 2.4 on my G4 PowerBook (OSX 10.4.7) but i,m not getting much love.

i had to change the paths in juce.xcconfig from MacOSX10.2.8.sdk to MacOSX10.3.9.sdk for it to do anything at all, i do not seem to have MacOSX10.2.8.sdk installed.

now it does start compiling over 600 files but at the end i get this error that is all chinese to me:

/usr/bin/ld: /code/juce/bin/libjucedebug.a(juce_String.o) illegal reference for -dynamic code (section difference reference from section (__TEXT,__eh_frame) relocation entry (46) to symbol: ___isfinite defined in dylib: /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libSystem.dylib)

does anyone have any idea?

If you’re setting it to use the 10.3.9 library, have you also changed the target OS setting in xconfig that from 10.2 to 10.3?

yes i tried 10.3, 10.2 and even 10.4, no luck

ARCHS = ppc i386
SDKROOT = /Developer/SDKs/MacOSX10.4u.sdk
GCC_VERSION_ppc = 3.3
MACOSX_DEPLOYMENT_TARGET_ppc = 10.3
OTHER_LD_FLAGS_ppc = /Developer/SDKs/MacOSX10.3.9.sdk/usr/lib/gcc/darwin/3.3/libstdc++.a
SDKROOT_ppc = /Developer/SDKs/MacOSX10.3.9.sdk

Have you tried a full clean and rebuild? Could just be a symbol that got left in the object file and isn’t getting rebuilt correctly…

i tried your suggestion, did a clean and then build and go but still the same error.

i did notice that this problem only occurs with the debug build, the release build compiles and runs fine.

how bizare …

I made a point of checking that it works with 10.3.9, so don’t know what’s going on there.

Maybe try removing the OTHER_LD_FLAGS_ppc setting, and let it choose which lib to link with?