Moodle 2.0 and PaintWeb test site

7 September 2009, 16:04

Hello everyone!

Two days ago I have uploaded a snapshot of the PaintWeb code and the integration scripts for Moodle 2.0 and Moodle 1.9, as required for the Google Summer of Code program. This snapshot contains only the code I contributed up until 14th of August 2009, and you can download it from the Google Summer of Code 2009 Moodle project site. Obviously, this code is provided only for recording the milestone I reached for the GSOC project deadline. Any paint tool user is supposed to get the latest code from my Git repository or from the PaintWeb project site.

Thanks to Anthony Borrow and Jordan Tomkinson, today a Moodle 2.0 with PaintWeb test site has been published. So, now you can try PaintWeb directly in Moodle. Make sure you login with the teacher account: user. Password is: demo.  

To try the paint tool, I have created a test course, and I added a glossary activity. Inside the glossary activity there's a concept I added. Go ahead and play with the glossary: add, edit or delete concepts. In the TinyMCE editor you can create new images and edit them seamlessly.

It should be noted that Moodle 2.0 and the paint tool integration are both under development. This means that Moodle devs have not yet completed upgrading all the code which deals with the HTML editors - so, other pages where TinyMCE is used might not have PaintWeb enabled because the configuration is still in "legacy mode" (no file attachments are allowed).

Anyone is welcome to provide me with feedback on the user experience, and any other thoughts.

Thanks!

Published in: gsoc2009, moodle, paintweb.

PaintWeb presentation at LVLE 2009

31 August 2009, 16:28

Hello everyone!

Beside bug fixing and polishing PaintWeb in the past weeks, I have also prepared a presentation about all the work I did this summer, as part of my Google Summer of Code project. As such, I talked about my GSOC project at the Linux and Virtual Learning Environments 2009 seminary on Friday, the 28th of August.

You can download the presentation slides in Romanian and in English (PDF). You may also watch the slides online at Scribd.com, both in Romanian and in English. Any feedback is welcome!

Published in: arad, gsoc2009, lvle, moodle, paintweb, romania, talks.

GSOC conclusions

21 August 2009, 09:34

Hello everyone!

Since my previous blog post I did some polishing to the Moodle 2.0 integration. Dan Poltawski from the Moodle community has provided his valuable feedback. He suggested I switch the parsing of the data URL to a regular expression and that I warn users before submitting a form while editing an image with unsaved changes. I made both of these changes and now I am looking forward for more feedback.

This blog post is more about the overall Google Summer of Code conclusions. So, here we go. I started from a simple PaintWeb demo application, which had only one JavaScript file of about 6000 lines of code, without any proper jsdoc-formatted comments. Over the summer I did the following:

1. Split the whole code into multiple files: per drawing tool, per extension, per language.
2. Created a new configuration file which allows changing almost any option inside PaintWeb, including keyboard shortcuts, tools, extensions and more.
3. Reorganized the entire code, followed more strict coding guidelines, more naming consistency, etc.
4. Wrote jsdoc-formatted comments for every function and method. Based on the code now I can generate a complete and up-to-date PaintWeb API reference documentation.
5. Changed the way PaintWeb loads: the whole GUI is loaded using an XMLHttpRequest from the server and added into the page. The PaintWeb demo was a stand-alone Web application, but now PaintWeb is a component which can only be used within another Web application - in a similar fashion to how TinyMCE can be used.
6. Developed a new API for PaintWeb extensions, tools and "commands". This allows new developers to easily extend and modify PaintWeb at any time.
7. Implemented a new PaintWeb extension: MouseKeys. This allows users to draw with the keyboard - no mouse is needed.
8. Reimplemented keyboard shortcuts support such that it works much better across different Web browsers. You can learn about this work from the latest tutorials I wrote for Dev.Opera about keyboard accessibility in Web applications.
9. Made important performance improvements for the OLPC XO.
10. Split the GUI into multiple files: an XHTML file, a CSS and a JavaScript file. This allows me to focus on GUI code, or on the base code of PaintWeb.
11. Implemented a new GUI for PaintWeb, with better keyboard accessibility, and with a new logo.
12. Implemented a new "application events" API which allows developers to hook into PaintWeb by means of events. For example, developers can listen for events like "imageSave" or "imageSizeChange". Such application events are used heavily in the new interface implementation.
13. Implemented numerous selection tool improvements and fixes.
14. Implemented a new "Hand" tool for dragging the image inside the viewport.
15. Made some important fixes for the Eraser tool.
16. Made PaintWeb behave better with huge images - around 6000 x 6000 pixels.
17. Made improvements to the Text tool and implemented better cross-browser compatibility. Also, attempted Opera compatibility with no luck.
18. Made PaintWeb ready for "production use" by properly packaging the whole Web application. The PaintWeb packaging process is driven by a Makefile.
19. Wrote "some" PaintWeb documentation.
20. Wrote a hefty TinyMCE 3 plugin for easy PaintWeb integration into TinyMCE 3.
21. Updated some patches for TinyMCE 3 integration into Moodle 1.9.
22. Implemented Moodle 1.9 and Moodle 2.0 integration - with different levels of success. That is, Moodle 2.0 integration is succesful and working properly, while the Moodle 1.9 integration still requires additional work due to the lack of a file API.

