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.
For those who want to try out the widget, i've uplodaded the code here:
http://futurepast.free.fr/CODE/Inkscape/22022009/preview-stuff.tar.gz
It will extract into a directory preview-stuff/, and you need gtkmm-2.4 and sigx installed for it to compile. There is no autotooled buildsystem, just a simple makefile. Just have gtkmm and sigx installed and run make. Then run ./previews and voila.
Regards, M.
On Sun, Feb 22, 2009 at 10:41 PM, Milosz Derezynski <internalerror@...400...
wrote:
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.
-- Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.]
One more thing:
There is a possible solution using Pango. I determined that the crash specifically happens when calling pango_layout_get_pixel_extents(). We could theoretically place a global lock in the entire application on calling this function. It should be regarded as a possibility IMO, until Pango has been made threadsafe. Please comments on this too. Thanks.
Regards, M.
On Sun, Feb 22, 2009 at 10:48 PM, Milosz Derezynski <internalerror@...400...
wrote:
For those who want to try out the widget, i've uplodaded the code here:
http://futurepast.free.fr/CODE/Inkscape/22022009/preview-stuff.tar.gz
It will extract into a directory preview-stuff/, and you need gtkmm-2.4 and sigx installed for it to compile. There is no autotooled buildsystem, just a simple makefile. Just have gtkmm and sigx installed and run make. Then run ./previews and voila.
Regards, M.
On Sun, Feb 22, 2009 at 10:41 PM, Milosz Derezynski < internalerror@...400...> wrote:
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.
-- Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.]
-- Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.]
NVM I forgot that Gtk+ itself calls this function numerous times in its code... :|
On Sun, Feb 22, 2009 at 10:51 PM, Milosz Derezynski <internalerror@...400...
wrote:
One more thing:
There is a possible solution using Pango. I determined that the crash specifically happens when calling pango_layout_get_pixel_extents(). We could theoretically place a global lock in the entire application on calling this function. It should be regarded as a possibility IMO, until Pango has been made threadsafe. Please comments on this too. Thanks.
Regards, M.
On Sun, Feb 22, 2009 at 10:48 PM, Milosz Derezynski < internalerror@...400...> wrote:
For those who want to try out the widget, i've uplodaded the code here:
http://futurepast.free.fr/CODE/Inkscape/22022009/preview-stuff.tar.gz
It will extract into a directory preview-stuff/, and you need gtkmm-2.4 and sigx installed for it to compile. There is no autotooled buildsystem, just a simple makefile. Just have gtkmm and sigx installed and run make. Then run ./previews and voila.
Regards, M.
On Sun, Feb 22, 2009 at 10:41 PM, Milosz Derezynski < internalerror@...400...> wrote:
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.
-- Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.]
-- Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.]
-- Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.]
participants (1)
-
Milosz Derezynski