Hello Everyone,<br><br>I want to discuss one issue with the new font dropdown. I&#39;ve already begun work on it and it can be seen in action in these 2 videos:<br><br><a href="http://futurepast.free.fr/out.ogv">http://futurepast.free.fr/out.ogv</a><br>
<a href="http://futurepast.free.fr/preview-text-update.ogv">http://futurepast.free.fr/preview-text-update.ogv</a><br><br>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<br>
at startup of the application.<br><br>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<br>2 videos.&nbsp; Now I&#39;ve run into a problem: For the class that generates the actual thumbnails I&#39;ve initially chosen Pango to render them. Now it seems that Pango is not<br>
thread-safe and I wrote another implementation using just cairo which seems to work fine so far.<br><br>The issues is that with cairo, we don&#39;t get proper thumbnails for some fonts, or some scripts. Pango handles this on a higher level and much better. Bulia mentioned to<br>
me that tradeoffs might be possible, but I am not sure at which point to make these. I&#39;m not an export on cairo or freetype2 to make this particular backend work properly<br>with all fonts and all scripts/glyphs.<br><br>
Then, there is always the third option of not using threading, but I&#39;d prefer to keep it since it works really well and is an ideal solution for the problem of time-consuming rendering<br>of previews of complex fonts. Please don&#39;t worry about &quot;threading&quot; itself, I&#39;m using libsigx in accordance with Bulia, which can be found here: <a href="http://www.assembla.com/wiki/show/sigx">http://www.assembla.com/wiki/show/sigx</a><br>
and is a threading library based on libsigc++ and makes thread programming *very* safe.<br><br>The question now is:<br><br>- Keep the cairo-only backend with the tradeoff that we can not render everything properly<br>- Try awkward things with Pango like dlopening() a 2nd (&quot;private&quot;) instance of libpango and use this solely for generation of the previews<br>
- Drop threading(?)<br>- Does anyone have a 4th solution?<br><br>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<br>
running the thumbnail generation in a thread with the same libpango instance, and merely simply rendering the application&#39;s UI with Gtk+ which uses Pango for text widgets and/or<br>rendering canvas text since layout-TNG uses Pango as well from what I&#39;ve seen in the code so far.<br>
<br>Any suggestions regarding this problem are appreciated.<br><br>Regards,<br>M.<br clear="all"><br>-- <br>Please note that according to the German law on data retention,<br>information on every electronic information exchange with me is<br>
retained for a period of six months.<br>[Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge<br>jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.]<br>