That's about all I did over this summer. I am very pleased with the results. In some cases, the results are beyond my initial expectations. For example, I did not expect to have so much PaintWeb documentation done over the summer. Writing the code for all of the above was fun and a pleasure for me.

The Moodle community has been really great and friendly. I appreciate all the feedback I got from the whole community.

What's next? Well, I hope this GSOC marks the beginning of a fruitful collaboration with Moodle and with the overall open-source community. I would like to continue work on Moodle 1.9 and 2.0 integration, and further improve PaintWeb. I certainly do not want to abandon the project. :)

I must thank Helen Foster and Martin Langhoff for their constant support over the summer, with feedback and testing. For example, Martin has provided important help with the performance work for the OLPC XO, together with Robert O'Callahan from Mozilla. And Helen was always ready to answer any GSOC-related questions. ;)

Last, but not least, thanks to Olli Savolainen and Jose Cedeno - two of the Moodle GSOC students who were very helpful, by testing PaintWeb and by providing valuable feedback.

Published in: gsoc2009, moodle, paintweb.

Moodle 2.0 integration

14 August 2009, 10:36

Hello everyone!

Together with my mentor, Martin Langhoff, we have decided that it's better for me to focus on the Moodle 2.0 integration of PaintWeb. This is because Moodle 1.9 lacks a file API sufficiently advanced to meet the needs of PaintWeb usage. Martin opened a relevant thread in the Moodle forums about storing images as attachements to text fields - it's worth reading to understand why PaintWeb integration is far from trivial. Moodle 2.0 has the solution to our problem: the new File API.

Focusing on Moodle 2.0 integration does not mean we do not want to complete the work started for Moodle 1.9. However, we want to have PaintWeb ready for core integration, for the Moodle 2 final release. The plan is for me to resume work on Moodle 1.9, some time later.

The Moodle developers are hard at work for the new Moodle 2.0. They've done numerous improvements. If you like Moodle 1.9, you will love Moodle 2.0. Integrating PaintWeb into the new version was much nicer and quicker.

I completed the integration of PaintWeb into TinyMCE, and I also made the image save action to work quite well. Images are saved in the draft file area, as is the rule for any textarea-attached file.

If you want to get the Moodle 2.0 code with PaintWeb, get it from my Git branch. Instructions:

git clone git://repo.or.cz/moodle/mihaisucan.git ~/src/moodle
cd ~/src/moodle
git checkout -b mdl20-paintweb origin/mdl20-paintweb

You might be interested to read the technical details about the Moodle 2.0 integration work, published at Moodle Docs.

Since my last blog post, I also made important updates for the entire PaintWeb documentation.

Olli Savolainen has provided me with more suggestions which I implemented. Thus, I changed the color to yellow, for the "plugin bar" of the TinyMCE plugin. I also made the "Save" and "Cancel" buttons look better. Last, but not least, based on his suggestion I found a fix for the "Edit" overlay button, for Firefox. For some reason, the button was not easily clickable in Gecko-based browsers. The problem is now gone. Thank you very much, Olli!

For better usability, I made the whole PaintWeb GUI resizable. Now, users are no longer stuck with the fixed dimensions. The TinyMCE plugin has been updated to synchronise the size of the editor area with the size of the PaintWeb image viewport, for a better user experience.

