new PDFGeneratorClient().open()
true0- Abstract
- Introduction / Motivation -- David
- (Concept) Lively Architecture / Shape replacement / Problems (Rendering, serialization, ...) -- David
- Implementation (What was changed and how) -- Robert
- Evaluation -- Robert
- Related Work -- Robert
- Summary -- Robert
?
t=newSimpleTextMorph(newRectangle(0,0,100,100))t.openInWorld()t.setFill(Color.white)
2Evaluation
We measured the performance by running four different benchmarks.
- Ellipse Benchmark (HTML / SVG)
This benchmark uses the EllipseMaker and records the frames per second over a fixed amount of time. The average fps is taken. More is better. It measures the performance of transformations.
- Mouse click and mouse move benchmark (HTML / SVG)
Measures how fast events are dispatched. For Lively HTML we still use the manual event dispatch mechanism that is also used by Lively SVG *except* for the new widgets. Their shapes directly subscribe to the browser's event system.
- List selection benchmark (HTML / SVG)
How fast can list elements be selected. The lists in the system browser are really slow when there are a certain amount of list items so it is interesting to see if there are differences.
- Results
In all four benchmarks we run the SVG version, the "pure" HTML version, and the HTML version that uses ContextJS. For the ellipse benchmark we also measured the performance of the canvas version.
As you can see in the LivelyHTMLPerformance.png (should be shown above) the transformations in the SVG version are twice as fast compared to the HTML version. This is unexpected and negate our theory that HTML is generally faster. The reason for that is probably the following: The CSS transformations have to be set using strings. This means that we have to convert values like position, rotation, and scale into one big string at the lowest level of our rendering engine. The CSS specification actually defines an API for setting CSS attributes that does not require string conversion. Unfortunately, this API isn't implemented in current Safari/Chrome versions. SVG on the other hand, directly uses matrices for transformation which is significantly faster. So we can only hope and wait that the different API is implemented.
The mouse event benchmarks show a distinct difference. HTML is faster although the event dispatch is the same. Switching to a complete DOM-based event dispatch will probably bring even bigger improvements.
The list selection benchmark (we use the new HTML list widget) show that HTML lists are an order of magnitude faster than SVG lists. The is because HTML lists don't consists of that many parts/submorphs as HTML lists and they use the direct DOM-based event dispatch.
Implementation
New shapes
As I already mentioned, our approach was very similar to your canvas implementation. Since Lively makes use of the Bridge Pattern to separate its graphics API (Morphic) from its implementation (lively.scene.Shape hierarchy) we started to implement new kinds of shapes that wouldn't use SVG but HTML nodes but still implement the same interface as the normal shapes. When used on an HTML canvas (a simple <div> element) we were able to implement all necessary Lively shapes. Simple shapes such as Rectangles are implemented using <div> elements, more complex elements are implemented using the canvas element (we reused your code).
Demo: Demo World (There are still some glitches but nothing that can't be fixed).
CSS3
Graphical attributes such as fill color as well as the transformations are implemented using CSS3 (the CSS3 standard introduces the transform property). With it, we were able to implement all features needed by Morphic.
Text
We implemented the text rendering very similar to the SVG text rendering. A text morph creates <span> elements and renders it's text words into it. However, we also implemented "pure" HTML text, see below.
ContextJS
We wanted to be able to develop Lively HTML from within Lively. First we extended Lively so that it was possible to load multiple worlds on the same page. We then used Jens' ContextJS to wrap our system additions into a Layer that is dynamically activated when something happens inside a HTML world. This way we can have two worlds - one using SVG and one using HTML - in the same page and we can manipulate the HTML world from the SVG world (I learned that this is a good idea when I was watching over your shoulder when you created the Canvas version ;-).
Of course there is an overhead using ContextJS. To remove that overhead we implemented a way to automatically "flatten" ContextJS layers so that ContextJS is no longer needed when you just want to display one world.
Demo: Two worlds
Summary
We were able to successfully implement a HTML version of Lively. The results show that Lively HTML isn't faster when displaying rich graphics and animations. However, text and list applications are much faster.
Although we didn't implement it it is also possible to continue using SVG shapes. We would use them only for certain shape types like curves and polygones. These means that we are able to easily mix different rendering types with each other. However, using only SVG shapes will not resolve the issue with the transformation performance since transformations will still be done using CSS so that all shape types are compatible with each other.
Also for the iPad Lively HTML is the better choice since elements like the date picker or the Apple search panels are only available in HTML (this is also what Sencha uses).
We have to make a decision if we should switch our default rendering to HTML. Writing source code and using the system browser can be done more efficient and with a better look and feel in the HTML version. Animations using complex graphical objects will be slower. Please let me know what you think about switching the rendering system.
Future Work
- Fix bugs and use SVG shapes for curves and polygons.
- We hadn't a chance to try out CSS styling using style classes created and assigned by the user.
- Event dispatch could be made much faster
- Static HTML document augmentation could be implemented. We made some experiments with embedding Lively worlds and that works fine. The next step is to "livelyfy" HTML objects to make them editable and scriptable. It could be possible to persistently script any page on the internet. We could use a similar scheme to those annotation tools that allow users to create notes and attach them to websites. The data for that is stored on their own server and is loaded every time a user visits a page that was modified before.