On Sat, Nov 22, 2008 at 6:00 PM, Erkin Bahceci <[EMAIL PROTECTED]> wrote: > 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?)
Thanks for the quick and detailed reply. I've had a good read over it and think quite a few of your points make a lot of sense in terms of what I wanted to do. I'll discuss your ideas below > > 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. Arbitrary textures, especially as part of a window sounds like a bad idea, basically because compiz doesn't draw the windows, it just draws the texture. Passing the window ID sounds like a good idea to me, and I was also unsure about animating the whole screen when I first posted by ideas, due to the fact that you would need multiple paintWindow and drawWindow passes with different parameters to do that, which does over-complicate some things. Of course, for some animations, animating the entire screen would make sense (transition wise), others wouldn't make sense. Painting the screen into a texture (texture copy), is a nice idea in theory, but on most hardware it isn't accelerated and requires (to the best of my knowledge) framebuffer objects, something that isn't implemented in most drivers. I think when we start speaking of normal apps animating certain bits of windows, that is out of the scope of compiz (as previously mentioned), and would require some kind of non-compiz depended animation framework that I see happening in the FAR future. I don't think it would be one of the things I am aiming for here. > > 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. Yeah, as said before, animating arbitrary textures doesn't really make much sense, because it becomes a pain for compiz to do (and you get problems with memory access as you said). I personally believe that compiz should not touch these windows, we already have frameworks available like clutter and pigment to do HW-accelerated window drawing, and with things like DRI2 on the march (no matter how many times it gets rewritten), I think that this would be the perfect place to drop in a generic animations library. That would be a far future goal of course, so I think we will just stick to what compiz can handle best (windows) when considering this. > > 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? In terms of plugins, I think we will see a significant code reduction, especially if we get plugins that just want to use the same animation for different things. > > 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. Yes, that definitely makes sense. > > 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. If we're talking about just animating the windows themselves, and not textures, yes that makes a lot of sense and is what I had in mind. The reason why I wanted to break away the event-animations into another plugin is because it would require some kind of framework for other plugins to use the animation plugin, hence we can have another plugin that serves as a dbus-trigger or external library that uses animation, instead of adding more code to animation. In terms of parameters passed to the animation, your list makes sense and I think that if those options aren't passed (asides from the vitals such as the window id, end pos start pos and duration), we can just use the defaults as set by the user. Slightly offtopic, but the 'open_options' method of doing things is more or less not user friendly and difficult to use and I know that this is due to a limitation in both CCSM and libcompizconfig. I will start another mail thread discussing how to solve this issue (and a number of other options system issues) in the future. > > 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. Of course. The ability to do 'extension plugins' has been avaliable long before the compizconfig code was introduced, just things became a pain options-wise because compizconfig couldn't handle extension plugins' options. > > 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. Certainly, if the infrastructure required to do that is too difficult to implement, then perhaps that might not be an idea worth pursuing. The only problem I see with a hardcoded approach is a lack of flexibility, firstly the plugin needs to be updated to include new animations, instead of them being made avaliable and secondly, there is no real way of hardcoding an animation and assuming it exists, if that were the case, we'd be limited to the ones guaranteed to be there by the animation plugin itself. The only problem I see with my approach at the moment is importing animations from subsets like 'open animations', 'close animations' etc, which might only have a few animations and not all of them. Perhaps a bit pool of animations should be made available? I think that flexibility would work in the long-run though, perhaps I can come up with a patch to allow this in the next few weeks? > > 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. OK, I'll talk to them about it then and start brainstorming some ideas for how it might work. > > Finally, I can't say I currently have much free time to work on these, > but I can make suggestions if needed. > Totally understandable. My free time will increase in the next few weeks as I go into summer break. It's been good discussing this with you and I hope that we will be able to make some progress with this proposal, (And I look forward to further discussion). > - 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 > -- Sam Spilsbury -- Developer _______________________________________________ Dev mailing list [email protected] http://lists.compiz-fusion.org/mailman/listinfo/dev
