Hi Sam, If I understand correctly, you want to see these separate changes:
1) compiz plugins and external programs to have the ability to use animations implemented in animation and its extension plugins for a particular window (or a particular texture+geometry or the whole screen). 2) ccsm/simple-ccsm to have the ability to display the names of all animations available for a certain event (e.g. open) as added to the selection list of some option in some plugin so that the user can choose which animation should be used for that option, whatever that option might be for. 3) the animation plugin to be split into two as event handler and the actual animator to make adding new events easier (like maximize?) Just to form a clear set of requirements, can you state a few particular use cases for these? First of all, what is supposed to be animated? Only windows (as it is now)? Arbitrary textures (and geometries)? The whole screen? Animating the whole screen might complicate things quite a bit, especially for certain animations, since the screen is not stored in a texture. You'd need to do multiple paintscreen passes if parts that need different transformations are involved. So this would be problematic performance-wise for anything but the simple-transformation-type animations. The alternative, painting the screen into a texture to animate it at each step, would probably also be bad for animation performance. For animating arbitrary textures+geometries, a list of vertex coordinates and texture coordinates should be passed along with the texture, which should all be copied when received, since we can't rely on that memory region to stay allocated until the animation ends, for stability reasons. This would use up extra memory and could lead to a slight delay at the start of the animation if the texture is too large. The question is, how useful would animating the whole screen or arbitrary textures+geometries in the animation plugin be and how much code reduction it would result in other plugins or external programs? For animating a window, since windows are usually drawn using two textures (decoration texture, including shadows, and window-contents texture), passing a single texture to the animation plugin would not work. A window id would be better suited as a parameter in that case. In (1) above, for external applications to make use of animations, a dbus interface would be the ideal choice: a dbus call with the window id, parameters (e.g. animation name, duration, initial and final window pos./size, etc.), and animation option names+values (possibly in the string format that is already handled for open_options, etc.). A "dbus-trigger" event can be added to the animation plugin to handle such dbus calls by any external application which wants to animate one of its windows. The same dbus interface could also be used for compiz plugins. Alternatively, plugins could initiate animations with a compiz event. Though in that case, probably there should also be an event signaled by the animation plugin to report the completion of the animation. I'd like to clarify that the animation extension API (in the plugin C code) and the compizconfig string-restriction-extension mechanism are completely independent. The extension-related tags in the metadata are not read or used by plugins. They are just there for ccsm or simple-ccsm to be able to add the animation-name strings to the necessary option selection boxes. So the metadata changes you suggest are not really necessary for a plugin to use animations from the animation plugin. Assume a plugin P wants to use some animations. It's likely that P would be interested in using only a fixed subset of the available animations (for, say, open event) since all animations will probably not be suitable for its purposes. The options of those animations would have to be hardcoded into P's code for their names+values to be passed to the animation plugin (for options where default values are not acceptable). If those are going to be hardcoded anyway, P might as well hardcode the names of the animations in its metadata (and code), which gets rid of the need for compizconfig to do additional complicated option-extensions just for that purpose. So unless there are good examples of where this could be useful, I don't think those metadata additions are necessary. I don't know how useful it would be to have an additional interface to retrieve animation options either. What would P do with a generic list of options? Pick a few known ones and provide values for those only? That could be done by hardcoding them as mentioned above. So it seems to me that (2) is not that necessary. About the suggestion for splitting the animation plugin into two: That window-animations plugin would be similar to the animation framework that was planned for a future version of compiz. You might want to talk to Dennis and Danny about this, if you haven't already. So the event handler part of the animation plugin would be integrated into compiz to trigger the animations in plugins like animation, minimize, wobbly, fade, etc. Triggered animation events would include open, close, minimize, focus (which will probably be the most problematic one), shade, maximize, and dbus-trigger (for external triggering). So I think splitting the animation plugin into two plugins isn't useful or necessary at this point since one of them would be made a part of compiz in the future anyway. Finally, I can't say I currently have much free time to work on these, but I can make suggestions if needed. - Erkin On Sat, Nov 15, 2008 at 11:29 PM, Sam Spilsbury <[EMAIL PROTECTED]> wrote: > Hi, > > I'd like to discuss some ideas I have about reworking the animation > plugin that comes with compiz-fusion. > I feel that the recent work done on the animation plugin and > libcompizconfig such as extension > options, the extension interface to animation itself and other things > are really a step in the right > direction for the plugin. The reason for this being, of course, is > that the options of animation are now > extendable. > > However, I think that this extension interface can be taken further > and made much more robust than it is > now. Right now, it appears that plugins can import other plugin's > headers and their display index's, so two-way > communication between plugins there is certainly possible. However > with extension options, it appears that the > communication is really only one way. An example of this might be: > > <plugin name="animation-addons"> > ... > <extension base_plugin="animation"> > <base_option>open_effects</base_option> > <(extend effects from here with string restrictions)> > > On animation's side, we have > > <option name="open_effects"> > <extensible/> > > This is a nice interface, the the problem is that 'animation-addons' > must specifically extend 'animation'. > What happens if there is another plugin that animation-addons can also > extend? We have to add more > metadata and patch the plugin. > > I think that the extension system would really benefit from something like > this: > > <plugin name="animation"> > ... > <option name="open_effects"> > <extender feature="open_effects_animation"> > > <plugin name="windowFX"> > ... > <option name="move_effects"/> > <extended "open_effects_animation"/> > > In this kind of system, a plugin can just provide an 'extension > feature' and other plugins are 'extended' by > this feature. This way, plugins can simply request all the > 'open_effects' from the animation plugin and display > them. The benefit of this is that we now have actual library plugins > in options, plugins could already use code > from other plugins, but now they can use options from other plugins > without being extended. > > I will post the second part to this in a second. > On Sun, Nov 16, 2008 at 12:21 AM, Sam Spilsbury <[EMAIL PROTECTED]> wrote: > Moving on to the second part, I'd like to use this system used to > split the animation plugin in two again: > animations-core and event-animations. The reason? Well, if we want to > add more event animations then > we need to modify the animation plugin directly. Also, the event > handling code and the actual animation > code are too coupled. A lot of plugins have to write their own code to > handle animating from point-a to > point-b. This is a huge waste of code, especially when we could be > re-using animations from the animations > plugin to do that. Here's how it would boil down. > > Animations-Core: > > Animations core would essentially be the bit that does the animations, > i,e the bit that wraps into paintWindow, > paintOutput, drawWindowTexture, drawWindow, addWindowGeometry etc etc. > It handles the playback of > animations. All the event-handling code would essentially be stripped > out and moved into another plugin > which would make use of animation. Some API's necessary would be: > > * The plugin sets the <extender feature="animation_*> flag on all > it's animation-selection options, so that other plugins can select > animations. > * The plugin would have an api, something like functionPointer = > animGetAnimation (s, char *animation); which > would return a function pointer (This would have to be typedef'd) > to the animation requested. > * Every animation function (which plays the animation) would have to > be constructed something like: > void animation (CompObject *object, CompOption *option, int > nOption). The CompOption contains all the options > for the animation determining how it would be played. We need some > kind of interface for retreiving these options, > I would think - through compizconfig would be nice. The CompObject > is there to specify whether to animate a whole > screen's texture, or just a window texture. Perhaps we could just > pass a CompTexture to be more general? > > Window-Animations: > > Window animations is essentially the event-handler part of the > animations. It wraps into handleEvent, initWindow etc > in order to play the user-specified animation on that event. It uses > the API's made avaliable to it via animations-core, > so a breakdown of how it would work is: > * Set the <extended feature="animation_*"> on relevant options, so > that animation can give it's options to the plugin > * Hook into events, select the animation for the window based on the > match etc, get the function pointer for that animation > and call it with relative options. > > This way, we can have other plugins animate windows from A to B via > animations-core just like window-animations does. > > -- > Sam Spilsbury -- Developer _______________________________________________ Dev mailing list [email protected] http://lists.compiz-fusion.org/mailman/listinfo/dev
