Canvas, Web Components, Polymer, HaXe?

Oh, My! The Future of ForeverScape Tech

Posted by Vance Feld on February 15, 2015

Well, after fussing with the beta explorer at, I’ve decided to quit the DOM altogether in favor of Canvas rendering. Absolute pixels are my old pal and friend anyway. We all know that the DOM is slow, but turns out it is horrendously slow for anything but opacity and transform. My hope for ForeverScape Core is that the main application can remain the same. Personally, I’m framework agnostic. I use angular because it’s familiar, but I’d switch to react if I had time to. This is a hobby project, I have no paid engineers, so I’m likely to not care what flavor-of-the-day the UI is written in.

The transition to Canvas could probably be done a weekend… watch the Github ForeverScape Core Repository for updates!

The biggest selling point for me is that I did not realize browsers went to the extent of pausing the javascript runtime during scrolling to increase performance by not letting js touch the DOM. The article, 60 FPS on the Mobile Web details the performance gains wraught by render-cycle drawing on Canvas. The foreverscape mobile explorer is all render-loop driven. I was hesitant at first, but now GPU acceleration for Canvas has become ubiquitous in mobile browsers.

The transition should be relatively smooth-- basically replace the geometry (which is fixed already because we assume a fixed pixel width of unloaded and loaded images at different resolutions). All entities are absolute relative to their container, which should translate well into an arbitrary scale ratio necessary for zooming and loading multiple resolutions for different LOD.

Web Components & Polymer

I see the potential for writing a concise Canvas widget that does three things very well. 1) Dynamically load tiles at correct resolutions. 2) Allow any direction fast scrolling and 3) drop waypoints and navigate to them. Perhaps features like commenting and “scavenger hunt” games could be built outside of the component, such that the component could serve a multiplicity of roles simply by binding to the node’s attributes. That would slick… totally doable, I just need some more engineering time!

Deep Future

Ideally, we can stop messing with duplicitous UI generation. HTML is pretty ugly. Sure, it’s great for templating, but that’s all it should be used for. The shadow DOM and the hidden “virtual DOM” within React.js (the pre-render position/relation tree that can be sampled into browser frames) is close to brilliant, but it’s only brilliant in that it’s compensating for the setbacks that HTML introduces. We should be going back to the extendable object/component paradigm, absolute in its relativity to the window size. If this were the norm across all devices, I’d be jumping in. There’s a lot of promises. I started down the path on the mobile app with HaXe and OpenFL. Its a great solution. I’m brewing a game in HaXe, it is nice to have a solid typed language with clear OOP syntax that can compile to very performant native code. React Native promises this? Does it? Will it? Can it be as performant as I need? I started the original ForeverScape app in HaXe, but got frustrated because of some instabilities early on. Those kinks are worked out-- maybe it's time to revisit it. Compiling the same codebase to C++, Neko and ObjectiveC is super fun!

Business Logic is Easy to X-Platform, Drawing Ain’t

Will React Native Solve the X-Platform UI Problem?