You can go ahead and try the updated PaintWeb+TinyMCE demo.

With the latest work, I am meeting the Google Summer of Code project goals: the development and integration of a paint tool inside Moodle via TinyMCE. There's only some polishing work left to do, and code reviewing from more Moodle developers.

Published in: gsoc2009, moodle, paintweb, tinymce.

PaintWeb integration progress

4 August 2009, 11:15

Hello everyone!

I would like to update you all on the latest happenings in the Moodle and PaintWeb land.

I have fixed some bugs in my TinyMCE plugin which prevented it from working properly in Firefox 3.0. I also made a number of improvements to the plugin and PaintWeb itself: images can now be saved as JPEG, not only as PNG. In Opera 10 and Firefox 3.5 developers can now save Canvas images as JPEG - which is great. Thus, when you edit a JPEG image, PaintWeb uses the JPEG format to update the file. Another improvement for the plugin is now you can click the PaintWeb icon in the TinyMCE toolbar even when an image is not selected. When you do this, a dialog comes up which allows you to create a new empty image - you can setup image dimensions, background color and other options.

PaintWeb now offers better visual feedback when the image you are editing is transparent. Background color support is now improved, albeit it's missing a GUI option to change it at will - this is going to be implemented some time after the end of GSOC. Also, as explained above, PaintWeb can now save images as JPEG, thus I should provide a GUI feature for users to pick the file format they want.

Moodle 1.9 integration has progressed up to the level that now PaintWeb is entirely usable and I am quite happy with the result. Image save is currently implemented in two ways: images are saved as data URLs or as files inside the Moodle data directory. Both saving method have advantages and disadvantages. Me and Martin, we are currently discussing ways of improving image saving as files. You can read all the gory details about the Moodle 1.9 integration of PaintWeb in a Moodle Docs wiki page I wrote.

In related news, I have created a Twitter account for "ROBO Design" (for me and my twin brother). You can follow our updates on Twitter as they happen. Additionally, I published the Planet ROBO Design site, where you can follow all the updates on what we do (and I mean all updates). This small "planet" aggregates all the feeds related to us - it's a single place where you can follow anything we do.

Don't forget you can always try the PaintWeb demos online. Any feedback is always welcome!

Published in: gsoc2009, moodle, paintweb, twitter.

PaintWeb and Moodle Git repository

24 July 2009, 12:21

Hello everyone!

I am getting closer to having a Moodle demo ready with PaintWeb integrated. Wednesday I had a very fruitful discussion with my mentor, Martin, on how I should proceed with the implementation of file saving inside the Moodle data directory. We have come to a conclusion which I am about to implement. More details soon.

For now, I have registered a Moodle Git repository mirror over at repo.or.cz. I have also registered a Moodle "fork" where I publish my Moodle branches. You can do:

git clone git://repo.or.cz/moodle/mihaisucan.git ~/src/moodle-mihai
cd ~/src/moodle-mihai
git checkout -b mdl19-paintweb origin/mdl19-paintweb

With that, you can easily and quickly get an always up-to-date Moodle 1.9 stable branch with TinyMCE 3 and PaintWeb integrated. You can already play with PaintWeb in Moodle.

If you only want the TinyMCE 3 editor you can do:

git checkout -b mdl19-tinymce3 origin/mdl19-tinymce3

The TinyMCE 3 branch holds Moodle 1.9 stable with the latest TinyMCE 3 integrated. The work I did on this branch is best explained in a Moodle forum discussion.

When you want to update your branch simply invoke git pull. Please also check the official documentation about how to use Git.

In related news, Opera Software has published the final part of the article serie I wrote about keyboard accessibility in Web applications. This article details the cross-browser compatibility layer implementation for keyboard events used by PaintWeb.

Enjoy!

Published in: git, gsoc2009, moodle, opera, paintweb, tinymce, tutorials.

Updated TinyMCE 3 in Moodle 1.9

17 July 2009, 11:05

Hello again!

The Google Summer of Code midterm evaluations passed without any problems for me, yay!

I have began work on integrating PaintWeb into Moodle. I will integrate my project into the stable Moodle 1.9 branch and into the upcoming Moodle 2.0 release.

