Hello Everyone,
I want to discuss one issue with the new font dropdown. I've already begun work on it and it can be seen in action in these 2 videos:
http://futurepast.free.fr/out.ogv http://futurepast.free.fr/preview-text-update.ogv
It uses threading for generating the preview as not to stall the UI/main application while scrolling, or take too long to startup when generating all the previews at startup of the application.
My architecture for this is very pluggable, I defined interfaces for all the classes used and wrote a few sample implementations which you can see at work in those 2 videos. Now I've run into a problem: For the class that generates the actual thumbnails I've initially chosen Pango to render them. Now it seems that Pango is not thread-safe and I wrote another implementation using just cairo which seems to work fine so far.
The issues is that with cairo, we don't get proper thumbnails for some fonts, or some scripts. Pango handles this on a higher level and much better. Bulia mentioned to me that tradeoffs might be possible, but I am not sure at which point to make these. I'm not an export on cairo or freetype2 to make this particular backend work properly with all fonts and all scripts/glyphs.
Then, there is always the third option of not using threading, but I'd prefer to keep it since it works really well and is an ideal solution for the problem of time-consuming rendering of previews of complex fonts. Please don't worry about "threading" itself, I'm using libsigx in accordance with Bulia, which can be found here: http://www.assembla.com/wiki/show/sigx and is a threading library based on libsigc++ and makes thread programming *very* safe.
The question now is:
- Keep the cairo-only backend with the tradeoff that we can not render everything properly - Try awkward things with Pango like dlopening() a 2nd ("private") instance of libpango and use this solely for generation of the previews - Drop threading(?) - Does anyone have a 4th solution?
To those interested: The details in the problems with Pango lie in that some structures inside libpango are not properly locked or protected, and race conditions occur when simply running the thumbnail generation in a thread with the same libpango instance, and merely simply rendering the application's UI with Gtk+ which uses Pango for text widgets and/or rendering canvas text since layout-TNG uses Pango as well from what I've seen in the code so far.
Any suggestions regarding this problem are appreciated.
Regards, M.