On 29-Jul-99 Mark B. Elrod wrote:
> we are rewriting the plugin loading stuff for freeamp2 in order to make
> things more efficiaent and reduce the overall memory footprint. right
> now every plugin is loaded at the beginning of the program and it stays
> in memory whether you use it or not. the next version of the plugin
> manager will only load plugins on demand hopefully saving on some memory
> usage.
Demand loading of pages... on linux at least, you're not going to save any
memory by having the plugins only load as needed, since the OS already does
this for you.
> this brings me to my question which is how we should select
> plugins for use inside the player. currently the process involves
> querying each plugin to see if it handles a certain transfer protocol in
> the case of the input plugins or a certain datastream in the case of the
> decoders. if the goal is to keep these plugins out of memory until they
> are really needed then this process needs to change. plugins need to
> "register" themselves once upon startup. i have noticed that netscape
> avoids the overhead of loading shared objects at startup by placing
> registration info inside resources associated with the shared objects.
> While this allows them to load faster as the beginning it is a little
> obscure. i still think loading the plugins and sending them a
> registration message would be the best way to handle this and then
> unload the plugins until you need them.
The way netscape does it is good, I think. If you're aiming to reduce resource
consumption, you shouldn't load the plugins at all, unless needed. It'd be
fairly easy to implement, you'd just have to store all the data that the plugin
would register somewhere along with the current timestamp on the plugin .so.
If the player sees a new plugin not in its saved cache, load it up, store the
data and then unload it.. If it's there, check the timestamps before loading
the whole plugin and going through all the stuff associated with that..
Should provide for a much, much faster startup. freeamp using only a
text gui currently takes a good 5-6 seconds to start playing a song on my
p166.. kinda sucky, really.
> how should decoders determine if
> they handle a bitstream though? it sucks to have to use file
> extensions... should decoders register themselves as handling mimetypes?
> i dunno just brainstorming out in the open. putting the "open" into
> "Open Source"... <grin>
File extensions are the simplest way to do things, imo. Stick a default
decoder for unknown file types, and if that one doesn't work, just pop up a box
or something for user intervention. It'll work perfectly 99% of the
time. Avoiding unnecessary complications is a good thing. =)
Isaac
