Memory after third opening 280 MB expected 130 MB
Steps to Reproduce:
1. Open attachment 97742 [details] (bug 77519)
3. Repeat 3x and look at memory usage for start center at the third time
User Profile Reset: No
Version: 184.108.40.206.alpha0+ (x64)
Build ID: a35c18aeff3b1d8f270db7e094850fb8ba1ab84a
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Version: 220.127.116.11.beta1+ (x64)
Build ID: 20be5cd0bdc57d812bf34a2debfe48caa51de881
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win;
Locale: nl-NL (nl_NL); UI-Language: en-US
I hope I'm repeating myself: weldfontbox.. bug 132536
I tried to reproduce on Windows 10 and debian with 7.0 beta 1 and could not reproduce.
- Could already been corrected (please check).
- Be more specific about your system.
- (note: I'm not a pro)
I repro, but why open this when bug 132536 still does not have a solution?
(In reply to Buovjaga from comment #2)
> I repro, but why open this when bug 132536 still does not have a solution?
Because I'm using the bugtracker as reminder to look at it some time; I probably forget it.. at some point. And because I'm getting slightly impatient..
* While testing bug I end up with 1/2 GB ram used.. with documents of 15 pages in around 15 minutes.. I can only assume.. its the font cache, it's font cache.. but never knowing for sure.. maybe another change..
* Font cache is tricky area.. Developers tend to walk around it for years. And Khaled wasn't to happy with it either (and struggled to understand how it worked).. So I assume the font cache to be a quite a thing; even for experienced developers. Which makes me even more worrisome. And I connecting this with the work of M. Stahl on tables, solve 1 problem, get 2 back. Solve two problems get 4 back..
Or Jmux starting to fiddle with timers, madness appears everywhere (re-resurrecting old hideous bugs etc). So I'm assuming the worst case.. until I'm proven wrong... Especially with fonts/ font measurements being cached/used on different levels. Harfbuzz Internal/ LibreOffice itself?/ the layout cache of Miklos.. all relaying on font lifetime cycles etc. Different font handling between OSes.. So enough potential to go wrong. It started already with welding the Fontbox; adding of a new special rendering; removing a few font caches..
This type of rework you ideally plan in advance to do, not something you want to resolve as side effect of welding; Ideally at the beginning of a new release, not at the point of beta2 or RC1...
And a developer delaying to look at - I assume so; can't proof, maybe looking at it in silence - it doesn't give me much confidence. I don't associate Caolan in addition with font handling in general (more the expertise of Jmux/Khaled) and/or
developing on Windows. Caolan has tons of experience... so maybe underestimating (hope so) but I don't see it as his area of expertise (or interest?). Especially if the font cache code being broken all over the place.. So fiddle with A and B does something unexpected. Fiddle with C and D does something it shouldn't do. Fiddle with E, expect G and get Z.
I'm too pessimistic, I hope..
I tested with Linux 6.5 repo and indeed before the weldfontbox commit the memory use was reset after each close/open cycle. So I don't know - it seems impossible to determine at this point, if this issue is separate. It would be masked behind the remaining issue.