I’m told Rust is great, where are the graphics libraries?

While I’m still a bit sour that Mozilla decided to use the same name for their language as an old project of mine (which is not a new thing for Mozilla anyway, if someone remembers the days of Phoenix and Firebird), I have been looking from the sideline as the Rust language as a way forward to replace so many applications of embedded C, with a significantly safer alternative.

I have indeed been happy to see so much UEFI work happening in Rust, because it seems to me like we came far enough that we can sacrifice some of the extreme performance of C for some safety.

But one thing that I still have not seen is a good selection of graphics libraries, and that is something that I’m fairly disappointed by. Indeed, I have been told that there are Rust bindings for the classic C graphics libraries — which is pointless, as then the part that needs safety (the parsing) is still performed in C!

The reason why I’m angry about this is that I still have one project, unpaper, which I inherited as a big chunk of C and could definitely be rewritten into a safer language. But I would rather not do so in a higher level language like Python due to the already slow floating point calculations and huge memory usage.

Right now, unpaper is using libav, or ffmpeg, or something with their interface, depending on how much they fought this year. This is painful, but given that each graphic library implements interfaces in different ways, I couldn’t find a better and safe way to implement graphics processing. I was hoping that with all the focus on Rust out there, particularly from Mozilla, implementing graphics parsing libraries would be high in the list of priorities.

I think it’s librsvg that was ported to Rust — which was probably a great idea to prioritize, given it is exactly the type of format where C performs very poorly: string parsing. But I’m surprised nobody tried to make an API-compatible libpng or libtiff. It sounds to me like Rust is the perfect language for this type of work.

At any rate, if anyone finally decides to implement a generic graphic file input/output library, with at least support for TIFF, PNM and PNG, I’d love to know. And after that I would be happy to port unpaper to it — or if someone wants to take unpaper code as the basis to reimplement it as a proof of concept, that’d be awesome.

The problem for a lot of these libraries is that you have to maintain support for a long list of quirks and extensions that over time piled up on the formats. And while you can easily write tests to maintain bit-wise compatibility with the “original” C language based libraries for what concerns bitmap rendering (even for non-bitmap graphics such as JPEG and WebP), there are more things that are not obvious to implement, such as colour profiles, and metadata in general.

Actually, I think that there is a lot of space here to build up a standard set of libraries for graphics libraries and metadata, since there’s at least some overlapping between these, and having a bigger group of people working on separate, but API-similar libraries for various graphic formats would be a significant advantage for Rust over other languages.

Inconsistent Scalable Vector Graphics

The one job I’m taking care of at the moment involves me drawing some stuff using SVG in C code, without using any support libraries. Without going into much detail, since I cannot because of an NDA, I can say the generated file has to be as small as possible since, as you might guess by now, it has to be done on an embedded system.

The task itself is not too difficult, but today I started the actual reduction of the code so that it fits in the software the I have to develop, and here starts the problems. The first issue has been I was tired of looking up the correct attributes for each SVG element, so I ended up doing the same I did for DocBook 5 and added a new ebuild to portage: app-emacs/nxml-svg-schemas:1.1 which installs the SVG 1.1 schemas so that Emacs’s nxml-mode can tab-complete the elements and attributes. I positively love Emacs and nXML since it allows me to have specific XML variants support by just adding its schemas to the system!

A little note now about nXML though: I’ll have to contact upstream because I found one nasty limitation of it: I cannot make it locate the correct shemas on a version basis, which means I won’t be able to provide SVG 1.2 schemas alongside as 1.1 with the code as it is; if I can get a new locating rules schemas that can detect the correct schema to use also through version, that’s going to solve not only SVG 1.2 but also future DocBook versions. So this enters my TODO list. Also, am I the only one using nXML in Gentoo? I’m maintaining all the three schemas ebuilds, it’s not like it’s a big hassle, but I wonder what would happen if I were to leave Gentoo — or more likely at this point if I were to end up in the hospital again; I hope I’m fine now but one is never sure, and my mindset is pretty pessimistic nowadays.

At any rate, I’ve been studying the SVG specifications to find a way to reduce the useless data in the generated file, without burdening the software with doing manual calculations. The easy way out is to use path and polyline elements to draw most of the lines in the file, which would be fine if it wasn’t they only accept coordinates in “pixels” (which are not actual pixel, but just the basic unit for the SVG file itself). This is not too bad since you can define a new viewport which can have an arbitrary size in “pixels”, and is stretched over the area. The problem is with supporting the extra viewports.

The target of the file to generate is to work on as many systems as possible, but it’s a requirement that it works on Windows with Internet Explorer, as well as Firefox. For SVG files under Internet Explorer there is the old, unmaintained and deprecated Adobe SVG plugin (which is still the default Internet Explorer will try to install) and the examotion Renesis Player which is still maintained. So I take out my test file, and try it.

I wrote the file testing it with eog which I’m not sure which SVG library uses for the rendering and with rsvg that uses librsvg obviously; with those, my test file was perfect, the problem has been with other software, since I got the following results:

Inkscape wouldn’t load it properly at all and just draw crazy stuff;
batik 1.6 worked;
Firefox, Safari and Opera shown me grey and red rectangles rather than the actual lines I wrote in the SVG;
Renesis Player shown me lines, but way too thick for what I wanted;
OpenOffice shown it with the right dimensions but didn’t translate it 2×2 cm down from the upper left corner like I instructed the svg to.

After reporting the issue on examotion’s tracker, since that is the most important failure in that list for my current requirements, I got a suggestion of switching the definition of font-size to direct attribute rather than through style so to change the actual svg measure unit. This made no difference for the three implementations that worked before, nor on examotion, but actually got me one step closer to the wished result:

inkscape still has problems, the white rectangle I draw to get a solid white background is positioned over the rest of the elements, rather than under like I’d expect since it’s the first element in the file; it also does not extend the grid like it should, so the viewBox attribute is not properly handled;
OpenOffice still has the problem with translation but for the rest seems fine;
Safari still has the same problems;
Opera 9.6 on Windows finally renders it perfectly, but fails under Ubuntu (?!);
Firefox official builds for Windows and OSX, as well as under Ubuntu, work fine; under Gentoo, it does not, and still show the rectangles;
Adobe SVG plugin work fine.

At this point I should have enough working implementations so that I can proceed with my job task, but this actually made me think about the whole thing about SVG, and it reminded me tremendously of the OASIS OpenDocument smoke which I had a fight with more than three yeas ago. I like very much XML-based technologies for sake of interoperation, but it’d be nice if the implementations actually had a way to produce a proper result.

Like in OpenDocument, where the specifications allow two different styles for lists, and different software implements just one of them, making themselves incompatible one with the other, SVG defines some particular features that are not really understood or used by some implementations, or can create compatibility issues between implementations.

In this case, it seems like my problem is the way I use SVG subdocuments to establish new viewports, and then use the viewBox feature to change their unit space. This is perfectly acceptable and well described by the specifics, but it seems to cause further issues down the line with the measure units inside and outside these subdocuments. But it seems like the problem is not just one-way, from this other bugreport on Inkscape you can also see that Inkscape does not generate so pure SVG as it should.

While XML has been properly designed to be extensible, thanks to things like namespaces and similar, one would expect that the feature provided by a given format would be used before creating your own extensions; in this case from that bug report you can see (and I indeed double checked that it still is the case) that Inkscape does not use SVG’s own features to establish a correspondence between “SVG pixels” and the size in real-world units of the image; indeed, it adds two new attributes to the main document: inkscape:export-xdpi and inkscape:export-ydpi, while SVG expects you to use the viewBox for providing that information.

Sigh, I just wished to get my graph working.

Update: for those who tried to leave comment on the post: I’m sorry I misconfigured apache and the comments weren’t recorded :/ Hopefully it’s fixed now.

Cleaning up xine-ui

So, I wanted to provide to my Gentoo users a new version of xine-ui with a few corrections, especially since I was able to turn off -fno-strict-aliasing applied to the whole code, and there are a few bugs that I couldn’t reproduce that might be fixed now, as I’ve tried to fix a few border line cases that were throwing warnings.

Unfortunately, when I gone looking for packaging xine-ui, I’ve seen that its configure.ac was really a good mess of stuff. For that reason, I’ve now updated all of it, making it human readable, consistent and possibly faster.

Basically what I ended up doing was to update switches to use AS_HELP_STRING for the help strings outputted on ./configure —help, so that it does not look like crap on autoconf 2.60, and to replace custom checks when possible with standard ones. Three test were moved from the previous custom ones to pkg-config checks. That is a good thing coming out of gnome at least ;) The tests were for libpng, xine-lib and curl, the new code looks way better.

I also dropped the support for libtool, as xine-ui does not install any shared library, so it made no sense to use it. The result is quite good as the code reduction in the generated configure file is notable; from 1.1MiB to less than 500KiB. This is not bad at all.
Also when removing libtool I found that the console utilities ended up linking against X11 when configured to build X11 ui too. This is now fixed in CVS.

Unfortunately there seems to be a few more things that does not work as intended in the current autotools code, so I’m working on clean that up, too. If all goes well, a snapshot will be in tree by night and it will take way less time to build :)

If I end up correctly preparing this stuff, I’ll try soon also to clean up the configure.ac for xine-lib, to make it faster, too, but that is going to take quite some time as a lot of that stuff cannot be easily changed as it has quite complex dependencies.

On a different note, today I received the replacement of the DVD from Amazon (and yesterday I sent out the one I received), this time it was sealed, latched and perfectly working :) Yai! :)

And a final note, I’ve decided to buy the 9250 card, so that I can use the radeon driver, and get rid of the binary nVidia driver. I’ll consider it an investment.

Waiting … and waiting ….

No, I’m not waiting for a call from a beautiful girl.. mainly because she won’t call me ever anyway. I’m waiting for two, or three, releases.

The first release is Amarok 1.4.1 (beta1) that should be the first test version of thew new version of Amarok, and I have to see if Gentoo is ready for it, after the lot of changes happened. The main thing that scares me is inotify support, as newer linux-headers aren’t present on ~x86 (nor on ~ppc fwiw). Should be fine in ~amd64 tho. If I was quick enough, the strict-aliasing fix will be present on that version, too :)

The second release is Dejavu Fonts that was due today. I want to see what they added, I’m always interested in new glyphs, also if I just use a little subset of them, because I think being able to see the text written in different encodings is important, especially for Free Software.

The third release is a bit of waiting, a bit of “I’d rather not see it coming” of Linux 2.6.17, as that it seems to have broken alsa-driver again, and I found no fix on upstream’s HG repos.

Now, of course I could have better things to do Sunday afternoon. I could be playing, I could be trying to find a way to see someone, I could be doing wood carving… but the only thing I’m able to do is to wait here for the new release, and in the mean time trying to fix a few things. Sigh. I would so much like to have a real life :P

On a different note, thanks to Stuart in the graphics driver post’s comments, I’m now more oriented on a R200-based ATI card to get out of the binary drivers enslavement, as of that I can tell it works fine (some people told me radeon 7000 can have some quirks with video playing, and the amount of on-board memory scared, me a bit, 32MB aren’t much for videos). I found something that seems to be appropriate, and that I wouldn’t even categorise as “downgrade for freedom”, a radeon 9200 with 256MB of memory, that would be good for video playing with xv, but it’s not that cheap, about €50, almost the double of the other one, but probably comparing the prices this has an higher quality/price ratio. I still have to hear from anyone about the compatibility with xinerama, that is another of my major concerns. If someone uses that card with two monitors, please tell me how the support is :)

Depending of what other jobs I’m going to take next, I would be very very happy to spend that money to be more free than before.

My thoughts on graphics drivers

In the last days there was a bit of discussion about the closed-source nVidia and ATI drivers, mainly because of xorg 7.1 and the ABI breakage.
I think it might be interesting to write something up about how I feel about this.

I do feel I have to use as much free software as I can. I trust free software, I love free software. But, I do have some needs that I have to trade with my freedom to be able to continue my work on other aspects of free software.

In my main box, which is what I work on the 90% of the time, I have a nVidia card that runs the nvidia binary driver. I work on multimedia programs, so I really need xv overlays working, thing that is not available on nv driver.

I work on two monitors since a few months now, and that increased my productivity, as I can watch a movie and still have enough screen real estate to work on something else. I need a working xinerama for that, this card provides me a working TwinView with DVI and VGA output.

Now, I’m not a gamer, so I care nothing about 3D performances, the most of 3D I used on this box is with Stellarium, that and Google Earth the other day just to see how it was. I used to play Unreal Tournament back in the days, but I’m done with that since long time.

Chutzpah suggested me an ATI 7000 card, AGP with dual output (DVI and VGA), that should use a driver good enough to provide me the two things I’m looking for, and it’s also quite cheap (about €32), that is a good thing especially since I don’t find it a priority myself to get out of the nvidia driver binding.

Now, if somebody has that card, and can tell me whether xinerama works, and if the xv overlays are fine performance-wise, I’d be really grateful. A simple test for the xv overlays is to play something in xine or mplayer (I personally use Kaffeine), then open a terminal and try to cat a long long file (like Xorg.*.log). If the image on the player window stops while the cat is going on, then xv overlays aren’t working as they should.

I would really like to be able to use an opensource driver with a fine 2d graphics card, but up until that, I have to trade part of my freedom to be able to work on other stuff, especially since I’m not paid to do this at all, and I’m still on contract jobs, so even if I have some money saved, I try to avoid spending it on things that are not in my priority list, and I’m not keen on spending them on this unless I can be sure that xv and xinerama works properly as I need them to.