alexkcd

The graphics stack in Android is badly designed. It is that way for historical reasons. Android used to do CPU-based blitting -- similar to other mobile platforms at the time: Symbian OS and Windows Pocket PC. Then the first iPhone launched & it became clear that GPU rendering was the way to go for mobile UI drawing.

Rather than rebuild the graphics stack from the ground around GPU rendering, GPU support was tacked on to the existing graphics stack. Resulting in this franken-architecture: http://source.android.com/devices/graphics/architecture.html

That guide has such gems as:

"Once upon a time this was done with software blitting to a hardware framebuffer (e.g. /dev/graphics/fb0), but those days are long gone."

"While this section uses SurfaceFlinger terminology, WindowManager uses the term window instead of layer…and uses layer to mean something else. (It can be argued that SurfaceFlinger should really be called LayerFlinger.)"

"Some things that work with Surfaces want a SurfaceHolder, notably SurfaceView. The original idea was that Surface represented the raw compositor-managed buffer, while SurfaceHolder was managed by the app and kept track of higher-level information like the dimensions and format. The Java-language definition mirrors the underlying native implementation. It's arguably no longer useful to split it this way, but it has long been part of the public API."

etc.

These stations don't get used much because Tesla sells a battery with every car they make. If the cars came without the battery, there would be a lot of demand, but would also require the infrastructure to be in place to support long range travel. It's a classic chicken and egg problem.

What Tesla discovered is that bootstrapping the battery swap infrastructure off of battery owners doesn't work, since owners are reluctant to pay for swapping out their battery over recharging the one they own.

Objective-C is a good example of successfully migrating the language forward. Breaking changes were introduced slowly. Library APIs are marked as deprecated several releases prior to removal. The compiler warns you of their use. Automatic reference counting can be turned off for legacy files, but a tool is provided that will help you convert a class to use ARC.

Code written in ObjC a couple of years ago will likely not run today without modifications. But overall this has been a net positive for the language. It's actually become really pleasant to use. And is in part why Apple's platform has thrived.

I think optimizing for the past is the wrong thing to do. If your language is successful, then most of the code is yet to be written. So if your choice is between making future code easy to write, or not breaking legacy code, then you should err on breaking legacy code and provide deprecation/migration tools.

Personally, I prefer languages that make small incremental breaking changes, as it prevents cruft from accumulating over time.

The important thing is to provide a migration path (e.g., begin by marking something as deprecated). Then provide refactoring tools to help migrate or interface with legacy code.

I think C++ would have been much better off had it been willing to do this. Paraphrasing Stroustrup: C++11 has within it a smaller more elegant language that's trying to break free.

Neat! That said, std::sort is a template function, so you can pull the source (e.g., take the one from libc++) and change the comparator to return an int. You will still get all the benefits of inlining and optimizations from lack of type erasure, while performing only one comparison :)

Edit: Actually quicksort only needs a stable boolean comparator (e.g., < or >) to determine order. So the number of invocations to the comparator is the same for both qsort and std::sort. Source: http://en.wikipedia.org/wiki/Quicksort

You left out the previous paragraph, which explains why Carmack feels the need to partner with a Titan, rather than go at it alone.

Not sure that I agree this move was necessary at this point in time, but I definitely see his fear of the potential consequences of refusing to strike such a partnership.

Poor artists outsource.

I'm not saying you shouldn't use arrays altogether, just that you shouldn't use them when you have uniqueness & no order.

For example, consider the posts.comments.users relationship. Here "posts" is the primary document (and let's say a collection), "comments" and "users" are related documents. The same user may have commented in multiple posts within a single response, so which `position` attribute would you use in the related "users" document? The answer is you don't, you can't, because the user appears in different positions in different posts. The order of comments is defined by the "post" document's "comments" array. Each comment document contains a user id. You look up the user from the unique "users" map by that id. There is no order that makes sense for related documents, since by nature of being related documents their entries may appear in different places/positions in the parent document, where they are already referred to from ordered collections (e.g. arrays of ids) or singular fields.

Hope that clears it all up :)

That's a fair point, but using arrays only where ordering matters adds nice semantics that can be used by a general-purpose client. Using a map for related documents makes it explicit that document entries are unique and unordered (it's implicitly assumed to be true in OOP's case).

In addition, you'll find that you're using an array at the toplevel only for the primary document when it is a collection, and for nested collections within documents (such as comment ids). Semantics that general-purpose clients can make use of.

