Before We Start
• Ask questions. Whenever you want to. I’m
happy to talk about anything - mapping, mobile
mapping, HTML5 canvas (and other bits), JS
performance, why squirrels are so cute, etc.
• I’m not an expert on anything, especially
• I’m more stubborn than I am intelligent.
HTML5 Mapping Library
does more generic tiling interfaces”
• “Um, ok, why on earth have you built another
mapping library - we have plenty...”
• “Fair, point, let’s talk about the why first”
Mapping for Mobile Devices
• Do we really need another mapping library -
there are already so many...
• Currently, only Google’s HTML API caters for
mobile touch events. So if you can use GMaps
no, but not everyone chooses a Google solution.
• Many map providers, but all maintain their own
proprietary APIs (Native, JS, etc).
Mapping for Mobile Devices
• What about OpenLayers (http://openlayers.org/)?
• Designers vs the Engineers perspective -
consumers have come to appreciate native
interactions on mobile devices.
• As Coke consider their competition to be water,
Tile5’s competition is native mapping interfaces
How is it Built?
HTML5 using Canvas
• Canvas’ feature set is excellent, albeit a little
• Quite a few JS libraries available that abstract
and simplify operations - fabric.js is a nice one.
• No need for browser plugins - awesome.
• Canvas’ speed is ok, but there are some things
• Tile5 implements a layering system much like is
implemented in CSS.
• The View and ViewLayer are used extensively to
build mapping interfaces (amongst other things)
Canvas Performance Notes
• Only IE9 and FF4 implement hardware acceleration
for canvas, which means you have to be
• Best thing you can do be conservative with your
draw code. Watch out for clearRect and
drawImage on large buffers.
• Chrome’s “Speed Tracer” is awesome for watching
performance. I rewrote Tile5 draw code a few times.
The Cost of Performance
• Optimising for performance has meant support
for opacity in layers is limited, but I’m working on
that by using clipping regions.
• It hurts your brain.
More on JS Performance
• Need to rethink strict OOP principles of design,
i.e. an object has both state and methods.
Methods on JS objects = memory bloat. This
hurts on Mobile Safari due to 10M memory cap.
• Consider “Eteration” as an alternative to Iteration
due ensure nice non-blocking interfaces. Mobile
> Get an iPhone 3G (arghhh!!!)
JS Performance Future
It will get faster !
So fast now = great soon...
Don’t forget readability though
• Implement GeoJSON (and other vector) overlays
• Play with heatmaps.
• Investigate “baking tiles” on the client to further
optimise performance and do other interesting
things (such as crowd tile rendering).
• Consider how to do all of the above efficiently and
in a JS performance friendly way.
• Get around to building b64proxy.appspot.com to serve
base64 data strings for images. This should allow using
caching tiles via localStorage.
• Check that everything is abstract as it can be. For example,
adding an annotation to a T5.View rather than a T5.Map.
• Improve Documentation (sorry about that)
• More sample code
• Build applications based on Tile5 that I think are useful.
• Break out some of the most useful stuff into “COGs”: http://
• Observable and Configurable Patterns (done)
• Touch (done)
• Image Loading
• Device detection (it’s a bit naughty, but necessary as feature detection isn’t completely
• Write some friendly build helpers, looking at Juicer: