Optimising xine’s plugin interface

So one of the targets for 1.2 release of xine is to actually get the plugin interface to shape. At the moment it has a lot of small issues needing to be addressed, to begin with the cache.

Anyway, today’s optimisation is geared toward removing two functions from every plugin: get_identifier and get_description.

Those two functions return, as the name suggests, the identifier and a localised description for the plugin. As it stands, they just return a literal (or the return of a gettext call).

I’ve now opened a new branch that replaces the two functions in the plugin classes structures with simply two pointers, that is two strings. This way they can be accessed without adding a call when using it, and also saves adding the actual functions to the plugins.

I first thought of adding the description inside the plugin_info_t structure that’s exported by the shared objects themselves, using N_() to allow internationalising the strings, and then call gettext() when accessing it. Unfortunately this doesn’t work out well for plugins that are injected by the frontend (like Amarok and Phonon do), as they don’t have plugin_info_t and they wouldn’t have the strings present in xine’s catalog.

So while using just one gettext call in libxine for the description would be, performance-wise, simpler, at the moment I just can’t do that, I will investigate if I can tell gettext to just search an extra catalog if none is found though, to see if I can return to that idea.

Anyway, the result compared with codiff (from dwarves package, that actually needs to be bumped), is quite nice, for libxine itself it’s 158 bytes of code less, okay just crumbles, but still nicely done without too much effort. For the plugins it’s 32 bytes each; probably would be more once I get rid of the various gettext calls in the plugins, although that will reduce the improvement for libxine (in the balance, though, it will still be gain).

I also have a couple more plans to change the plugins and reduce the resource waste, but that will come later on today, probably.