I agree with you. "OP" was referring to your suggestion. I edited my pervious comment to clarify.

The related documents are indexed by id from the primary document, so ordering doesn't matter, and it makes sense to use a format suggested by calebio, as it's both more efficient and terse. However, the primary document and other nested entities which require ordering should return an array of objects.

Edit: clarification

Work on supporting some provisional C++1y features is already underway: http://clang.llvm.org/cxx_status.html

Well, at least they open sourced the parts of the code they used ;)

I recommend checking out Qt Creator. It's cross platform, has code completion, live syntax checking, supports regular Makefiles, C++11, and much more.

Plus, if you're looking to build a cross platform GUI app, Qt is a great toolkit, and Qt Creator (as the name suggests) supports drag&drop UI building, QML etc.

Luma applies stabilization on playback. We keep all the pixels we get from the camera, even when you upload to our cloud service. As we improve our algorithms your existing videos will continue to improve with time. There's much more that we can do to help you create stunning videos. We're just getting started :)

Luma's cinematic stabilization performs much better than Nokia's optical stabilizer in daylight. As sensors get better (more light sensitive, higher resolution), the advantages of optical stabilizers will diminish even further and eventually disappear. (Disclosure: I cofounded Luma).

(Cofounder here.) Ours is better: http://luma.io/v/CJC

You can think of AVFoundation's as dampening handshake. We retarget the motion to be along the smoothest path possible. So we can often completely eliminate handshake. Luma supports both native and cinematic stabilization modes.

Here you go: http://luma.io/v/CIt (thanks to cosbynator for letting me make this)

We developed this in-house. We use additional sensor data and fairly advanced optimization algorithms to produce these videos (all done in real-time on your mobile phone!) Due to the lack of sensor data, and subpar camera models, you won't get results of this quality with desktop video editing software like Final Cut.

It's on our todo list :)

(Cofounder here.) That's our motion retargeting algorithm at work. It'll fit the smoothest motion to your recording. In this case a constant panning motion does the trick. You can get perfectly stationary, motorized-tripod-like panning shots, and dollies with Luma without any equipment other than your hands.

I've dropped all iPhones I've ever owned. Never shattered glass yet, but it's only a matter of time.

Doesn't list your email in your profile. Ping me at alex (at) luma.io

Yes, if 1) VP9/Daala are significantly better, and 2) they don't come out much later than h265. VP8 failed on both accounts compared to h264. To see why, read: http://x264dev.multimedia.cx/archives/377 (not an unbiased source admittedly, but the technical analysis is accurate).

Fixed. Thanks!

Sadly, the best compression techniques are fairly obvious and have been patented. The economics of this space have always favored better codecs over licensing concerns. Savings in bandwidth often negate the cost benefits of a free codec. High end video recording/editing tools used by most content creators are expensive, such that a codec license amounts to only a small fraction of the cost. Pirates care about high quality and fast downloads. They don't care about licensing costs for obvious reasons.

H.265 merely standardizes on a set of the best known compression techniques that meet certain compression vs processing constraints. It just so happens that most of these techniques are patented. Which in turn is why MPEG-LA exists. This will continue to be true going forward. The only way to make a free codec viable is to fix the patent system. I'm all for patent reform, but as I mentioned elsewhere, I'd much rather discuss h265 tech here, and leave the patent debate for the numerous posts we're sure to continue to see on HN.

We remove handshake by computing optimally smooth camera paths. Some example videos shot on a handheld iPhone using our app: http://luma.io/v/Brl http://luma.io/v/BtN http://luma.io/v/Brm

More info here: http://luma.io

No different than h264 in that regard. I'd rather we discuss the technical merits of this technology than have another patent debate. Not that I wouldn't agree, just that if you want to talk patent reform, it might be better suited to do so in a dedicated HN posting.

As far as encoding technology goes, this is pretty exciting. Looking forward to the first wave of 4K TVs & cell phone cameras hitting the market.

(Disclaimer: I'm the cofounder of a startup specializing in high quality cellphone videos)

Second that. I was pretty upset that I couldn't make it to the last one.

Also, on the tricks front: I was proxying UITableViews to override their layout before UICollectionViews were cool :)

This isn't a problem. Just make it work the way shared folders already do. When I join a team, create a folder with the team's name in the Dropbox root, and optionally (or in case of conflicts) let me also choose the folder name.