Hi Igor, > >> It first glance it seems that the only way to get into freetypeScaler.c > >> is through synchronized methods and > >> env variable gets overridden every time. So, it seems that it should > >> match current thread always. > >> I am interested to understand what i am missing here. > >> > > > > I think what could happen here is that FreeType doesn't read the whole > > font file in one go during initialization, but instead reads the glyphs > > on demand when actually scaling. It's possible that this is triggered > > from a different thread than the one used during initialization. I don't > > know about Hotspot, but I know that some VMs simply don't care (so much > > as others) about what JNIEnv* they use when calling a JNI function. > > > Well, I would expect that any read requests are triggered by request to > freetype glue layer to retrieve glyph image or > glyph metrics. And any call to glue layer should reset JNIEnv field > (explicitly or by calling setupFTContext()). > Theoretically, this should guarantee that JNIEnv is matching current > thread unless > there are other code changes that break one of these assumptions.
I see. You are probably right. But: I found at least one call into Freetype that does not setup the env correctly, that is in getGlyphCodeNative(). I don't know if this is supposed to read from the font file, but we probably cannot guarantee that it doesn't. /Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-48 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Geschäftsführer: Dr. James J. Hunt
