Making things small ... single source resource cache

When we created the Storyboard platform, our first design goal was to specifically target embedded products.  As the guys over at 37Signals will tell you, drawing a line in a sand can have a clarifying effect and significantly speed up development.

One of the fall outs from this decision is that resource duplication just can't happen.  This was something that we had seen over an over again with clients building products using other frameworks and tools.  If an image was loaded, perhaps as a background, then used on multiple screens of the application, that the decoded image content would be duplicated several times over.  With a QVGA 320x240 32bit display this can end up consuming 300K per image for just the background.

The solution to avoid this problem, is to maintain an image cache, but in most libraries and graphics frameworks this is code that you have to write yourself, then you need to tune it, make it configurable, figure out a life cycle for the cache objects and incorporate the shared images into the graphics framework you are using and hope that it will support shared image data pointers.

Building a good image or resource cache is the kind of activity that can suck anywhere from a couple of days to a week out of a project.  Assuming an average software developer salary that cache cost ~$1000 not to mention the time that could have been spent working on other aspects of the project.

Storyboard is a tightly integrated system, where image, text and fonts resources are not only cached but their decoded data is shared, even in the situation where content is scaled or rotated.  This means that estimating your application's memory footprint can be done easily by looking at the resources you are using, knowing that only one copy of those resources will every be sourced.

The resource cache in Storyboard can also be configured and capped through the use of Resource Manager options to achieve the best match of memory consumption vs resource load/decode latency for your particular application.

In the future one of the features we expect to add into Storyboard Designer is the ability to pre-composite content at design time.  In the case where there are multiple static  images, text or other render extensions we would be able to join them all together into a single image, further reducing the application's runtime memory footprint.

Storyboard: It doesn't always consume resources, but when it does it prefers small ones ... stay small my friends.

Thomas