I'd been sending this sort of stuff to Dean and John but maybe other
people will find it interesting.

Plugin loading works in two phases:
- at startup, we scan the plugin directories for metadata, like plugin
names and which mime-types they apply to;
- at runtime, when we're asked for a specific plugin by mime type, we
open the appropriate library and have at it.

On Windows and Mac, the startup step queries file metadata (version
info on Windows, plists on Mac).
On Linux, that step must dlopen() the plugin and poke a function in
it.  This means if a plugin ends up getting used we open it twice,
which is especially brutal because Flash can take multiple seconds to
open for me (complicated story, Adobe is working on it).

It appears that Mozilla (maybe for similar reasons) caches this info
across browser runs and relies on the file mtime to see when its cache
has expired, much to some users' dismay:
  https://bugzilla.mozilla.org/show_bug.cgi?id=125469
Or at least they did in 2002.  ;)

For now (for test_shell) I think I'll just pay the double-load cost.
The alternative is leaving plugins open, which I think wastes memory
and hurts load time.  At some point we'll have to look at performance
and decide about the cache thing.

PS: Do we scan for plugins on a background thread in the normal
browser startup?  If so, how do we prevent races between that scan and
someone's home page requesting a plugin?

--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: [email protected] 
View archives, change email options, or unsubscribe: 
    http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---

Reply via email to