Re:Slowloris: high-performance HTML5 UIs
by erichocean on Monday September 10, 2012 @08:33AM
(#4499398)
The timing of this is funny, since I spent the last five days splitting Blossom[1] into two threads, a UI thread which runs on the "main" JavaScript thread, and an Application thread which runs in a dedicated web Worker (it's also possible to have multiple Application threads, for app plugins, which was part of my goal).
Anyway, at least for modern MVC development, I've gotten Blossom booting in a Worker, and I've worked through how to split it up so that it's still a "normal" MVC app, but event handling, animation, and rendering is 100% on the UI thread, and all business logic, model layer storage, network communication, and application state management is on the Application/Worker thread.
My primary goal is to make Blossom's requestAnimationFrame()-driven, canvas-based UI thread rock solid at 60fps, even for JavaScript-driven animations, and to place all potentially long work (> than 2-3 ms) in the Application/Worker thread.
This technique is applicable in all modern browsers (IE 10, Chrome, Safari, mobile Safari/iOS, Chrome on Android, and Firefox), and of course in IE 6-9 with Chrome Frame installed.
This approach will also use up to three CPU cores (the third in Blossom is invoked by the automatic application of hardware-accelerated CSS transitions in Blossom, which are executed by the browser on their own thread as well), and even more cores can become involved when plugins are added to the scheme, in their own dedicated workers.
Anyway, at least for modern MVC development, I've gotten Blossom booting in a Worker, and I've worked through how to split it up so that it's still a "normal" MVC app, but event handling, animation, and rendering is 100% on the UI thread, and all business logic, model layer storage, network communication, and application state management is on the Application/Worker thread.
My primary goal is to make Blossom's requestAnimationFrame()-driven, canvas-based UI thread rock solid at 60fps, even for JavaScript-driven animations, and to place all potentially long work (> than 2-3 ms) in the Application/Worker thread.
This technique is applicable in all modern browsers (IE 10, Chrome, Safari, mobile Safari/iOS, Chrome on Android, and Firefox), and of course in IE 6-9 with Chrome Frame installed.
This approach will also use up to three CPU cores (the third in Blossom is invoked by the automatic application of hardware-accelerated CSS transitions in Blossom, which are executed by the browser on their own thread as well), and even more cores can become involved when plugins are added to the scheme, in their own dedicated workers.
[1] https://github.com/erichocean/blossom