The major advantages of this change are
- qualitiy improvement of the output images,
- performance improvement, and
- the ability to create native vector-based PDF documents.
It was a long outstanding task for me to move away from libgd and I should have used libcairo from the beginning. I would have saved myself a lot of time for development. But on the other hand the relevant code now is much more straight forward.
Why libcairo instead of libgd?
Libgd is a really nice graphics library which I have used a lot in the past for several small projects. I think it got prominent with PHP where it es widly used to create small images on the fly.
The major advantage of libgd is that it got a very simple API. Everybody, independently if familiar with producing images or not can start to use it within 2 minutes of studying one or two code examples.
Although the API of libcairo is not very difficult to understand one still has to spend some time to read through the introductory docs to understand the core concepts. But now I just can encourage everybody to take some time for it. Particularly if you intend to create more complex images than just some lines and rectangles.
Libgd has some drawbacks which hit me during the development of Smrender. You should considered the following issues before using it.
- It has no support for layering. This means that any drawing operation is always directly executed on your image. You cannot construct some complex intermediate figures (for example nested multi-polygons) to finally paint it to the background at once. You have to manually program it as I did with Smrender.
- Libgd has only a limited support for anti-aliasing which tends to give bad results in some cases. This is the reason why I had to implement oversampling myself (you may read this article) but this has a dramatic impact on performance.
- It does not support bevelling at all.
- Although the built-in text API of libcairo is called a toy text API it is still much more than that compared to libgd’s real toy text API 😉 The worst thing about it is that you cannot exactly derive the origin of rendering a text string even if you retrieve the font extents.
These are reasons why I had to implement a lot of additional stuff around libgd and why I now changed to libcairo which supports all of that very well.
What else is new with version 3.0?
As already mentioned it now is able to create PDF documents directly (see option -O).
The auto-rotation code is now the third generation. Although it is similar to the first one in its workflow (which is subject to change 😉 it has an improved color difference detection by using a luminosity formula instead of the 3D color distance. The same code is also used for auto-rotation of images which is completely new.1
Several code cleanups were done and the ruleset is updated.
The option -a was added. By default Smrender now only renders nodes which are within the visible range. Option -s was removed. The action exit() was added for debugging purpose.
Smrender has support for KAP/BSB files which have a limited color space of 7 bit at a maximum. Thus, Smrender reduces the 24 bit color space. It turned out the the histogram function is not perfect 😉 which might lead to the case of wrong colors in the KAP file. Of course, this will be fixed.
I updated the documentation accordingly. Go to the projects home page at http://www.abenteuerland.at/smrender/ for download and documentation.
Have fun using Smrender and don’t hesitate to contact me if you have any questions!
- All older revisions still used the simple 1st generation code with a static background color. ↩