On 23rd of April 2015, Mihai Șucan passed away due to metastatic cancer caused by
23 June 2009, 19:51
HTML 5 Canvas specification defines two important methods for text rendering:
strokeText(). You also have a
measureText() and the associated text-related
properties: font, textAlign and
The Canvas Text API is only implemented in Webkit (Safari and Chrome)
and in Gecko 1.9.1+ (Firefox 3.5+).
If you want to render text in your Canvas element in Gecko 1.9.0 (Firefox 3.0) you can use their proprietary Canvas text rendering API which is now, obviously, deprecated in favour of the standardized API. They provided the following methods:
mozMeasureText(). To style the text you only have the mozTextStyle
In PaintWeb I use the
mozPathText() method when the standard
API is not available.
Opera does not support the Canvas Text API. I learned that the
drawImage() 2D context method allows the drawing of SVG document as well - this works only in Opera. I implemented
the text tool by adding a new minimal SVG document which contains a
<text> element. This was updated and drawn in the Canvas element in sync with user interaction. However,
after I completed the implementation I found several bugs:
SVG redraw issues. When you update the text styling properties, or when you update the text itself, sometimes Opera
fails to entirely redraw the SVG document, irrespective of the SVG being visible or not.
memory leaks (test case). For some unfortunate reason, each
drawImage(svgDocument) leaks some amount of memory. Got a crasher with this, and a system freeze
after filling my physical memory (1 GB) and the swap (1 GB). ;)
security violations (test case). Opera considers the SVG
document as being an external resource, thus it marks the Canvas as being "dirty" once
drawImage(svgDocument) is invoked. You can no longer read pixels using
getImageData(), nor can you use the
toDataURL() method. This broke the PaintWeb history mechanism, the selection tool,
and the "image save" option.
The first two issues I said I can live with, but not with the security violations. Thus, I have disabled the text tool
in Opera. I have reported the last two bugs to Opera with the associated minimal test cases.
If you are interested to render text, you can even attempt server-side "hacks". You could make a server-side script
which renders text, and you can then draw it in your Canvas with an image element. This, however, defeats the purpose
of PaintWeb - I want it to be a "pure" client-side Web application.
Lastly, you can implement "vector drawing" of text using a client-side font definition in some format, and then render
it with basic paths in Canvas. Again, this is beyond the purpose of PaintWeb. Opera will implement Canvas Text some
For further details about attempts at rendering text when the standard Canvas Text API is not available, please read
the rendering text blog post wrote by Christopher Clay
at the end of 2006.
14 May 2009, 11:09
I have been working on the PaintWeb code refactoring and now I am nearing
completion. The initial PaintWeb 0.5 alpha code was more of a demo - it was all in a single big script. I have now added
jsdoc comments almost everywhere and I did split the code into multiple files - per tools, per extensions, per language,
and more. I have also made important changes to the API. Now
any external code can easily add/remove tools, extensions and keyboard shortcuts.
For more developer-related information please read the latest forum thread I posted on the Moodle forums.
For teachers and potential users of PaintWeb inside Moodle, I have prepared a list of questions on how you would use the paint tool in Moodle.
Martin, my mentor, suggested early in my GSOC application process to also apply
for the OLPC Contributors program. So I did, and my project was accepted.
Even if the OLPC XO has a slow CPU by today's expectations, it's only 400 Mhz, the system works quite nicely. It has
256 MB of RAM and 1GB of disk capacity. The Sugar interface and the activities provided are amazing. People who hear
about these laptops do not know to appreciate the numerous doors such laptops open, doors to knowledge, for all those
children who receive them. They help a lot in learning about computing, maths, music, and more.
The Sugar interface is quite well thought-out. I like the concept of having the neighbourhood, group, home and
The default browser, is some Python application embedding Gecko - on par with Firefox 3.0. The performance of the
browser is lacking.
Opera 10 alphas start much faster and feel snappier. The paint tool
feels sluggish as well.
The Gnash plugin
is more of a problem rather than a solution. I installed Flash Player 10, which is sluggish, but at least it works. The
system can play Youtube high-quality videos and even uncompressed DVD videos, with Mplayer over the wireless connection. Flash Player cannot play Youtube videos.
Battery life is good - I can use it about three hours without any problems.
Since last week I have been working on the performance of the PaintWeb application, with the OLPC XO-1 laptop. After
several tests, I have managed to improve things sufficiently such that the paint tool is now usable in Opera 10 on the
XO. Unfortunately, in Browse.xo it's not, at least not by default.
The main performance culprit affecting PaintWeb on the XO is their use of layout.css.dpi. Gecko allows
users to change the
DPI used for rendering Web pages, in order to makes fonts and images smaller or bigger.
So, on the XO the browser is set to use DPI 134, instead of DPI 96. This makes the fonts and images render bigger - with
DPI 96 they would all be way too small. PaintWeb and all the pages feel much slower because Gecko performs bilinear image
When I set layout.css.dpi to 96, drawing in PaintWeb becomes real-time. I was amazed to see it works so well.
It's like on my desktop computer. And ... it's even faster than in Opera 10. ;)
If you want, check out the
performance tests yourself. Spoiler: Webkit is the fastest and Gecko is the slowest when running synthetic tests. Obviously, more performance
tests will come - these are only limited to the pencil tool and to the main
ev_canvas() event handler from
Next on my of list things to do is a new GUI and a packager for the entire
code. Loading PaintWeb is now slower due to the amount of code comments and the increasing number of files. The packager
will compress/minify all the files into a single one.
That's all for now. Any feedback is welcome!