14601 2007-07-13 03:35:27 -0700 WebCore/Windows: too many FontData object and takes too much memory 2007-07-19 14:21:20 -0700 1 1 1 Unclassified WebKit WebCore Misc. 523.x (Safari 3) PC Windows XP RESOLVED FIXED InRadar, PlatformOnly P1 Major --- 1 808caaa4.8ce9.9cd6c799e9f6 hyatt oldest_to_newest 4910 0 808caaa4.8ce9.9cd6c799e9f6 2007-07-13 03:35:27 -0700 In WebCore::FontCache::getFontDataForCharacters(), many many FontData/FontPlatformData objects created with same constructor parameters. HFONT by IMLangFontLink2 is cached result(documented in MSDN docs). FontPlatformData objects have CFFont object, work buffer, for each. FontData/FontPlatformData objects live as long as the process lives. Another saying, objects isn't destroyed even after closing assosiated views. Example: viewing news.google.co.jp, with caching FontData objects like this: ------------------------- .../WebCore/platform/win/FontCacheWin.cpp ------------------------- fontData = new FontData(FontPlatformData(result, font.fontDescription().computedPixelSize(), font.fontDescription().bold(), font.fontDescription().italic())); -> fontData = CreateFontDataWithCache(result, font.fontDescription().computedPixelSize(), font.fontDescription().bold(), font.fontDescription().italic()); ------------------------- Results: only 8 objects created, and almost 1400 objects avoided from creation, 30MB memory seems to be saved (71MB used without cache, 40MB used with cache.) 4759 1 ddkilzer 2007-07-14 15:19:29 -0700 <rdar://problem/5335829> 4571 2 hyatt 2007-07-16 13:08:38 -0700 I think this should be P1. 4573 3 hyatt 2007-07-16 13:15:17 -0700 Actually lowering this back to P2. This case should only get hit if no font specified in CSS contains the right characters. I'm not completely sure how we would go about caching this result, since the value returned is dependent on the characters being used. 4574 4 hyatt 2007-07-16 13:16:48 -0700 Oh, never mind, I get it. 4576 5 hyatt 2007-07-16 13:22:19 -0700 This is definitely a P1 issue. Mac is actually using the cache for this method, but Windows is creating a new FontData every time. 4579 6 hyatt 2007-07-16 13:48:43 -0700 My assumption was that mlang would give me different HFONTs, but if it really does cache fonts internally, then we can simply use our cache on top of mlang. 4554 7 808caaa4.8ce9.9cd6c799e9f6 2007-07-17 02:38:08 -0700 errata: not CFFont, is CGFont, of course. http://msdn2.microsoft.com/En-US/library/aa741043.aspx > IMLangFontLink does (font linking) by creating custom fonts and > providing an underlying font cache in the implementation. Actually same (DWORD)HFONT returns many times, and number of GDI objects NOT SO increased. 4538 8 ddkilzer 2007-07-17 07:10:58 -0700 Fixed in r24332. 4375 9 808caaa4.8ce9.9cd6c799e9f6 2007-07-18 18:32:49 -0700 new impl: beautiful. ----- FontPlatformData platformData(result, ...); fontData = getCachedFontData(&platformData); fontData->setIsMLangFont(); ----- I fear if this temporary platformData's associated objects is successfully deleted.... (Of cource, platformData itself is on local stack.) ----- FontPlatformData::~FontPlatformData() { } ----- In FE environment this constructor is called for almost every every every FE chars. Constructor checks and fills for m_synthetic***s with calling GetOutlineTextMetricsW(),EnumFontFamiliesEx() each time, and creates CGFont inside. Checking before creating FontPlatformData objects is with reality, rather than implementing destructors or delay-CGFont-creation, I thought. Additional info. (might be another issue but related) IMLangFontLink certainly caches our HFONTs, but it's cache slot might be too small? langFontLink->MapFont() seems returns E_INVALID so often with correct arguments... why? I'm working now for verification about this hypnosis. If proofed, I'll report here and ask for instructions. 4265 10 hyatt 2007-07-19 14:21:20 -0700 There is an underlying CGFontRef cache, so we are not creating new CGFontRefs every time.