Bug 58391 – Embedded font resources never get released when page is closed

• Status: UNCONFIRMED
• Component: WebKitGTK

[Hao]

This should happen on all WebKit ports which using CAIRO as rendering engine.
I observed both latest WebKitGTK+ and Google Chrome Official release on Linux.

How to reproduce:
Open browser, load a page with embedded font, (e.g. the simple test page attached),
refresh the page many times, observing the memory usage of the process.

e.g. For Google Chrome on Linux, loading the attached page, then about 20~30M of memory will be used. But if refreshing the page many times, you can easily see the memory usage will rock climbing.


Why it happens like that?
http://trac.webkit.org/browser/trunk/Source/WebCore/platform/graphics/freetype/FontCustomPlatformDataFreeType.cpp
The intention here to set destroy function to both [buffer] & [freeTypeFace] by using cairo_font_face_set_user_data() are great.
But they never get called even when the page is closed.

From my understanding, to render the embedded font:

(1) [SharedBuffer] contains the embedded font data

(2) based on [SharedBuffer], a Freetype Face is created [FT_Face] by FT_New_Memory_Face()

(3) based on [freeTypeFace], a [cairo_font_face_t] is created by cairo_ft_font_face_create_for_ft_face()

(4) based on the [cairo_font_face_t], a [cairo_scaled_font_t] is created by cairo_scaled_font_create() in FontPlatformDataFreeType.cpp, cairo_scaled_font_create() also add a ref count on [cairo_font_face_t]

(5) The [cairo_scaled_font_t] is the actually font object that will be used for rendering

Ideally, since the release should happen like:
(a) [cairo_scaled_font_t] should be released by cairo_scaled_font_destroy() in it's deconstructor, which will also decrease the ref count of [cairo_font_face_t]
(b) [cairo_font_face_t] should be released by cairo_font_face_destroy() in it's deconstructor while (a) is done
(c) [FT_Face] and [SharedBuffer] should both get release when (b) is done, since they are registered by cairo_font_face_set_user_data()

BUT, since CAIRO choose to do cache internally, right after cairo_scaled_font_create() is called, the reference count of [cairo_font_face_t] will be 2. And due to that, nothing will get released since they reference count won't be 0.


I personally don't have a good solution since I don't want to change anything inside Cairo library. To provide myself a workaround, I just remember all the [SharedBuffer] and [FT_Face] that get created for a particular URI, and when the URI changes to another one, I'll release those 2 anyway.

Please help to see if there is any better solution. Thanks a lot.

[Martin Robinson]

Are you sure you're seeing this on Chrome as well. I only ask because Chrome does not use the Cairo backend at all.

[Hao]

Yes, I'm pretty sure this happens on Google Chrome Linux. I verified the behavior many times.

My understanding is Google Chrome on Linux use the same stack of WebKitGTK+,
at least, I know they are using GTK+, and I think GTK+ use CAIRO.

[Martin Robinson]

(In reply to comment #2)
> Yes, I'm pretty sure this happens on Google Chrome Linux. I verified the behavior many times.
> My understanding is Google Chrome on Linux use the same stack of WebKitGTK+,
> at least, I know they are using GTK+, and I think GTK+ use CAIRO.

The Chrome browser UI does use GTK+, but the things inside the WebView are rendered via Skia. :)

[Hao]

(In reply to comment #3)
> (In reply to comment #2)
> > Yes, I'm pretty sure this happens on Google Chrome Linux. I verified the behavior many times.
> > My understanding is Google Chrome on Linux use the same stack of WebKitGTK+,
> > at least, I know they are using GTK+, and I think GTK+ use CAIRO.
> 
> The Chrome browser UI does use GTK+, but the things inside the WebView are rendered via Skia. :)

I see. But I'm pretty sure I can reproduce the issue.

[Carlos Garcia Campos]

Yes, this is expected, but undesirable. It's a known issue, cairo keeps the font cached and the user data callback is never called, because the font is not destroyed. Adding a cairo_font_face_finish() function similar to other cairo APIs would solve the problem, See this cairo bug:

https://bugs.freedesktop.org/show_bug.cgi?id=28145

[Hao]

(In reply to comment #5)
> Yes, this is expected, but undesirable. It's a known issue, cairo keeps the font cached and the user data callback is never called, because the font is not destroyed. Adding a cairo_font_face_finish() function similar to other cairo APIs would solve the problem, See this cairo bug:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=28145

I agree this should be the similar issue. But the question is whether CAIRO would like to provide an extra API or not? If yes, then when?  If not, what else can we do on the WebKit side as a work around. Thanks a lot.

[Carlos Garcia Campos]

(In reply to comment #6)
> (In reply to comment #5)
> > Yes, this is expected, but undesirable. It's a known issue, cairo keeps the font cached and the user data callback is never called, because the font is not destroyed. Adding a cairo_font_face_finish() function similar to other cairo APIs would solve the problem, See this cairo bug:
> > 
> > https://bugs.freedesktop.org/show_bug.cgi?id=28145
> 
> I agree this should be the similar issue. But the question is whether CAIRO would like to provide an extra API or not?

Yes, that bug was marked as blocker for cairo 1.10, indeed.

> If yes, then when? 

when someone proposes a patch. 

> If not, what else can we do on the WebKit side as a work around. Thanks a lot.

I don't know any workaround :-(