core animation....

[gummybearx]

i was reading about apple's core animation earlier on digg, and i am worried. it seems to me, that everything apple does, it does well, and i dont think core animation will be any exception.
something makes me feel like beryl/compiz/compcomm is going to get smoked in october. that demo of disco looks sexy, with the smoke, when burning a disc.

does anyone else feel like linux's desktop environment development should be focusing more on a standardized, integral animation core? im not even sure how to go about thinking about this, much less talking about it...

what does everyone think? are we all doomed? what can we do?

for reference:
[url:ee13a]http://www.wired.com/software/coolapps/news/2007/06/core_anim#[/url:ee13a]

[Jupiter]

i was reading about apple's core animation earlier on digg, and i am worried. it seems to me, that everything apple does, it does well, and i dont think core animation will be any exception.
something makes me feel like beryl/compiz/compcomm is going to get smoked in october. that demo of disco looks sexy, with the smoke, when burning a disc.

does anyone else feel like linux's desktop environment development should be focusing more on a standardized, integral animation core? im not even sure how to go about thinking about this, much less talking about it...

what does everyone think? are we all doomed? what can we do?

for reference:
[url:962e2]http://www.wired.com/software/coolapps/news/2007/06/core_anim#[/url:962e2]

I think...........LINUX IS FREE

[gummybearx]

well....yes. i suppose you are onto something??
i mean, what can we do to unify animation between programs and desktop environments and window managers? surley, it would be a worthy, but lofty goal to beable to export a rendering engine for any app to use on a comp with compcomm/beryl/w/e runnning?

[Deciare]

A compositing manager's task isn't only to impose its own animations onto ordinary windows, but also to facilitate the requests of Compositor-aware windows.

Right now, windows can communicate with the compositing manager by using an ARGB visual to selectively tweak portions of itself into different degrees of opacity. That can't be the most that can feasibly be communicated to the compositing manager.

I don't think we need to integrate specific compositing managers with specific desktops, or even unify anything. What we would benefit from is a specification, supported by a reputable organisation such as freedesktop.org, that allows compositing managers to tell other applications which capabilities it supports, then allows those applications to tell the compositing managers which capabilities to use, and how. It would almost be like CoreAnimation, but the "core" (the compositing manager) can be swapped as we please.

There's a lot that can be achieved from communication and shared specifications across programs that don't directly integrate with each other. fdo's specifications already aim to make it easier for non-integrated environments to share the same menu structure, icon themes, configuration data hierarchies, thumbnails, common dialogues, and more by giving them a way to interact without needing to care about what's on the other end. Why not try for the same with compositing managers and their clients?

[SmSpillaz]

As soon as applications support this, then we can do it.

Otherwise we'd have a lot of bloat trying to put separate effects on 10000's of different applications :P

[aantn]

As soon as applications support this, then we can do it.

Otherwise we'd have a lot of bloat trying to put separate effects on 10000's of different applications :P

Well, it seems to me that applications won't be able to support it until we add in the functionality. We don't need to add effects for apps. We just need to add a framework that apps can use.

[SmSpillaz]

I think...........LINUX IS FREE

HAHAHA! Thats got to be the best comeback I've heard all day!

[some-guy]

Jupiter is alive???? :D