Tumbleweed Goes to Cairo

I briefly mentioned in a previous post that I was looking into options for providing a GUI on top of Tumbleweed. Now that Tumbleweed has a direction, to become an interactive media authoring solution, work needs to progress choosing a method for drawing graphics from Tumbleweed. For this reason, I’ve spent a significant amount of time investigating options and prototyping possible solutions, including OpenGL, Cairo, Skia and others.

What Matters

While looking at the options available, I’ve tried to keep some key considerations in mind:

  1. Cross platform
    It should be possible to run whatever solution I settle on across many platforms, initially at least Windows, MacOSX and Linux, but any other platform options going forward is a definite benefit.
  2. Depth
    It should be possible to create a wide variety of graphical styles directly from Smalltalk. The solution should enable choice, not force the user down one particular road.
  3. Future-proof
    In as much as that goal is ever really possible, a solution that has mileage will get significant plus points.
  4. History
    As important as the life expectancy, is the pedigree, a solution that has been around for a while, and has had time to stabilise and prove itself is more appropriate than a relatively new and untested solution.

Options

Some of the alternatives I’ve looked into include:

  • OpenGL
  • Cairo
  • Skia
  • Fog
  • SFML
  • SDL

Evaluation

I quickly eliminated SDL, as I couldn’t easily find a way to create a simple Window for drawing into without all the extra baggage of a prescribed ‘main’ entrypoint. It may be possible to achieve this, but I couldn’t readily find it. For drawing context management, SFML seems like a much more suitable choice. In prototyping, I very quickly had it bound to Tumbleweed sufficiently to be able to create a window and draw some textured sprites into it. The recent introduction of struct support to the FFI framework made event management possible with SFML too.

Moving forward with the promising SFML, I began to think that the drawing capabilities it offers would soon seem limited. I started looking at more functional vector drawing libraries. Cairo is an immediate obvious choice, with it’s pedigree and broad usage base. I researched this for a while, and came across many conflicting reports about it’s performance. Skia seems to have been created specifically to address those concerns, so I looked closer at that option. Skia is relatively easy to build on at all three platforms, however, I felt the documentation to be a bit weak, and moreover the project as a whole just feels very immature at this point, one to watch definitely. Fog is based on the previous public domain incarnation of Antigrain Geometry (AGG), and again is designed to address the performance concerns of Cairo, but also seems to be very immature compared to Cairo at this point. Fog does have the advantage the it offers a drawing context abstraction layer as well. Another to watch.

I decided to spend some time with the three vector options, Cairo, Skia and Fog. While the quoted performance concerns around Cairo did cause me some concern, I found that there is an (experimental) Skia back-end for Cairo, and of course the OpenGL one too. I currently feel that the stability and completeness of Cairo outweighs the performance concerns, at least for now. I already had the SFML binding working, so it seemed logical to continue the prototyping from there. Borrowing from an old SFML/Cairo code snippet I found on the SFML wiki, and re-enabling the FFI callbacks mechanism in Tumbleweed, I now have a prototype system working whereby I can draw Cairo into an SFML texture, apply it to a sprite and draw it into a window.

Shifting Towards Cairo and SFML

I will be continuing with this approach for some time, as it seems to have the most legs of all the options. The side advantage of using SFML for the display context management, means I can bind OpenGL as well at some point, to get into the 3D realm. My main concerns are around speed of rendering. The solution at the moment creates a Cairo image surface, draws into that, and then transfers the pixels to the SFML texture. It is cached, so if the Cairo doesn’t need to change, all is good, only when the vector drawing needs to change or animate might there be performance issues. As this framework will form the ide part of the system too, text editing is obviously going to be majorly important. Including Pango into the mix seems like the obvious choice for layout management, whether the image surface approach will suffice for text editing remains to be seen.

More to come…

This entry was posted in Blog and tagged , , , , , , . Bookmark the permalink.

Leave a Reply