With 6.6 almost out of the door (we released 6.6. RC 2 today, for those yet to check) we’ve finally added support for new Retina displays to Mac Desktop. This support means that LiveCode apps will look as crisp as other Mac apps on modern Mac laptops with virtually no work at all (you might need to add some @2x images, but that’s about it). However, this crispness does come at a cost…

LiveCode’s graphics rendering is inherently CPU-bound (for the moment at least). This means that every pixel you see in a window is being generated by operations performed on the machine’s CPU with the GPU only being involved at the Window Server end when its compositing the display. Whilst this approach means that we can deliver a much richer set of graphics primitives and effects than the host OS can manage, it does mean that Retina has a huge cost – a four-fold cost in fact (Retina displays are double the density in both directions, so that means for every single pixel rendered on a non-Retina display, there will be four pixels rendered on a Retina display).

Now, whilst CPU speed hasn’t suddenly jumped 4 four-fold in the same time as pixel counts have, one thing has jumped considerably – the number of cores our CPUs have. Indeed, all Retina MacBook’s have at two cores with each core able to run two threads concurrently. Within this fact lies a potential short-term solution to speeding up display on Retina systems…

The solution I’ve been experimenting with is to split the rendering of a stack up into 4 tiles with a separate thread responsible for rendering each tile. The engine keeps a pool of four threads around on which it schedules this work – as soon as one thread is complete, the main thread takes its work and sends it to the appropriate quadrant of the window buffer (ideally the individual threads would do this last part as well to eliminate the inherent bottleneck this creates, however for the APIs the engine currently uses for window updates this isn’t possible).

In an ideal world you’d hope to get a 4x speed up to rendering but due to the reality of overhead in the approach this is purely a theoretical limit. However, that being said, my current experiments indicate that around a two-fold increase in rendering speed should be attainable for large and reasonably graphically complex stacks (lots of bitmap effects and gradients) which should certainly help to mitigate jump from normal to Retina resolution.

Of course, this approach isn’t limited to Retina displays, the same idea can be applied to any computer with a multi-core CPU – there you could see up to a two-fold increase in rendering speed which is nothing to be sniffed at!

For C-source-level-interested parties, the code for the experiments I’ve been running can be found on the feature-threaded_rendering in my github repo (https://github.com/runrevmark/livecode.git). The code is Mac-only for now (search for MacStackTile in osxstack.cpp), and there’s a few hacks here and there to ensure thread-safety (patterns are disabled and there’s a global lock around text rendering) but it’s certainly showing promise…