sigh I was hoping we would be making objects like Typeface, Font, et. al. thread safe (to eventually allow concurrent Graphics operations in the same Image) but it seems we are going in the completely opposite direction!
Why add a SingleThreadedReferenceCountedObject ?! It is hard to imagine that anyone noticed a performance penalty from using an atomic operation… extra code with no benefit (and possibly going backwards in features).
None of those classes was ever remotely thread-safe! They couldn’t possibly be used in a multi-threaded way without proper locking, so having atomic reference counts was pointless! To make the graphics classes thread-safe would be a far bigger and more complex job than just using a few atomic operations for the pointers!
Are you sure this is actually true? Back in the days I did some code that drawed some stuff in another thread and drawing to an image didn’t seem like a problem, unless using drawText(). Ofcourse, drawing on screen should only be performed in the GUI thread, but it makes a lot of sense to be able to render in a second thread to some image that is displayed later on.
But if I understood right, TheVinn wants to use multiple threads to access one single context? That doesn’t make sense.
True, a simple atomic counter in no way makes Graphics safe. But having an extra class, almost an exact duplicate of an existing class (why not make the type of counter to use a template?) to get an invisible performance gain that no one will notice seems to be un-Juce like.
Zamrate said it exactly right. Drawing to the screen should of course be done only in the message thread but I think that concurrent Graphics operations on a shared software Image is a legitimate use-case - if these operations are performed on non-overlapping sections.
To be clear, I am not suggesting that a single Graphics object be made thread safe. Instead, I am saying that it should be possible for multiple threads, each with their own Graphics object instance pointing into a single shared Image, to perform concurrent operations. Again, each thread would have its own Graphics instance (its own saved state, clipping, etc). NOT two threads using the same Graphics.
The only really tricky part is fixing the font code. The glyph cache in the software renderer is not thread safe, and Typeface needs to be fortified to be thread-safe (without over-locking which would result in serialization).