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
([EMAIL PROTECTED])
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
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