Moodle 1.9 has a very old TinyMCE release (version 2.0) which is not used by default - the even older HTMLArea is still used. Both do not work in Opera and Google Chrome. For this reason Martin Langhoff, my mentor, and other Moodle community members have worked on patches to switch to the modern TinyMCE 3 editor. A clean port of TinyMCE 3 to Moodle 1.9 is available on the Moodle forums.

The clean port is quite well done, but again, it was "outdated", being from october 2008.

For PaintWeb I took the work Martin did and updated it to the latest Moodle 1.9 stable branch, the latest TinyMCE 3 version, and made additional fixes. One fix was to make the editor show up in Opera, Safari and Chrome, and another fix was for the script which converts TinyMCE language files to Moodle language files.

PaintWeb integration into Moodle 1.9 will come as a patch on top of the TinyMCE 3 patch. Currently I got PaintWeb loading fine in TinyMCE, inside Moodle. More work is needed to get file save working. For PaintWeb I did some assorted fixes for the Makefile, for the overall keyboard accessibility, for multi-language support, and I did improvements to the TinyMCE plugin.

You can download the updated TinyMCE 3 patch for Moodle 1.9. The package includes usage instructions.

In other related news, Opera Software has published the second part of the article I wrote about keyboard accessiblity in Web applications. This article describes the inner workings of the MouseKeys extension for PaintWeb. Make sure you checkout the updated and improved source code of the MouseKeys extension in the PaintWeb code tree.

Have fun until the next time!

Published in: gsoc2009, moodle, opera, paintweb, tinymce, tutorials.

PaintWeb documentation and TinyMCE plugin

8 July 2009, 14:03

Hello again!

In the past week there was important progress on PaintWeb. I have published several wiki pages about PaintWeb on Google Code - this documentation comes as an overview or a guide to the entire codebase and the API reference. You can read about how to integrate PaintWeb into your Web application, how to extend PaintWeb, how to package PaintWeb yourself with the Makefile, and how to use the new TinyMCE plugin.

I have completed a new TinyMCE plugin which allows you to easily and quickly integrate PaintWeb. This plugin allows users to click an "Edit" button which is overlayed on top of the editable images. The plugin also includes a context menu item (right-click and choose "Edit image"), and a toolbar button.

I have published a new demo page which shows the latest TinyMCE and PaintWeb working together. Enjoy!

Moodle integration is currently being planned. I wrote my thoughts and questions in a Moodle Docs wiki page about the paint tool integration.

Last, but not least, for the purpose of tracking progress, I have attached a packaged PaintWeb snapshot to the Moodle tracker issue associated with my project.

Olli Savolainen has created some very good mockups as proposals to improve the PaintWeb user interface. His feedback is very much appreciated, and I really hope to get to implement his suggestions as soon as possible. Thanks Olli!

On a related note, for those interested on how PaintWeb implements keyboard shortcuts, Opera Software has just published the first part of a series of articles I wrote on this topic. More articles will be published soon at the Opera Developer community site.

Have fun testing PaintWeb and reading articles about it. Don't forget that I am always looking forward for feedback!

Published in: api, documentation, gsoc2009, moodle, opera, paintweb, tinymce, tutorials.

API reference and packaging for PaintWeb

2 July 2009, 19:52

Hello everyone!

Since my last blog post I have completed the user interface polishing for PaintWeb: the Color Mixer and the Color Picker are both working fine now.

Today I have completed work on packaging. I also generated the complete API reference documentation from the source code.

You can go and play with the PaintWeb demo at the usual location.

For packaging I use a Makefile, YUICompressor, jsdoc-toolkit, PHP and some bash scripts. First of all, I merge all the JavaScript files into a single file. I also merge the XHTML interface layout inside the JavaScript - for this I use a small PHP script which encodes the string using json_encode(). Once I have the hefty script, I use the YUICompressor tool to make it a lot smaller.

For the PaintWeb interface stylesheet I use the YUICompressor in combination with a simple PHP script I wrote. The PHP script inlines the PNG images using data URIs. This helps a lot in reducing the number of elements being downloaded.

Here are the numbers, for those curious of the packaging results. Before packaging:

