Tuesday, May 10, 2011

Google I/O

On the train back to Philadelphia from the Google I/O Extended
conference in NYC. Props to Google NYC for hosting us for the streaming session and showing us around.

The Google NYC offices in the Port Authority building in Chelsea are
neat. I'm a sucker for the converted warehouse look, so it appealed to
me straight away. They still had alot of hustle and bustle getting the
space put together and remodeled, and expanded into new parts of the
building. One architectural feature I found funny was that their main
common spaces/auditoriums/rec rooms were located in the loading docks
for their (still working) truck elevators.

There was a big focus on Android graphics and HTML5 capabilities at the
sessions they showed us, which was really encouraging. I'm curious
about the capabilities of their RenderScript. It seems like the
documentation and examples are rather sparse, but it is some kind of
OpenGL wrapper + CUDA approximation that allows for high-performance
rendering or compute (simulation, encoding/decoding) that can run on
either the GPU or CPU as is appropriate.

Rather than Dalvik, then use an LLVM intermediate representation that is
targeted to the CPU's or GPU's available at run-time, which reminds me
of the Apple OpenGL emulation system using LLVM. This, plus the fact
that anyone that can is using LLVM as their back-end, really makes me
think I should pick it up. One nice RenderScript feature is that their
compiler automatically generates Java .class files for you that make
binding from your Android app quite painless.

I'm a little sad that Google chose to rebuild this stack rather than
support OpenCL and build a similar abstraction on top of it; I'd be
curious to hear the rationale. I don't think RenderScript will find for
larger software systems (serious physics engines, math libraries)
without more of a cross-platform nature; it's a pity they couldn't have
leveraged such that already exists for OpenCL, which promises alot of
the same benefit of heterogenous platform support.

Another good talk I saw was the Android ProTips. He actually ran over
alot of the same points on watching battery, connectivity, and docking
state that were covered in CIS542, Embedded Systems. He also showed
some really nice tricks using PassiveLocationProvider to take advantage
of Location updates that other apps requested to keep yourself

Really, the number of system events that can be captured
and handled using Intents is really impressive, and one of my favorite
features of Android as a platform. I thought I was really clever when
we used them to capture document opening for SEASPrint, but apparently
that's just best practice.

Another neat Android library I learned about today in passing is
FileObserver, which is a low-level and powerful utility that I wasn't
really expecting. It's just a wrapper for the Linux inotify library,
but it let's you do neat things like the shader preview tool I talked
about last fall.

It's probably not that great a tool for general IPC since Android
applications view of the filesystem is really restricted, and there are
already higher-level tools like Intents to pass media and messages
between applications, but I can see it being used in content development
to push out asset changes to the phone during development for
interactive preview. Noone likes reinstalling an app to see changes.

At the reception after Google I/O, I bumped into one of Google's engineers for
Google Body, which uses alot of WebGL to render some really high resolution
datasets. I'd been curious about streaming 3d assets into the browser, so he
was really great to talk to.

He had some great points about the tradeoffs in streaming, storing, and
decompressing data when your host code runs in Javascript and your
rendering runs in accelerated OpenGL. This is especially difficult
since in Javascript you can't access custom native libraries for
compression/decompression or asset preparation. One option is using
browser builtin's like Gzip or Deflate content-type encoding to handle
your compression for you.

No comments:

Post a Comment