Refactored Draw Code in SlickJS (Again)

Monday 05 July 2010

Late last week I refactored the draw code in Slick JS (http://github.com/sidelab/slick) again. I’ve been pretty frustrated that I didn’t get the drawing logic right first time, but I think I’ve come to terms with it. Here are the major changes.

Invalidation (request to repaint) on demand functionality change
Prior to this update, parts of the code that needed the display would request that the display updates itself with an invalidate command – something other old Delphi custom control writers would probably recognise. This was starting to become inefficient, and while I tried a few different ways of improving the performance – you know like using setTimeout and clearTimeout to prevent lots of redraws nothing really worked out.

The draw operation is now done in an setInterval callback which is set to fire every 40ms (basically equating to 25fps for draw). Yes, I know that all of you smarty pants out there will say this was obviously the way to go, but for some reason I thought I could implement an on-demand drawing system better (that maxed out at a 25fps draw rate). Anyway, lesson learned – the animation loop is in and it’s working really well.

Essentially, the invalidate command still exists and is used to inform a SLICK.Graphics.View (api doc to come) that something is actively requiring redraws (such as a panning or pinch zoom operation). That just triggers a flag that means we need to lay off heavy buffer redraws while this is going on.

Created a ViewLayer “class” in addition to View
Prior to this refactoring, the tiling and mapping classes extended the functionality contained in the View. However, things were starting to be come a little unwieldy and seperate drawing operations weren’t terribly well encapsulated. As such I introduced a ViewLayer to serve as a mechanism for encapsulating that draw code. Essentially, a ViewLayer has a z-index and can be buffered or unbuffered (i.e. it draws directly to the View canvas as opposed to an offscreen buffer, which is then drawn across). Since creating the ViewLayer class I have been able to encapsulate nicely a Radar Overlay, a cross hair Overlay, copyright text for the maps, etc and most importantly been able to implement zooming behaviour for the maps in a way that provides the experience that we are all used to (I’ll post more on this later). Anyway, I’m very happy with the result and if anyone want to checkout the code – feel free to have a look on Github. The following modules are probably of most interest:

Right, onto implementing the RouteOverlay to enable displaying a route on a map…

Any questions, comments, etc, then feel free to leave something below or comment over on Github (I think you can do that)…

Leave a Reply