Re: [compiz] Plugin Library Interface
Most of the interface we have on the core so far have specific needs and I'm sure future interfaces will too. This library interface would have to be extended to support cases like that. If we do that, then this would work as a low level interface that other interfaces can be layered on top of and plugins can create their own interfaces, which could make sense but I'm not sure. Anyhow, I'm not against this in it's current state even though it seems an awful lot like just providing dynamic library loading which it makes more sense to do using dlopen, dlsym... If we have a case where this interface makes more sense than anything else then fine with including it. The text_to_pixmap interface is very specific and I don't think the functionality itself is a good idea. What are the use cases for this? For rendering text, I suggest that we create an interface that hooks into the drawing framework and allow plugins to implement glyph caching similar to what I once created for xgl and cairo's glitz backend. Do you have other use cases for which this library interface fit in? Yeah actually I tried loading functions from a plugin through dlsym(p-devPrivate.ptr, fooFunc), but we need this management-layer to do some advanced functionality with library functions. In my opinion it makes just more sense to have a updateLibraryFunction, then checking if a plugin, which provided a shared function, got unloaded. Another example which we discussed on IRC are wrap-able library functions. This would let us do some really cool stuff with drawing. A future glow plugin could provide such a wrap-able function (paintGlow) and other plugins could hook into that if needed. The image plugins could use that too, which would eliminate the need for a image interface in core. As far as I know Roi Cohen is currently working on adding wrap-able functionality to shared functions. I don't know how your glyph caching interface in xgl/glitz works, so I'm unsure with that. I'll probably take a look at that later. Using plain shared libraries would be far less beneficial: As Danny already pointed out (link: http://lists.freedesktop.org/archives/compiz/2007-March/001665.html ), there would be no load notifications, no wrapping of functions (in both directions: library plugins couldn't wrap into core functions and plugins could not wrap into library functions) and library functions could not offer any options to the end user. Regards, Patrick ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Plugin Library Interface
On Wed, 2007-03-07 at 14:28 +0100, Patrick Niklaus wrote:
Hi,
some of you might noticed that there was recently some discussion on
the Beryl ML about an interface which provides sharing functions and
allows us to do library plugins. One example for this kind of plugins
is text, which was recently ported to that system. I now want to
explain here how it works in general.
Core does save the shared library functions in a CompLibraryFunction struct:
struct _CompLibraryFunction {
CompLibraryFunction *prev;
CompLibraryFunction *next;
char *name;
void *function;
};
Core also gets a number of utility functions:
void addLibraryFunction (CompDisplay *d, char *name, void *function);
void removeLibraryFunction (CompDisplay *d, char *name);
void* getLibraryFunction (CompDisplay *d, char* name);
void updateLibraryFunction(CompDisplay *d, CompLibraryFunction *func);
You can register a function through addLibraryFunction and remove it
with removeLibraryFunction.
Whenever a function gets added or removed updateLibraryFunction is
called. Like initScreen/finiScreen it's done through a additional
entry in the vTable. It doesn't make sense to make this function
wrap-able, it's just too important and no plugin should be able to
stop or manipulate it.
Plugins which need a shared function can get it through
getLibraryFunction, most likely you will call that in initDisplay and
just save the pointer to the function.
When you want to see how exactly it's used in plugins you can have a
look at text-plugin, which is in beryl-plugins at trunk
(http://bugs.beryl-project.org/browser/trunk/beryl-plugins/src/text.c).
We just want to get some feedback on these ideas. If you are
interested I can provide a patch for compiz too.
Hey Patrick,
Thanks for your explanation. I don't know if this is a good idea or not.
Most of the interface we have on the core so far have specific needs and
I'm sure future interfaces will too. This library interface would have
to be extended to support cases like that. If we do that, then this
would work as a low level interface that other interfaces can be layered
on top of and plugins can create their own interfaces, which could make
sense but I'm not sure.
Anyhow, I'm not against this in it's current state even though it seems
an awful lot like just providing dynamic library loading which it makes
more sense to do using dlopen, dlsym...
If we have a case where this interface makes more sense than anything
else then fine with including it.
The text_to_pixmap interface is very specific and I don't think the
functionality itself is a good idea. What are the use cases for this?
For rendering text, I suggest that we create an interface that hooks
into the drawing framework and allow plugins to implement glyph caching
similar to what I once created for xgl and cairo's glitz backend.
Do you have other use cases for which this library interface fit in?
- David
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Plugin Library Interface
Hi, Except from the notifications on Load/Unload it does not offer anything but another framework to load dlls at runtime. I fail to see any real benefit Maybe I should outline the benefits a bit more: - as you said, load/unload notifications - library plugins can wrap into core functions, dlopen'ed ones can't - library plugins can have options, dlopen'ed ones can't All in all library plugins are more plugin than a plain library, plugins which just happen to provide arbitrary functions to other plugins. Maybe the text plugin isn't the best example, but imagine a movement animation plugin where other plugins can request movement animation calculations from. This plugin would wrap into preparePaintScreen, do all the needed calculations and deliver the results to the requesting plugins. With such a plugin, all the animation settings (e.g. speed / timestep) or types (spring model like as it is now / new linear animation) could be set inside this plugin. Of course the API design of such a plugin would need a lot of thinking about first, but the first step is to create a framework to make it possible in theory. Regards, Danny ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Plugin Library Interface
Patrick Niklaus wrote: We just want to get some feedback on these ideas. If you are interested I can provide a patch for compiz too. Thanks for showing us this. I have a couple of questions though. What are the major pros/cons of using this method over plain old libraries? Do you have any other library plugins other than text? Or what do you plan for other types of library plugin? It seems like only text and group use this at the moment. ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Plugin Library Interface
Hi, What are the major pros/cons of using this method over plain old libraries? They plug into the normal plugin infrastructure and don't add the need for plugin writers to mess around with dlopen(), dlsym() and such. Basically, they work like normal libraries and look like a plugin. A large advantage is that every plugin gets a notify whenever a library plugin is loaded or unloaded. Do you have any other library plugins other than text? Or what do you plan for other types of library plugin? It seems like only text and group use this at the moment. Currently the only library plugin is text. In the future however, there could be library plugins like window move animation which provides means for the move animation currently found in scale, switcher and such (that animation which is adjustable by speed timestep). That way, this animation code would only be needed once. Cornelius even suggested breaking animation into subplugins by using that library plugin approach. Each separate animation would get its own subplugin then, and animation.c would only provide the framework to glue them together. And in Beryl, the text plugin is not only used by group, but also by switcher and scale. I could provide a patch which adds text display support (on hovering) to scale, but that patch would need the text plugin which is a bit problematic if scale is considered a core plugin and text isn't ;-) Regards, Danny ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Plugin Library Interface
Danny Baumann wrote: What are the major pros/cons of using this method over plain old libraries? They plug into the normal plugin infrastructure and don't add the need for plugin writers to mess around with dlopen(), dlsym() and such. Basically, they work like normal libraries and look like a plugin. A large advantage is that every plugin gets a notify whenever a library plugin is loaded or unloaded. The amount of code in the text library is very small and seems like it would do just as well as a normal c library. Other than being notified when it is added or removed I don't see how it is beneficial. Using a library would mean that the functionality could always be guaranteed. I also think that your symbol lookup table could get really slow if there were more than 20 functions loaded, have you done any benchmarks on this? Do you have any other library plugins other than text? Or what do you plan for other types of library plugin? It seems like only text and group use this at the moment. And in Beryl, the text plugin is not only used by group, but also by switcher and scale. I could provide a patch which adds text display support (on hovering) to scale, but that patch would need the text plugin which is a bit problematic if scale is considered a core plugin and text isn't ;-) It would be very simple if it were just a library, there would be no need to port from and to compiz because the same library would work without modifications on both. It looks like the major advantage is that functions can be loaded and unloaded at runtime. The major disadvantages being slowness, possibility of crashes and incompatibility. I think we would all welcome libraries which make plugin developers lives easier, maybe you could write a library which has lots of compiz/beryl helper functions. I suspect something like that, combined with a patch which uses the functionality in some plugins would be very useful. Is the text plugin still integrated into the fileFromImage hooks or are you only using it as a library plugin now? ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Plugin Library Interface
Am Mittwoch, 7. März 2007 16:59 schrieb Mike Dransfield: Danny Baumann wrote: What are the major pros/cons of using this method over plain old libraries? They plug into the normal plugin infrastructure and don't add the need for plugin writers to mess around with dlopen(), dlsym() and such. Basically, they work like normal libraries and look like a plugin. A large advantage is that every plugin gets a notify whenever a library plugin is loaded or unloaded. The amount of code in the text library is very small and seems like it would do just as well as a normal c library. Other than being notified when it is added or removed I don't see how it is beneficial. Using a library would mean that the functionality could always be guaranteed. The idea behind this is, that no new dependencies are needed in a plugin, if you use this system. Currently text depends on cairo and pango, but each plugin that uses the library interface does not need to depend on it. If the text plugin is not available the text is simply not rendered. There could also be another text plugin that uses qt to render the text. I also think that your symbol lookup table could get really slow if there were more than 20 functions loaded, have you done any benchmarks on this? Do you have any other library plugins other than text? Or what do you plan for other types of library plugin? It seems like only text and group use this at the moment. And in Beryl, the text plugin is not only used by group, but also by switcher and scale. I could provide a patch which adds text display support (on hovering) to scale, but that patch would need the text plugin which is a bit problematic if scale is considered a core plugin and text isn't ;-) It would be very simple if it were just a library, there would be no need to port from and to compiz because the same library would work without modifications on both. It looks like the major advantage is that functions can be loaded and unloaded at runtime. The major disadvantages being slowness, possibility of crashes and incompatibility. I think we would all welcome libraries which make plugin developers lives easier, maybe you could write a library which has lots of compiz/beryl helper functions. I suspect something like that, combined with a patch which uses the functionality in some plugins would be very useful. Is the text plugin still integrated into the fileFromImage hooks or are you only using it as a library plugin now? The text plugin now only uses the library interface. ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Plugin Library Interface
Danny Baumann wrote: Other than being notified when it is added or removed I don't see how it is beneficial. Using a library would mean that the functionality could always be guaranteed. There might be functionality which isn't needed to be guaranteed. The animation subplugins were an example, the text plugin is another. Some person might think that he doesn't need text display, so he can simply disable it. It could also be disabled with an option, or at compile time. If it was a really big library then you could use dlopen, but this is just one function. I also think that your symbol lookup table could get really slow if there were more than 20 functions loaded, have you done any benchmarks on this? Why should it be slow? Of course, plugins using library plugin functions shouldn't look them up everytime they use it, but instead store a function pointer when their updateLibraryPlugin routine is called. It would be slower than the alternative of just compiling this one function in, simply because there would be no need to update their function pointers. Plugins would take longer to load. I cannot see how this method would ever be quicker (overall it is taking more resources). Can you please elaborate on your concerns about slowness (see my argument above), possibility of crashes (a versioning scheme could be used) and incompatibility? I do not think that such tight coupling of plugins will lead to a stable system. The plugins should be unaware of each other as much as possible. I do not see an awful lot of benefits over standard linking methods. Adding a versioning scheme just sounds like you are reinventing the wheel. There is incompatibility between compiz and beryl. All that needs to be done is rip the textToPixmap function from text and add it to whatever plugin you want to draw text. It provides the same functionality with very little overhead. Then all the extra functions you have added will be removed. Will the user be able to notice a difference? All you seem to have here is a beryl specific dynamic library loader. If dlopen is too hard, then couldn't you write wrappers to make that easier? That way everyone could benefit from your hard work. ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Plugin Library Interface
Dennis Kasprzyk wrote: Am Mittwoch, 7. März 2007 16:59 schrieb Mike Dransfield: Danny Baumann wrote: What are the major pros/cons of using this method over plain old libraries? They plug into the normal plugin infrastructure and don't add the need for plugin writers to mess around with dlopen(), dlsym() and such. Basically, they work like normal libraries and look like a plugin. A large advantage is that every plugin gets a notify whenever a library plugin is loaded or unloaded. The amount of code in the text library is very small and seems like it would do just as well as a normal c library. Other than being notified when it is added or removed I don't see how it is beneficial. Using a library would mean that the functionality could always be guaranteed. The idea behind this is, that no new dependencies are needed in a plugin, if you use this system. Currently text depends on cairo and pango, but each plugin that uses the library interface does not need to depend on it. If the text plugin is not available the text is simply not rendered. There could also be another text plugin that uses qt to render the text. This would make sense if you wanted to add textToPixmap to core and then use different plugins to wrap it, in the same way as the image plugins do now. But this is not what you are proposing. Maybe that could solve your particular text problem better? ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Plugin Library Interface
2007/3/7, Mike Dransfield [EMAIL PROTECTED]: It could also be disabled with an option, or at compile time. If it was a really big library then you could use dlopen, but this is just one function. Doing it through an option would be a real mess in the settings manager and just removing it at compile time would mean code becoming very growed with defines. I do not think that such tight coupling of plugins will lead to a stable system. The plugins should be unaware of each other as much as possible. I do not see an awful lot of benefits over standard linking methods. Adding a versioning scheme just sounds like you are reinventing the wheel. Adding a versioning system isn't that hard in this case. Just storing the size of the typedef containing the functions information should be enough. There is incompatibility between compiz and beryl. All that needs to be done is rip the textToPixmap function from text and add it to whatever plugin you want to draw text. It provides the same functionality with very little overhead. Then all the extra functions you have added will be removed. Will the user be able to notice a difference? Thats why I said I would provide a patch for Compiz as well. Are you really saying code duplication is good? If the user could tell the difference isn't relevant here, but it's much harder to maintain code of you have copies of it in 4 source files. Making every plugin that wants to draw text depending from pango is another bad thing. All you seem to have here is a beryl specific dynamic library loader. If dlopen is too hard, then couldn't you write wrappers to make that easier? That way everyone could benefit from your hard work. See my answer above. This would make sense if you wanted to add textToPixmap to core and then use different plugins to wrap it, in the same way as the image plugins do now. But this is not what you are proposing. Maybe that could solve your particular text problem better? I thought core should be kept as small and simple as possible? Regards, Patrick ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
