Re: Memory leak

[Kenichi Handa]

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