[odilitime]

Completely agree.

I actually have an offline repo with multithreading started but put on hold to focus on other issues. I'd like to implement threading sooner than later as it will be easier to do on a smaller project than a large one.

It's all about the architecture. We want to get that right first and are willing to throw away our current code to make sure we have this nailed. We are focusing on the renderer using a flow-programming style (only update what needs to change) as much as possible. So we're yielded to the OS unless there are pending events (using glfw). So no render() 60 times per second (unless there was something pumping events as such)

We're actually going to be converting HTML/CSS into JavaScript and the renderer will be handling a dynamic DOM. So we're not falling into trap of expecting things to be static. A couple of us are ex-game devs and have worked on HTML 5 games.

Thanks for the kind words.

[oscargrouch]

> We're actually going to be converting HTML/CSS into JavaScript and the renderer will be handling a dynamic DOM

Thats a cool idea. Than its just a matter of exposing the c++ composition/rendering engine to javascript.

But of course, this will require a pretty hardcore javascript JIT like the current V8..