Monday, June 25, 2007

phase synchronicity

so back to more useful things again: plasma, and specifically phase/animator =)

spent some time tonight smoothing out the API so that its is clearer and more consistent (e.g. the more self-documenting "framesPerSecond" instead of "frameCount"; animateItem and animateElement, etc). the animator now defines the curve shape as well.

in separate conversations with both kevin ottens and frederik h. it was suggested that i should consider a single timer instead of separate qtimelines per animation. so i took the plunge tonight and now all animations operate on a single tick and all the items get updated in sync with each other. this decreases the number of timers for N animations from N to 1. of course, it's still 0 when no animations are ongoing.

i need to reimplement the math to alter the frame interval based on the curve shape, but other than that it's all in place and working well.

it's one of those efforts where success means "the result is exactly as it was before", so i have to take heart in the technical improvement it represents ;) i'm also hoping to avoid the odd disjointed feel i experience with microsoft vista when multiple items are animated simultaneously.

speaking of vista.. one of the early code names i had tabled quietly for kde4 was "clarity". that got ruined pretty thoroughly when "vista" was announced as the name for redmond's new desktop. =)

just a few more days to akademy and lug radio live. going to be a blast.

11 comments:

josepfebrer said...

Possibly a bit OT, but I want to ask you if it would be possible to assign arbitrary keybindings to a an individual plasmoid.

For example, if I am browsing internet and I want to use the dict plasmoid or a translator plasmoid with one click I can get the plasmoid that I want with the focus on it's line edit for an easy search, and later if I click the key Esc I can get back to the browser without having to use the mouse.

The Apple Dashboard can't do this and when I open Dashboard I have to look for the widget that I want and I have to click inside it with the mouse to be able to use it.

Josep

Anonymous said...

hey aaron,
i would really like to do some slideshow-thing for plasma (i need my girlfriend on my desktop)

is there any tutorial or guide, that explains how to do this??

best regards Ramin

Anonymous said...

Will having a single timer make all animations interdependent? If one animation is buggy and takes a full second to calculate its next frame, will all the other animations in the system also pause for a second?

As an OSX user I get to experience the joy of having my finder (the entire file viewer of the OS) hang when a single network drive goes down or my network connection dies. I wouldn't wish this on anyone...

tom said...

i agree with the last post, it seems a dangerous thing to do

patpi said...

josepfebrer's idea is great! Pleas implement this one :)

Gustavo Sverzut Barbieri said...

@anonymous: yes, it makes, but no matter how many timers you have, if you have a cpu-sucker it will take all time... you could avoid that by using another thread or process, but this would suck in other places and doesn't worth. What you can do is time each animator and remove those that suck, you need this time anyway so you can recalculate timer based on drift (you can't just reschedule the same timer, you need to take spent time in account)

@aseigo: great work man! This is what evas/ecore provides for some time and works well... You can also use a trick that we employ that is lock display update before running the first item and unlock after the last, then you avoid wasting round trips to X server... just accumulate dirty areas and have them all to be sent to X after you're done. You can run these dirty ares through an optimizer so you remove overlapping areas and merge nearby areas... This helped us a lot: http://blog.gustavobarbieri.com.br/2007/06/03/evas-now-using-rectangle-split-and-merge/

Thanks, albeit developing E for work, I still use kde on my laptop and I'm really wanting kde4 :-)

Anonymous said...

"As an OSX user I get to experience the joy of having my finder (the entire file viewer of the OS) hang when a single network drive goes down or my network connection dies. I wouldn't wish this on anyone..."

I would imagine we are talking about simple animation, here (i.e. move 5 pixels right, change animation frame to "Smiley Face", etc), not network I/O. I'd be fairly surprised if this became an issue, to be honest, except with phenomenally badly-coded Plasmoids.

Aaron J. Seigo said...

@josepfebrer: that's a really nice idea; i'll see what i can do about it. no promises for 4.0, but it's a sane enough idea that i think we should do it at some point.

@anonymous[0]: i'll be putting up tutorials on techbase after akademy. until then you can look at the apidox on api.kde.org and at the code in svn (kdebase/workspace/libs/plasma, kdebase/workspace/plasma/ and playground/base/plasma)

annma has already done an image plasmoid where you can set the image (it's in playground/base/plasma/applets/frame); adding the ability to have multiple pictures or setting a directory to load them from sequentially would be all that's really needed extra i'd think. maybe you could help out there.

you can find us in #plasma on irc.freenode.net if you need some pointers.

@anonymous[1]: as gustavo noted, there's not much one can do about this except optimize the animations themselves and minimize the overhead involved in managing them and pushing the paint ops.

coordinating the animations on one timer is actually better than multiple timers in this case, not worse. it's all in a single thread anyways.

what i do have planned is to put the data engines in a separate thread so that network access, disk access, etc doesn't block the graphics. this was one (of several) reasons for the dataengine/plasmoid split.

@gustavo: hey guy! =) thanks for the kind words. and yeah, you guys are doing some sweet stuff with e17.

sinewalker said...

I appreciate a change 'where success means "the result is exactly as it was before"', especially when "exactly" actually means, "the same, but faster and more reliably". That's how I understand this timer change will work.

On the topic of code names and branding for KDE, don't forget Kaleidos as was mentioned in your blog comments a couple of years ago and originally suggest by Robert Cappuccio. It was discussed here as well. Any development on that front?

Chani said...

josep: good idea, but it might pollute the shortcut-space less if it was implemented a little differently. one global shortcut for pulling plasma to the front, and then a bunch of shortcuts for navigating and interacting with the plasmoids, perhaps?

laptop mouse-like things can be a real pain sometimes - good keyboard shortcuts are one of the reasons I ended up on kde.

Aaron J. Seigo said...

honestly, "kaleidos" is a horrible name. it says little, inspires less and would be a bitch to try and build a harmonized set of marketing messages under.