Yes, the ownership model is kind of a mess right now. It doesn't really matter yet, since the font cache just grows without bound throughout the lifetime of a session. The reality is that a lot of refcounting probably needs to be added. I want to hold off changing the messed up ownership model until post-3.0 though, so that @font-face can land first. Growing without bound matters less than you might think, since mobile browsers tend to have a limited set of fonts (thus capping the cache size), and desktop browsers can easily handle instantiating every single font (typical Windows install only has ~300, very few of which will even be used on Web pages). dave (hyatt@apple.com) On Jun 30, 2007, at 8:35 AM, Holger Freyther wrote:
Hi,
is it right that FontData owns the FontPlatformData it gets assigned? And that FontData::platformInit and ::platformDestroy define the lifetime of the FontDataPlatform. So if I destroy the "platform specific objects" created by FontPlatformData I will not interact badly with the cache? This ownerhip in the Gdk port was wrong and I needed some time to figure that out.
While reading the code I think I have found a oversight in the FontPlatformData of the Mac port. The FontCache uses a HashMap. This HashMap will use the (implicit) Copy-Constructor and the (implicit) Assignment-Operator of the FontPlatformData to store objects in the cache.
I'm not that familiar with CoreFoundations reference counting, but CFRetain is called in the explicit Copy-Constructor for the NSFont* and I wonder why there isn't an explicit assignment operator increasing the reference on the other font and decreasing it on the current one.
Why does this implicit copy operator work here?
Comments would be appreciated. z. _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev