Thanks Nicolas. You know that I appreciate your work. I would appreciate that Eliot does not send me personal emails to tell that I’m a bad leader :) but at least this is coherent with the violent emails I received in the past - nothing new under the sun. Just anger against me. I cannot do much.
I imagine that I cannot avoid the send so I will block the reception :). > On Apr 10, 2019, at 7:08 AM, ducasse <steph...@netcourrier.com > <mailto:steph...@netcourrier.com>> wrote: > > Thank you P and G. > It is so annoying. Why can you not include Nicolas Cellier in your thanks? He provided pertinent information. That you only ever thank members of the Pharo team I find annoying. It is bad leadership. > On 10 Apr 2019, at 15:49, Nicolas Cellier > <nicolas.cellier.aka.n...@gmail.com> wrote: > > Good find! > The fac tthat FT_Face is not thread-safe is documented > https://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html > <https://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html> > > Le mer. 10 avr. 2019 à 15:39, teso...@gmail.com <mailto:teso...@gmail.com> > <teso...@gmail.com <mailto:teso...@gmail.com>> a écrit : > Hello, > > After checking the problem with Guille, we have the hypothesis of the > source of the problem. > We have seen that accessing Free Type is not thread-safe. > Basically, the FTFace holds a structure that is filled up with the > glyph and its information. As this structure is part of the Font Face > (a font face is a font plus size and attributes), only one request to > a glyph can be executed at the time. As we are sharing the same font > in many places, you will be starting to see the problem. > > Also, we have seen that there many accesses to the glyphs outside the > UI process. > This problem started to appear as we starting to use Calypso (but it > is not limited to it), as Calypso uses lazy tabs. The creation of > these tabs is done outside the UI process. > > This is only a hack to test our hypothesis. > To fix it correctly we will have to rewrite the drawing of the glyphs > and synchronize the access to the glyph data information. Also, we > want to do it in a way that does not penalize the processing in the UI > process. > > I have only patched the code that is used by the rendering of morphic, > other renderings like Athens or any other user using FT should be > correctly rewritten. > > Once we are sure that synchronizing the access to FT fixes the > problem, we will do a real fix not a dirty hack like this. > > I will be testing this new Image to see if there is an improvement. > > I will really love you try to use this image and tell me if you still > find the problem. > > There is a PR generating a Pharo8 image (it is called wrong, but... it > is a Pharo8) > > 32 bits > ===== > > https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/PR-3157/2/artifact/bootstrap-cache/Pharo7.0-PR-32bit-f8c6957.zip > > <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/PR-3157/2/artifact/bootstrap-cache/Pharo7.0-PR-32bit-f8c6957.zip> > > 64 bits > ===== > > https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/PR-3157/2/artifact/bootstrap-cache/Pharo7.0-PR-64bit-f8c6957.zip > > <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/PR-3157/2/artifact/bootstrap-cache/Pharo7.0-PR-64bit-f8c6957.zip> > > If somebody is willing to use it in Pharo 7, I can create a PR against > Pharo7 to generate patched P7 images. > > Thanks! > > -- > Pablo Tesone. > teso...@gmail.com <mailto:teso...@gmail.com> >
