In article <address@hidden>, Jason Rumney <address@hidden> writes:
> If the leak is coming from the font cache, then I wouldn't expect it to
> be released when the frame is deleted, as the font cache is shared
> between all frames on w32 (and I think between all frames on the same
> display on X). Stefan is seeing 10x the increase as you are on Windows,
> which could be explained by xft loading fonts into Emacs's process
> space, while on Windows the font itself stays in system owned memory,
> and only Emacs's internal info that it associates with the font
> contributes to the growth. That also points to fonts being responsible
> (though circumstantial).
I've just installed a fix in font-cache handling. Now, even
when I create many new frames, the memory usage doesn't
increase that much. Though it still increases several
handreds K-bytes each time a new frame is created, and it is
not reduced when I delete the frames. So, I think there
still be a problem somewhere.
FYI, when I compile Emacs without gtk, the amount of
(non-freed) memory increase becomes smaller.
> There is another similar problem when we get text extents - each redraw
> cycle can call w32font_text_extents a number of times for the same
> glyph_string (from compute_glyph_string_overhangs, left_overwriting and
> right_overwriting in quick succession in draw_glyphs, with nested
> compute_overhangs_and_x within some of the if statements that cause
> extra calls for preceding and following glyph_strings if there is
> overhang, which there often is with antialising enabled). Perhaps this
> operation is cheap with the X font backends, but on Windows it is
> expensive (even with caching of metrics), and I suspect this is a major
> cause of the slowdown reported by Windows users.
I remember that I modified x_draw_glyph_string for such a
font-backend as xft that can't do foreground-only drawing
because of antialiasing, which increases the count of
overhang-checking. Perhaps we should study the code of
draw_glyphs and x_draw_glyph_string and find a solution.
---
Kenichi Handa
address@hidden