As per the plan for v0.2, I am ready with a working implementation of inkface. I also made few more design decisions after my last design post. Here are the highlights:
1. All code is in python
2. For X11 surfaces, pygame is used.
I found that pygame (python bindings for SDL) is a mature library for drawing on X11 surfaces. It also has some optimizations which help in 2D animations. There is also OpenGL support, but I do not plan to use it inside inkface library. It is also well supported on Maemo.
I have written my favorite twitter client app with the new inkface-pygame library. The following video demo shows, how I could quickly code 2D scrolling animation with the help of pygame.
The v0.2.0 is delivered as a tarball. I have also updated the inkface wiki with some getting-started tips.
Wednesday, February 25, 2009
Sunday, February 22, 2009
Smooth scrolling with Inkface+pygame
Preview of what's coming out later in the week. A v0.2 drop of inkface-pygame package for maemo and others should be ready in coming few days.
Saturday, February 14, 2009
Inkface v0.2 update and automated GUI testing
As I posted earlier, my work on v0.2 of Inkface is on track. It's implementation of an SVG library entirely in python, with the goal of dynamic rendering in mind.
This new implementation can now render some basic SVG shapes - rectangles, paths (except for arc), linear and radial gradients. Following video shows some of these shapes.
I spent most of today to write a regression test framework for this library.
Typically it's difficult to automate regression testing of a GUI library/app. But in this particular case, it is possible. The idea is to save SVG image's rasterized buffer into a PNG image, when we know it's correct by visual inspection. As new features are added to the library, the regression script rasterizes the same set of SVG images and compares their raster buffer with the that loaded from PNG files saved earlier. If new changes have modified the rendering, then the new rasterized buffer will be different from the loaded from PNG image.
You can find the regression script here. In fact, the above video is the same script run in visual inspection mode.
This new implementation can now render some basic SVG shapes - rectangles, paths (except for arc), linear and radial gradients. Following video shows some of these shapes.
I spent most of today to write a regression test framework for this library.
Typically it's difficult to automate regression testing of a GUI library/app. But in this particular case, it is possible. The idea is to save SVG image's rasterized buffer into a PNG image, when we know it's correct by visual inspection. As new features are added to the library, the regression script rasterizes the same set of SVG images and compares their raster buffer with the that loaded from PNG files saved earlier. If new changes have modified the rendering, then the new rasterized buffer will be different from the loaded from PNG image.
You can find the regression script here. In fact, the above video is the same script run in visual inspection mode.
Friday, February 13, 2009
Testing Android (Koolu Beta 3) on Openmoko Freerunner
[My Openmoko Freerunner hadn't got much love in a long time. So its battery discharged to absolutely no charge. Then I realised that I have got a deadlock - FR cannot turn ON without battery and the battery won't charge unless FR is ON (because the firmware can't negotiate enough current from USB port to charge the battery, the running FR kernel can do that). Anyway, after coming to India I got a cheap instrument that tests and charges generic cell-phone batteries like FR's. The device's simplicity is amazing. It has two metal probes that can be adjusted to make contact with the battery terminals and with help of two buttons you can either test battery's charge or start charging it. Point is, the external charging worked.]
Now the more important topic...
As the Freerunner came back to life, I decided to test the latest Android images on it. Openmoko wiki has details of all (three so far) efforts trying to get Android running on FreeRunner. I decided to try Koolu's images. They are frequently releasing new images and their latest release is billed as Beta 3. Flashing the phone was straightforward - just followed the instructions.
Once the phone booted into Android (the first boot seemed very slow, but subsequent boots took 1 minute as I timed them), I could see what's all the Android noise about. This is my first experience with Android (saw it a bit in emulator, but not much). Android has rendered the best GUI on the screen of this phone so far. I was impressed with some animation effects (whatever happened to glamo's limited capabilities to do accelerated graphics - although I am not sure yet if these effects are done in h/w).
Most importantly, I got the wifi working on this phone first time. No other distro I had tried in the past has enabled wifi of this device. Android, easily scanned and detected my wireless network. A small problem came, when entering the WPA2 key. Note that the only official Android phone out there (HTC G1) has hardware keyboard, so Google has been slow in implementing a virtual keyboard. However I found a keyboard after some exploring (dunno if it's Google-added or some community effort). This keyboard is not perfect, but it works. The problem is, it is not accessible when WPA2 key entry dialog appears. So I can't tap in the password. After looking at Koolu's release notes, I figured one workaround is to type the password in Notepad app and then paste it in the password box. That worked.
After connecting to wifi, I tested the browser, visiting many sites (yeah mostly those tweets some of you read ;). Another impressive app is email. Configuring my gmail account with it was a 2-step cake walk and I was in my inbox in no time. I could also compose an email without much trouble.
Sadly however, the GSM is not working. I am using Tata Indicom's SIM card - which should be in GSM 1800 band (and my Openmoko is 850/1800/1900). But still it didn't detect any network (It didn't work even with the Qt image I had earlier - so I won't blame Android for it). I read that the GSM libraries in Android are not yet completely open, so there are some difficulties there. I need to learn the GSM Modem commands to debug this issue.
The accelerometer works. There is an app named Amazed that lets you navigate a ball using the accelerometers inside the FR. It's really cool.
I don't expect GPS to work, (although the antenna icon keeps radiating green waves) - because GPS satellites don't like me. :)
I tested an alarm app, which confirmed that the vibrator and sound also work great.
The 'Global Time' app has that 3D revolving earth that's depicted in some youtube videos. But its FPS is not so great, I believe there is no h/w acceleration there.
I also browsed through the software repository. Installed a game 'MiniSpaceWar'. It installed correctly, but I guess it was too heavy for FR, it took forever to load and then crashed Android, leading to a reboot.
Unfortunately, I couldn't get a screenshot tool for android. So can't post any of them now. But if I manage to get any, I will tweet them.
Now the more important topic...
As the Freerunner came back to life, I decided to test the latest Android images on it. Openmoko wiki has details of all (three so far) efforts trying to get Android running on FreeRunner. I decided to try Koolu's images. They are frequently releasing new images and their latest release is billed as Beta 3. Flashing the phone was straightforward - just followed the instructions.
Once the phone booted into Android (the first boot seemed very slow, but subsequent boots took 1 minute as I timed them), I could see what's all the Android noise about. This is my first experience with Android (saw it a bit in emulator, but not much). Android has rendered the best GUI on the screen of this phone so far. I was impressed with some animation effects (whatever happened to glamo's limited capabilities to do accelerated graphics - although I am not sure yet if these effects are done in h/w).
Most importantly, I got the wifi working on this phone first time. No other distro I had tried in the past has enabled wifi of this device. Android, easily scanned and detected my wireless network. A small problem came, when entering the WPA2 key. Note that the only official Android phone out there (HTC G1) has hardware keyboard, so Google has been slow in implementing a virtual keyboard. However I found a keyboard after some exploring (dunno if it's Google-added or some community effort). This keyboard is not perfect, but it works. The problem is, it is not accessible when WPA2 key entry dialog appears. So I can't tap in the password. After looking at Koolu's release notes, I figured one workaround is to type the password in Notepad app and then paste it in the password box. That worked.
After connecting to wifi, I tested the browser, visiting many sites (yeah mostly those tweets some of you read ;). Another impressive app is email. Configuring my gmail account with it was a 2-step cake walk and I was in my inbox in no time. I could also compose an email without much trouble.
Sadly however, the GSM is not working. I am using Tata Indicom's SIM card - which should be in GSM 1800 band (and my Openmoko is 850/1800/1900). But still it didn't detect any network (It didn't work even with the Qt image I had earlier - so I won't blame Android for it). I read that the GSM libraries in Android are not yet completely open, so there are some difficulties there. I need to learn the GSM Modem commands to debug this issue.
The accelerometer works. There is an app named Amazed that lets you navigate a ball using the accelerometers inside the FR. It's really cool.
I don't expect GPS to work, (although the antenna icon keeps radiating green waves) - because GPS satellites don't like me. :)
I tested an alarm app, which confirmed that the vibrator and sound also work great.
The 'Global Time' app has that 3D revolving earth that's depicted in some youtube videos. But its FPS is not so great, I believe there is no h/w acceleration there.
I also browsed through the software repository. Installed a game 'MiniSpaceWar'. It installed correctly, but I guess it was too heavy for FR, it took forever to load and then crashed Android, leading to a reboot.
Unfortunately, I couldn't get a screenshot tool for android. So can't post any of them now. But if I manage to get any, I will tweet them.
Saturday, February 07, 2009
Clutter animation paths with Inkscape+Inkface (v0.1.3)
While I am working on inkface v0.2, I will keep releasing dot versions for 0.1.x that will have some improvements that are independent of altsvg backend. So I have posted v0.1.3 source tarballs.
Only major improvement in v0.1.3 is the exporting of path data of SVG path elements. This path data can be used by clutter based applications to create "Knots" (animation paths along which objects can move). Check out the following video.
In this app, four paths were drawn in Inkscape. Then using inkface v0.1.3 library their path data was made available to clutter app. The clutter app created "BehaviourBspline" using this data and made the ball and star move along these splines.
As can be seen, any complicated paths can be created using this method. Without it, one will have to calculate coordinates of each point along which one wants to animate (very tedious to calculate control points for Bézier curves).
v0.1.3 source tarballs: libaltsvg, inkface
The clutter app is a single python script available here (also part of inkface tgz). You are looking for element_to_bspline
Only major improvement in v0.1.3 is the exporting of path data of SVG path elements. This path data can be used by clutter based applications to create "Knots" (animation paths along which objects can move). Check out the following video.
In this app, four paths were drawn in Inkscape. Then using inkface v0.1.3 library their path data was made available to clutter app. The clutter app created "BehaviourBspline" using this data and made the ball and star move along these splines.
As can be seen, any complicated paths can be created using this method. Without it, one will have to calculate coordinates of each point along which one wants to animate (very tedious to calculate control points for Bézier curves).
v0.1.3 source tarballs: libaltsvg, inkface
The clutter app is a single python script available here (also part of inkface tgz). You are looking for element_to_bspline
Monday, February 02, 2009
Turning a page
"...What I think is, it's never
too late...or, in my case, too
early, to be whoever you want to
be...There's no time limit, start
anytime you want...change or stay
the same...there aren't any
rules...We can make the best or
worst of it...I hope you make the
best...I hope you see things that
startle you. Feel things you
never felt before. I hope you
meet people who have a different
point of view. I hope you
challenge yourself. I hope you
stumble, and pick yourself up. I
hope you live the life you wanted
to...and if you haven't, I hope
you start all over again."
- Benjamin Button
(Curious Case of Benjamin Button)
Today was my last day at my day job. From now on I will be devoting all of my time to my pet project. I am moving back to my home town Mumbai, after spending 6 wonderful years in US. I will be flying in few hours. Catch you from the other side of the planet!
Sunday, February 01, 2009
Planning Inkface v0.2
With v0.1.X of Inkface libraries feasibility of SVG based GUI framework is proven. With different experiments, the following structure seems to be evolving.
The inkface library provides canvas objects to draw on. These canvas objects can be implemented using different backends. Currently only X is used as backend. Clutter seems possible, it will be there in v0.2.X. Inkface library loads the SVG elements with the help of altsvg library. altsvg library is responsible for parsing the SVG document and rendering its component elements.
I spent past few weeks investigating the SVG rendering solutions that are out there. There are two major efforts in open source to the best of my knowledge: librsvg (Gnome library, which is the base of current libaltsvg) and Qt's couple of libraries (QtSVG and other being a KHTML component).
They are good libraries with their own advantages and pitfalls. But they are made with a simple purpose in mind - Parse the SVG document and render it as an image. They do not handle the individual elements of the SVG DOM tree in a dynamic way. This is the reason, none of them fully supports animation extension of SVG specs.
In the inkface framework, following two things are expected from the altsvg library:
1. Separate rendering of different elements of an SVG document.
2. Programmatic access to the SVG attributes of these individual elements.
I have spent very long time trying to understand librsvg. It was very painful to get it working the way it works right now. I am not satisfied with the patches I applied on top of librsvg to accomplish the 1st requirement above. (2nd requirement is not available in v0.1.X). I have faced great difficulty to understand the highly recursive logic of librsvg. It will take much larger effort to tweak it elegantly so that both the above requirements are fulfilled.
I also looked into Qt SVG libraries. Qt's code is elegant and easy to understand. But I am afraid, it is tightly embedded inside Qt framework (at least it will take long to tear it and take away what's needed, not sure if that's worth it).
After exploring above two options, I have also considered implementing altsvg from scratch. And that sounds like a better option after all. I have started experimenting with that option. Here are some details.
As the altsvg block shows, there are two distinct components in these libraries:
a) SVG parsing - nothing but a standard XML parsing
b) SVG rendering - librsvg uses cairo and QtSVG uses their PaintEngine for this logic.
I plan to reimplement the SVG parsing part. The rendering will be done by cairo or Qt's PaintEngine. Cairo and Qt's rendering library are mature libraries and their role is orthogonal to the above two requirements of the inkface framework.
Furthermore I figure that the SVG parsing part is not as performance critical as rendering part. But it will have to go through lot of iterations of design and implementation. So I will be implementing it in python. Python's excellent support for XML parsing will speed up the prototyping.
So far I see following advantages of implementing altsvg from scratch and that too in python:
1. It will save energy and time in trying to understand existing librsvg/QtSVG libraries and try to redesign them for the purpose that they might not have been designed for in the first place.
2. Some initial work on this front has proved that, I can totally eliminate the need for a designer to change in XML nodes in Inkscape. They will also not need to explicitly mention the order as an attribute of the element. The order in which the elements are shown in the Inkscape will be recognized by the inkface framework. Also the name of the element can be defined using Inkscape's "Object Properties" option in the context menu.
3. Most of the developers who have inquired about this project, have asked about the portability. The choice of python will help address that issue.
4. It certainly would be a daunting task to aim for a full SVG compliance with my own implementation. But in retrospect, I think that's not the goal. It's not necessary initially to implement all of SVG spec. Some basic features like paths (lines, bezier curves, rectangles, ellipses) and gradients should be available soon enough. They are the most widely used elements. Further features like filters can be implemented incrementally. I suspect, that will be a translation of librsvg's cairo calls to PyCairo calls.
5. I am not sure how can I do this, but a progressive rendering of SVG elements seems possible. It will need more interaction between inkface and altsvg. It will improve load time of the GUI.
There are other two topics as well. But I may address them in some later post. Implementation of inkface (its role in the big picture, the clutter backend) and benefits of using OpenGL for rasterization (Qt has a proven advantage over cairo in this regard. I know glitz can solve this problem for cairo, but I didn't find any numbers to support that)
The inkface library provides canvas objects to draw on. These canvas objects can be implemented using different backends. Currently only X is used as backend. Clutter seems possible, it will be there in v0.2.X. Inkface library loads the SVG elements with the help of altsvg library. altsvg library is responsible for parsing the SVG document and rendering its component elements.
I spent past few weeks investigating the SVG rendering solutions that are out there. There are two major efforts in open source to the best of my knowledge: librsvg (Gnome library, which is the base of current libaltsvg) and Qt's couple of libraries (QtSVG and other being a KHTML component).
They are good libraries with their own advantages and pitfalls. But they are made with a simple purpose in mind - Parse the SVG document and render it as an image. They do not handle the individual elements of the SVG DOM tree in a dynamic way. This is the reason, none of them fully supports animation extension of SVG specs.
In the inkface framework, following two things are expected from the altsvg library:
1. Separate rendering of different elements of an SVG document.
2. Programmatic access to the SVG attributes of these individual elements.
I have spent very long time trying to understand librsvg. It was very painful to get it working the way it works right now. I am not satisfied with the patches I applied on top of librsvg to accomplish the 1st requirement above. (2nd requirement is not available in v0.1.X). I have faced great difficulty to understand the highly recursive logic of librsvg. It will take much larger effort to tweak it elegantly so that both the above requirements are fulfilled.
I also looked into Qt SVG libraries. Qt's code is elegant and easy to understand. But I am afraid, it is tightly embedded inside Qt framework (at least it will take long to tear it and take away what's needed, not sure if that's worth it).
After exploring above two options, I have also considered implementing altsvg from scratch. And that sounds like a better option after all. I have started experimenting with that option. Here are some details.
As the altsvg block shows, there are two distinct components in these libraries:
a) SVG parsing - nothing but a standard XML parsing
b) SVG rendering - librsvg uses cairo and QtSVG uses their PaintEngine for this logic.
I plan to reimplement the SVG parsing part. The rendering will be done by cairo or Qt's PaintEngine. Cairo and Qt's rendering library are mature libraries and their role is orthogonal to the above two requirements of the inkface framework.
Furthermore I figure that the SVG parsing part is not as performance critical as rendering part. But it will have to go through lot of iterations of design and implementation. So I will be implementing it in python. Python's excellent support for XML parsing will speed up the prototyping.
So far I see following advantages of implementing altsvg from scratch and that too in python:
1. It will save energy and time in trying to understand existing librsvg/QtSVG libraries and try to redesign them for the purpose that they might not have been designed for in the first place.
2. Some initial work on this front has proved that, I can totally eliminate the need for a designer to change in XML nodes in Inkscape. They will also not need to explicitly mention the order as an attribute of the element. The order in which the elements are shown in the Inkscape will be recognized by the inkface framework. Also the name of the element can be defined using Inkscape's "Object Properties" option in the context menu.
3. Most of the developers who have inquired about this project, have asked about the portability. The choice of python will help address that issue.
4. It certainly would be a daunting task to aim for a full SVG compliance with my own implementation. But in retrospect, I think that's not the goal. It's not necessary initially to implement all of SVG spec. Some basic features like paths (lines, bezier curves, rectangles, ellipses) and gradients should be available soon enough. They are the most widely used elements. Further features like filters can be implemented incrementally. I suspect, that will be a translation of librsvg's cairo calls to PyCairo calls.
5. I am not sure how can I do this, but a progressive rendering of SVG elements seems possible. It will need more interaction between inkface and altsvg. It will improve load time of the GUI.
There are other two topics as well. But I may address them in some later post. Implementation of inkface (its role in the big picture, the clutter backend) and benefits of using OpenGL for rasterization (Qt has a proven advantage over cairo in this regard. I know glitz can solve this problem for cairo, but I didn't find any numbers to support that)
Subscribe to:
Posts (Atom)