Hi,
Suggested changes seems reasonable.
However, i failed to invent testcase to reproduce this issue.
Could you please describe what google test is doing in regard to the
font code?
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.
-igor