• 18 JavaScript files, 426.6 KB;
• Three JSON files, 33.9 KB;
• One XHTML file, 14.9 KB;
• One CSS file, 21.8 KB;
• 47 images (PNGs), 206.5 KB;
• A total of 70 files, 703.7 KB.

That's quite much. Here's what the current level of packaging gives us:

• Two JavaScript files, 130.7 KB - one of them, json2.js, is only 3 KB and is not always loaded;
• Three JSON files, 33.9 KB. The JSON files are left untouched, the configuration example stays the same - with all the comments in it. It's up to the integrator to choose what he/she does with the file (at the moment).
• One CSS file, 297.1 KB - with all the images inlined;
• A total of only 6 files, worth of 461.7 KB.

That's better, but there's room for more. You should always enable gzip compression on your Apache server. Here's what a properly configured server can give you:

• Two JavaScript files, 35 KB;
• Three JSON files, 8 KB;
• One CSS file, 99 KB;
• A total of six files, and only 142 KB.

That's much better now. To properly configure your server, make sure you enable gzip compression in your .htaccess file:

<IfModule mod_deflate.c>
  <FilesMatch "\.(js|css|json|html)$">
    SetOutputFilter DEFLATE
  </FilesMatch>
</IfModule>

If you are curious how fast PaintWeb loads, I added a timer in the demo script - you can take a look in a JavaScript console in your Web browser. On my local system it takes less than a second, depending on the browser I use. Go ahead and try PaintWeb yourself. Also make sure you check out the API reference.

In the coming days I will be publishing guides on PaintWeb development, extensibility and general code overview. This means Moodle integration is ready to begin!

Published in: apache, api, documentation, gsoc2009, makefile, moodle, paintweb, performance, yui.

Canvas text rendering

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.

PaintWeb has a new user interface!

22 June 2009, 08:29

Hello everyone!

Since my previous blog post I have been doing lots of changes under the hood. Lots of them broke PaintWeb badly and made it unusable for about two weeks - sorry for the lack of updates.

Now PaintWeb is back in a better shape and close to being complete. Here's the list of changes:

• new user interface.
• some new icons and a new PaintWeb logo.
• keyboard shortcuts work for all tools and commands properly - no issues like in previous PaintWeb trunk builds.
• changed the PaintWeb initialization a lot. Now PaintWeb is only available as a JavaScript component/library which can be integrated by Web developers easily in their applications.
• lots of new API for registering new tools, extensions and commands into PaintWeb.
• I changed the entrance to PaintWeb. Now users have to load a demo page which has minimal code for integrating PaintWeb.
• made the Text tool to work in Opera 9+ and Firefox 3.0 as well. Unfortunately, there are some Opera-related bugs in the Text tool - changes might come.
• rendering shadows works again in browsers which have support for it (Chrome, Firefox 3.5, Safari, Konqueror).
• changed the selection marquee - now it's a nice dashed border.
• added the option to crop the image to the size of the current selection.
• several bug fixes related to editing huge images (say 6000 x 6000 pixels).
• lots of other bug fixes and minor changes.

With all that I have completed the code reorganization and I have almost completed the implementation of the new GUI. This week I am working on the updated color mixer, after which I will work on the PaintWeb packaging scripts.

Go ahead and test PaintWeb yourself! If you want to see a list of detailed changes, you can read the SVN commit log.

Anyone is welcome to provide me with feedback, suggestions, and bug reports. Thank you!

Published in: gsoc2009, gui, paintweb.

PaintWeb performance

28 May 2009, 11:55

Hello everyone!

This week I have completed my work on performance testing and improvements for PaintWeb on the OLPC XO laptop.

During testing it became obvious that something other than the actual Canvas painting was very slow on the XO. The main performance culprit is that the default Gecko-based browser is configured to render pages using 134 DPI instead of the default 96 DPI. Generally web browsers render pages using 96 DPI. If the XO web browser would do the same the texts and the images would be far too small - the XO display is an odd 200 DPI screen perceived as 134 DPI.

PaintWeb's drawing performance was hugely affected by the bilinear scaling of the Canvas elements being done by the browser on the XO. When I configured the browser to render the page using 96 DPI, the web application became a lot more responsive.

Martin Langhoff, my mentor, got in contact with Robert O'Callahan from Mozilla. He provided us with lots of help in finding a solution for the performance issue.

