201 reputation
18
bio website
location
age
visits member for 2 years, 2 months
seen Jul 28 at 14:46

I used to work as a software engineer for Google, working on Android (2005-2014). I spent five years working on Dalvik (2006-2011), and two on system-level graphics (2012-2014).

I've written a few documents for Android developers that now appear on the official site:

I also wrote Grafika and run bigflake.com.


Sep
24
awarded  Autobiographer
Jul
28
comment Java Buffers and OpenGL ES 2.0 (Android)
cf. "texture swizzling" and related topics. The format of the image loaded from disk may be suboptimal for access by the hardware, so being able to rewrite the texture can provide significant performance improvements. So not only would avoiding the copy be a restrictive API design for non-UMA systems, it could also cause a performance hit.
Jul
28
awarded  Commentator
Apr
15
awarded  Editor
Apr
15
revised Android OpenGL ES RENDERMODE_WHEN_DIRTY implementation
added missing quote
Apr
15
awarded  Yearling
Jun
18
comment Android Loop : Draw Loop : How to pull off smooth FPS?
The easiest way to check for GC-induced problems is to watch the logcat output. If you see a lot of GC messages from Dalvik, you need to find a way to reduce object churn. (These are logged at "debug" level.)
Jun
17
awarded  Caucus
May
18
awarded  Analytical
May
18
awarded  Informed
May
16
answered Android game loop's effect on cpu/battery usage - unexpected results
May
16
answered Android Loop : Draw Loop : How to pull off smooth FPS?
May
3
comment Formula for converting ratio of current device to target device
You can see it in a GLSurfaceView implementation here; it's essentially the same computation, but not as concise: code.google.com/p/android-breakout/source/browse/src/com/…
Apr
24
comment Where to run logic update in openGL ES?
Example of a game that uses this structure: code.google.com/p/android-breakout . Some discussion about the one-vs-two thread approaches is in the supporting docs, and also here: stackoverflow.com/questions/14077403/…
Feb
1
comment Limited Screen Switching Count Memory Issue
On the Dalvik VM side, garbage is discarded when necessary. Manually invoking the GC isn't necessary for correctness. The only time it's really useful to do so is to control the timing of GC pauses.
Jan
30
comment Limited Screen Switching Count Memory Issue
The "force close" dialog is generally put up by the failing app itself, when a Java-language exception lands in the global default uncaught exception handler. In the event of a native crash, that's not possible and the app just disappears, but you will get a full crash trace in "logcat". Watch the logcat output as it scrolls by, and capture just the part that begins when you start the last screen transition before the crash and stops after the process is dead. The native stack backtrace may give you some idea of where things are going wrong.
Jan
29
comment Limited Screen Switching Count Memory Issue
Your logcat output appears incomplete. For example, in the first one, it shows the tail end of an exception in process 11707, then some GC logs from 12963. The second shows some GC logs from 13772. None of the GC messages indicate any sort of failure or problem -- those are normal messages from a Dalvik VM. There is no indication that you're running out of memory in the logs. The native crash in the 3rd set of output is interesting but you didn't include any of the registers or call stack.
Jan
23
answered Android OpenGL ES RENDERMODE_WHEN_DIRTY implementation
Jan
23
comment How do I dispose of OpenGL resources cleanly on Android?
If you're using GLSurfaceView, you don't really need to do anything -- it does it all for you. It actually discards everything whenever the activity is paused, which is good to know when figuring out where to allocate stuff, i.e. you want to create all your GL programs in onSurfaceCreated(). See code.google.com/p/android-breakout for an example.
Jan
8
awarded  Teacher