On 23rd of April 2015, Mihai Șucan passed away due to metastatic
cancer caused by RDEB.
23 June 2009, 19:51
Hello again!
The
HTML 5 Canvas
specification defines two important methods for text rendering:
fillText()
and strokeText()
. You also
have a measureText()
and the associated text-related
properties: font, textAlign and
textBaseline.
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: mozDrawText()
, mozPathText()
,
mozTextAlongPath()
and mozMeasureText()
.
To style the text you only have the mozTextStyle
property.
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 day. :)
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.
Published in:
bugs,
canvas,
gecko,
gsoc2009,
html5,
opera,
paintweb,
svg,
text,
webkit.
14 May 2009, 11:09
Hello everyone!
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 activity views.
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 resampling.
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
PaintWeb.
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!
Published in:
canvas,
css,
dpi,
gecko,
gsoc2009,
moodle,
olpc,
opera,
paintweb,
performance,
webkit.