Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Keyframes: Delivering scalable, high-quality animations to mobile clients

code.facebook.com

Post reply on HN
Print view View original

91–100 of 153 posts

Re: Keyframes: Delivering scalable, high-quality animations to mobile clients

#91

Post by TD-Linux »

echelon wrote: post #27
lozzle wrote: post #23

Hey, everyone! I'm one of the developers at Facebook who worked on this library since its conception! Really excited to be able to share this library today! I'll be checking up here periodically and can help answer any technical questions that you have!

Why does the software license [1] include the following clause: > provided Your Software does not consist solely of the Software Why didn't you guys choose MIT or BSD? It feels like the custom Facebook license is close to the intent of these, but it has that mysterious gotcha. In any case, thanks for the software! It looks really slick, and I definitely have a use case for using it to replace the sprite sheet I used…

It's not the first time they've used this license: https://github.com/facebook/transform/blob/master/LICENSE

(in that case, they even used it to distribute a patch to ffmpeg, which is LGPL)

Re: Keyframes: Delivering scalable, high-quality animations to mobile clients

#92

Post by misio »

seanwilson wrote: post #70
misio wrote: post #63

Earlier quoted context omitted.

>I'm not understanding why this isn't interesting to programmers who on a daily basis have to weigh up the pros and cons of different technology/library choices. Perhaps I'm showing my age, but this feels like this problem was solved a long time ago, forgotten or unused to a large extent and now re-invented. Flash was the clever web version back in the day but I can't see anything really new in this. I could absolute…

Flash isn't supported on mobile browsers (now), native Android or native iOS though.

Oh, absolutely. It was a heavy implementation of a similar solution and the mobile ecosystem is better off without it.

Re: Keyframes: Delivering scalable, high-quality animations to mobile clients

#93

Post by misio »

city41 wrote: post #26
omginternets wrote: post #7

Earlier quoted context omitted.

Your example speaks to my point: there's nothing new, innovative, technically challenging (beyond the norm). I really don't see what there is to write home about. This article reads as a PR announcement (which is okay) disguised as a technical achievement (which it isn't). They're "just" animations.

Maybe not the biggest breakthrough ever, but it does fill a gap. Animations like this on the web really weren't possible without either using Flash or SMIL. A completely JavaScript based solution is very welcome.

I think the annoyance is the slightly smug tone of "Look what I invented. Vector animation and keyframes!"

It's a cool implementation but it feels like they are claiming to have broken amazing new ground. To people that don't understand much of the background technology that's exactly how it reads.

Re: Keyframes: Delivering scalable, high-quality animations to mobile clients

#94

Post by eva1984 »

zigzigzag wrote: post #60

I was totally down with this - a tight, efficient vector graphics format with After Effects integration, super - up until the point they said these animations were JSON files. Huh? Didn't I just read a whole blog post saying that one of their requirements was fast loading from disk, small bandwidth usage, etc? And that's what justified creating an entirely new image format from scratch, not something the internet is…

My reaction exactly...JSON seems a horrible choice to encode numeric data. Protobuf will be much better.

Re: Keyframes: Delivering scalable, high-quality animations to mobile clients

#95

Post by BinaryIdiot »

mahyarm wrote: post #84
BinaryIdiot wrote: post #76

Earlier quoted context omitted.

While a binary format would be better over the wire, once it's put into memory the format really doesn't matter. In fact I would argue that the decision to use JSON versus XML versus a binary format is entirely immaterial as it'll get cached once and likely never downloaded again (essentially). At least as far as Facebook's usage is concerned (they load these 6 once and never again). Also I think you have to pick som…

As someone who has to deal with mobile perf issues, JSON serialization/deserialization can take a lot more of a perf budget than you realize. A flatbuffer version would definitely be faster hands down. With gzip sizing is about the same, but processing speed wise it is not.

> As someone who has to deal with mobile perf issues, JSON serialization/deserialization can take a lot more of a perf budget than you realize. A flatbuffer version would definitely be faster hands down

With something that's grabbed once and cached likely forever I think the tiny bit of overhead for JSON won't make any difference. I've done this too and yes, of course a flatbuffer would be faster but the speed is just related to the initial download and caching. Beyond that you'd keep it in whatever structure is more efficient for the app to re-use.

Re: Keyframes: Delivering scalable, high-quality animations to mobile clients

#96

Post by cosmotron »

echelon wrote: post #36
electic wrote: post #34

Earlier quoted context omitted.

You are misreading it. Software = Keyframes software. Your Software = Whatever you are releasing. So basically they are saying you can't redistribute just the Keyframes software library by itself. Which also means, if I understand this right, you can't fork it and modify it either. I agree however, not a good license.

I'm not misreading it. The license says we cannot fork the software. That's not open source.

Isn't a different interpretation that a fork is, presumably, their software _plus_ your modification(s)? Thus, a fork is not "solely" their software anymore and is allowed.

Re: Keyframes: Delivering scalable, high-quality animations to mobile clients

#97

Post by mahyarm »

BinaryIdiot wrote: post #95
mahyarm wrote: post #84

Earlier quoted context omitted.

As someone who has to deal with mobile perf issues, JSON serialization/deserialization can take a lot more of a perf budget than you realize. A flatbuffer version would definitely be faster hands down. With gzip sizing is about the same, but processing speed wise it is not.

> As someone who has to deal with mobile perf issues, JSON serialization/deserialization can take a lot more of a perf budget than you realize. A flatbuffer version would definitely be faster hands down With something that's grabbed once and cached likely forever I think the tiny bit of overhead for JSON won't make any difference. I've done this too and yes, of course a flatbuffer would be faster but the speed is jus…

Unless they store the cached version as a flatbuffer or similar format, you will suffer a penalty every app startup. And startup is where a lot of mobile perf is focused on. I haven't heard of SVG renderers storing SVG XML files in a more efficient format. It's like using jpeg2000 compressed images vs. PNG. And if you use a lot of them, it will add up.

Re: Keyframes: Delivering scalable, high-quality animations to mobile clients

#98

Post by st3v3r »

andybak wrote: post #53
echelon wrote: post #36

Earlier quoted context omitted.

I'm not misreading it. The license says we cannot fork the software. That's not open source.

They had better start paying their lawyers overtime. You can't do a PR without forking and people fork on Github for a multitude of reasons (I often fork into a group as a lazy form of bookmarking or collecting projects). Hell. I just clicked the 'fork' button. Where's my cease and desist?

A PR isn't the only way to contribute. You can also check out the repo and send in patch files.

Re: Keyframes: Delivering scalable, high-quality animations to mobile clients

#99

Post by st3v3r »

LeanderK wrote: post #90
peller wrote: post #44

Earlier quoted context omitted.

They want the user adoption, without giving up control, presumably.

this might be silly, but why? what does Facebook gain by getting this library user adoption (beside some bug-reporting). I would think that for fb user adoption of the open source projects is not the goal, but getting OSS developers attracted and getting fixes/features etc. developed from them. Or is it some kind of pride? Fake internet point for having repositories on github?

Dev mindshare.

Re: Keyframes: Delivering scalable, high-quality animations to mobile clients

#100

Post by zwegner »

echelon wrote: post #27
lozzle wrote: post #23

Hey, everyone! I'm one of the developers at Facebook who worked on this library since its conception! Really excited to be able to share this library today! I'll be checking up here periodically and can help answer any technical questions that you have!

Why does the software license [1] include the following clause: > provided Your Software does not consist solely of the Software Why didn't you guys choose MIT or BSD? It feels like the custom Facebook license is close to the intent of these, but it has that mysterious gotcha. In any case, thanks for the software! It looks really slick, and I definitely have a use case for using it to replace the sprite sheet I used…

Note that, by publishing this repo publicly on GitHub, there is a right to fork granted by GitHub's ToS[0], which this license seems to conflict with (though IANAL of course...). Not sure what "fork" means in this context, whether it's just duplicating a repository or also modifying it.

[0] https://help.github.com/articles/github-terms-of-service/#f-... Section F.1: "By setting your repositories to be viewed publicly, you agree to allow others to view and fork your repositories."

Post reply on HN