We did think about having a CSS property to change the DPI only for the Canvas elements, or a different CSS property to disable scaling, or some proprietary API for changing the DPI on a single page. None of these are good ideas, because they allow web developers to start coding for specific DPIs - this is not desired.

Gecko scales pages using integer scaling factors - that's 1, 2, 3, etc - it doesn't use floating point numbers. In a normal Gecko build the scaling factor for 134 DPI is 1 - because 134 / 96 = 1, so you do not get any scaling. You can have a scaling factor of 2 or higher if you go above 192 DPI.

Gecko is patched on the XO in a way that it forces the browser to scale pages using floating-point scaling factors as well. Therefore, for 134 DPI the pages are scaled and they look really good on the XO screen.

The final solution which I implemented into PaintWeb is to simply scale down the Canvas elements in my document. If I accurately scale down the elements, Gecko is sufficiently optimized to cancel any scaling and you do not notice any performance impact. This works really great.

In Gecko 1.9.1 (Firefox 3.5) I can detect the DPI used for rendering the page with CSS 3 Media Queries. I use this in PaintWeb. However, the XO only has Gecko 1.9.0 for now, so I cannot determine the DPI. I am forced to do user agent sniffing to check if the browser runs on the OLPC XO. If it does, then I scale down the Canvas elements using a different way of calculating the scale-down factor - because Gecko is patched - and I always consider the page is render using 134 DPI. Fun, huh? ;)

On Opera, on the XO, I did all my testing using 100% zoom level. It ran much better than Gecko, for obvious reasons (no scaling, yay). Once I fixed the Gecko scaling issue, Opera came second. For some reason Canvas draws much faster in Gecko than in Opera on the OLPC XO.

Opera cannot render pages using different DPI values other than 96. People use zoom, so, for consistency, I use an old trick to measure the zoom level (thanks Arve). Based on this I scale down the Canvas elements. For some zoom levels, like 200%, the scaling is cancelled and PaintWeb works better. Unfortunately, Opera does not allow non-integer pixel values, thus the scaling-down is generally not effective...

Another important performance improvement in PaintWeb is the use of timer-based canvas drawing. This means that mouse move events are either cancelled or coalesced into one. For example, redrawing a polygon with a lot of points for every mouse move is very slow. The tools in PaintWeb use timers to update the canvas every few milliseconds. This approach makes PaintWeb feel faster.

Lastly, I now avoid going into the global scope, for things like Math.round or such. The importance of this change is reduced by the fact the JavaScript that runs is not very intensive - not too much code is executed for each mouse move event. Such changes become more important the more code you run. This will be important for the color space visualization I have.  

The loading performance will improve greatly once I will make a packager for PaintWeb. Additionally, I will continue to constantly check the overall performance of the web application on the OLPC XO.

Go ahead and try PaintWeb from SVN trunk. Lots of thanks to Robert for his great help and to Martin for his assistance and for finding the Gecko patches.

Currently I am working on the new user interface, stay tuned!

Update May 31, 2009: Just published a page on the OLPC wiki about the HTML Canvas performance on the OLPC XO laptops. The page includes code snippets explaining how to work-around the scaling issue.

Published in: canvas, css, dpi, gecko, gsoc2009, moodle, olpc, opera, paintweb, performance.

PaintWeb code refactoring and more

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.

Google Summer of Code for the Moodle project

23 April 2009, 14:58

Hello everyone!

I have great news this time! I have applied to work for the Moodle project over the summer within the Google Summer of Code program. My project proposal has been accepted. This means that over the summer I will be working on integrating the PaintWeb project into Moodle. Part of this work will also include a complete code reorganization and several important improvements.

Locally I have already started working towards code reorganization and a complete rework of the keyboard shortcuts support inside PaintWeb is ready. This work will become public very soon.

I am really glad to be working with one of the best open-source educational software. The Moodle community has been very nice and they welcomed me warmly. Congratulations to every student who has been accepted this year!

On a related note, Opera Software has published a tutorial I wrote about how you can start developing your own paint tool. The code presented is strongly based on my work for PaintWeb. Another new tutorial is now being prepared for publishing.

Best luck to everybody and stay tuned for more!

Published in: gsoc2009, moodle, opera, paintweb, tutorials.