I’m using different Threads that generate (non-shown) Images in which I am writing some text using Graphics::drawText(). Sometimes it happened that some character was just blank (for instance, “JUCE” would be written “JU E” in my Image). I got no clue why this happens, but could it maybe be that the Glyph Cache is just throwing away a Glyph on one Thread while another Thread tries to use it (or something like that) ?
Yes, you could get all sorts of problems if you try to render on a background thread at the same time as your UI thread is drawing. Should be ok if you lock the message manager though.
Actually, it’s not just about locking the UI Thread - one is not allowed to concurrently call drawText() from different Threads. One always has to call it from one Thread only at the same time, right? (Even if not using the UI Thread at all, if many threads use this function at the same time I seem to get artifacts).
Hmm this is bad, because I’m using JUCE147 and as far as I remember the MessageManagerLock mechanism sometimes does not work as it should.
Would this work (that is me modifying my JUCE): to put some ScopedLock lock(globalGlyphCacheCriticalSection) into GlyphCache::getGlyphFor(), or better just into Graphics::drawText()? This should basically avoid my problem, but I don’t know how expensive a CriticalSection is in terms of CPU usage if it’s used a few thousand times per second (actually I read it’s +/- 400 cycles)…
I guess a bit of hackery like that would work.
Where did you read that a critical section was 400 cycles? That sounds a bit silly to me, I’d have thought that getting an uncontested lock would be pretty trivial.
http://www.codeproject.com/KB/threads/CritSectEx.aspx
(see tables for P4 ealier (which is my computer), but i haven’t tested it!!)
Good article - it’s tempting to implement something similar if the win32 sections are really so crappy! I wonder if his algorithm is safe on multi-core systems though… It sounds a bit too good to be true, and maybe win32 locks are slow because they have to deal with some weird architectures that don’t behave as you’d expect…