When I first began creating Control, interfaces were defined as HTML Canvas objects that filled the entire screen. Each widget had its own draw method (this is still true) that drew straight into the canvas. Although this made the most sense from an organizational view in practice the rendering was very slow.

It took a while for me to realize the Canvas object was the bottleneck in rendering; I assumed that Canvas performance was hardware optimized for the gpu on iOS devices and that the problem was related to getting the widget values in the Objective-C runtime so that they could be sent out over OSC. Eventually I found some blog posts that described the performance issues with using large Canvas objects and realized the Canvas approach would not work for my needs.

The way it works now is that every widget has its own div tag. The div tags are manipulated via JavaScript and CSS. This seems to be hardware accelerated and yields usable latency. The only exception to this is the knob widget; there really was no practical way to draw a knob using divs alone (-webkit-border-radius gives a huge performance decrease) so Canvas is still used. In general it seems like the performance of canvas isn’t that bad as long as the canvas object is small. Thus, drawing multiple small canvas objects is much more efficient than redrawing the entire interface whenever a widget value should change.

In the future I’ll be doing some tests to see if it makes sense to have other widgets (like sliders) draw via canvas instead of using div tags. It would definitely provide more flexibility in terms of the toes of widgets that could be drawn. WebGL will also be a great option once it’s available on mobile devices.