So my understanding is that FreeType is not thread safe, so to overcome this we
can just mutex off any SkFontHost functions that call into FT_* functions
directly. The way I've done this is to just wrap FT_Reference_Face and
FT_Done_Face with static inline functions that acquire the mutex then call into
FT_*.
Ben, could you also take a look at this. Things that come to mind:
1. can we (should we) share FT_Face instances across the library boundary?
2. are there threading concerns with #1?
3. are there RAM or other resource concerns with tying an FT_Face instance with
every live SkTypeface? (in the current impl, they are related only via an
associated cache)
4. are there chrome-specific constraints (e.g. sandbox, process boundaries) that
should be noted when looking at this CL?
The first issue which stands out to me is the cross library FT_Face. The GDI ...
11 years, 11 months ago
(2012-04-10 19:32:00 UTC)
#4
The first issue which stands out to me is the cross library FT_Face. The GDI and
CoreText FontHosts currently do something like what is proposed here (though I
would very much like to do away with them). These are acceptable since LOGFONT
is just a descriptor, and CTFontRefs come from the system and will work with any
system calls we need to make. In this case we have two different FT_Librarys,
the one which created the font and the one used to access the font. This is a
rather bad idea. Either the SkFaceRec needs to know the FT_Library as well, or
the SkScalarContext needs to be created with the correct FT_Library, at the very
least.
FreeType would need the font data loaded in process space anyway. Whatever
process is used to locate the font to be used can simply create an SkStream from
the known font data and use that to create an SkTypeface instead of creating a
FT_Face. This is actually exactly what SkFontHost_linux.cpp does, as
SkFontHost_FreeType.cpp does not actually know itself how to find any fonts.
Basically, I believe what you really want is a local port of
SkFontHost_linux.cpp.
For an example of how the above can be done with fontconfig, see Chrome souce ...
11 years, 11 months ago
(2012-04-10 19:48:39 UTC)
#5
For an example of how the above can be done with fontconfig, see Chrome souce at
/src/skia/ext in files SkFontHost_fontconfig.cpp and
SkFontHost_fontconfig_direct.cpp .
On 2012/04/10 19:32:00, bungeman wrote: > The first issue which stands out to me is ...
11 years, 10 months ago
(2012-05-08 20:29:33 UTC)
#6
On 2012/04/10 19:32:00, bungeman wrote:
> The first issue which stands out to me is the cross library FT_Face. The GDI
and
> CoreText FontHosts currently do something like what is proposed here (though I
> would very much like to do away with them). These are acceptable since LOGFONT
> is just a descriptor, and CTFontRefs come from the system and will work with
any
> system calls we need to make. In this case we have two different FT_Librarys,
> the one which created the font and the one used to access the font. This is a
> rather bad idea. Either the SkFaceRec needs to know the FT_Library as well, or
> the SkScalarContext needs to be created with the correct FT_Library, at the
very
> least.
The FT_Face itself has a reference to the FT_Library that created it in the
glyph slot. Is there a reason why it would be a bad idea to instead of using
gFTLibrary, to use face->glyph->library?
> FreeType would need the font data loaded in process space anyway. Whatever
> process is used to locate the font to be used can simply create an SkStream
from
> the known font data and use that to create an SkTypeface instead of creating a
> FT_Face. This is actually exactly what SkFontHost_linux.cpp does, as
> SkFontHost_FreeType.cpp does not actually know itself how to find any fonts.
We can do this, however it doesn't map too well to our internal gfx APIs, which
wrap an underlying font object for the platform we're dealing with with no
obvious way to get the memory data backing the font object. We do all our own
font selection so SkFontHost_FreeType not knowing how to find any fonts is ideal
for us (we do all our own selection via FontConfig before it gets to Skia).
On 2012/05/08 20:29:33, gwright wrote: > On 2012/04/10 19:32:00, bungeman wrote: > > The first ...
11 years, 10 months ago
(2012-05-14 21:37:49 UTC)
#7
On 2012/05/08 20:29:33, gwright wrote:
> On 2012/04/10 19:32:00, bungeman wrote:
> > The first issue which stands out to me is the cross library FT_Face. The GDI
> and
> > CoreText FontHosts currently do something like what is proposed here (though
I
> > would very much like to do away with them). These are acceptable since
LOGFONT
> > is just a descriptor, and CTFontRefs come from the system and will work with
> any
> > system calls we need to make. In this case we have two different
FT_Librarys,
> > the one which created the font and the one used to access the font. This is
a
> > rather bad idea. Either the SkFaceRec needs to know the FT_Library as well,
or
> > the SkScalarContext needs to be created with the correct FT_Library, at the
> very
> > least.
>
> The FT_Face itself has a reference to the FT_Library that created it in the
> glyph slot. Is there a reason why it would be a bad idea to instead of using
> gFTLibrary, to use face->glyph->library?
>
> > FreeType would need the font data loaded in process space anyway. Whatever
> > process is used to locate the font to be used can simply create an SkStream
> from
> > the known font data and use that to create an SkTypeface instead of creating
a
> > FT_Face. This is actually exactly what SkFontHost_linux.cpp does, as
> > SkFontHost_FreeType.cpp does not actually know itself how to find any fonts.
>
> We can do this, however it doesn't map too well to our internal gfx APIs,
which
> wrap an underlying font object for the platform we're dealing with with no
> obvious way to get the memory data backing the font object. We do all our own
> font selection so SkFontHost_FreeType not knowing how to find any fonts is
ideal
> for us (we do all our own selection via FontConfig before it gets to Skia).
What I described seems to map rather well to the existing internal gfx APIs.
What I am proposing is simply treating Skia as the platform and passing around
SkTypeface as the platform font (because that's how it was written to be used).
Whether Skia happens to use FreeType under the hood or not should be immaterial.
On 2012/05/14 21:37:49, bungeman wrote: > > We can do this, however it doesn't map ...
11 years, 10 months ago
(2012-05-14 21:45:21 UTC)
#8
On 2012/05/14 21:37:49, bungeman wrote:
> > We can do this, however it doesn't map too well to our internal gfx APIs,
> which
> > wrap an underlying font object for the platform we're dealing with with no
> > obvious way to get the memory data backing the font object. We do all our
own
> > font selection so SkFontHost_FreeType not knowing how to find any fonts is
> ideal
> > for us (we do all our own selection via FontConfig before it gets to Skia).
>
> What I described seems to map rather well to the existing internal gfx APIs.
> What I am proposing is simply treating Skia as the platform and passing around
> SkTypeface as the platform font (because that's how it was written to be
used).
> Whether Skia happens to use FreeType under the hood or not should be
immaterial.
Well the issue we have is that then we'd have an internal implementation of
gfxFont (this is in Gecko) that would be Skia specific, whereas ideally we'd
like to be able to share our font code between backends on the same platform.
i.e. - on Linux we use gfxFontFreeType, on Windows we use gfxFontWindows, etc. I
guess what I'm really after is to be able to have an API in Skia that's
analogous to Cairo's cairo_ft_font_face_create_for_ft_face().
Whilst we could conceivably create a new set of gfxFont classes which speak
Skia/SkTypeface internally, it seems to make more sense for us to implement it
in terms of the lowest common denominator between our backends, which is
Freetype.
Issue 5846051: Modify SkFontHost_FreeType to allow for a client to control the FT_Face object
(Closed)
Created 12 years ago by gw280
Modified 11 years, 8 months ago
Reviewers: reed1, bungeman
Base URL: http://skia.googlecode.com/svn/trunk/
Comments: 0