[HTC EVO 3D] agrabren:
Can't speak for battery life at the moment, I'm not having an issue, but I haven't had a chance to update lately.

Nightly builds have been restarted from the Thanksgiving Holiday.

Chrome Issue: This is 99.9% likely related to overlays. SurfaceFlinger doesn't seem to have an issue, or we'd see corruption all over the place. Instead, we only see it in select apps. OpenGL doesn't appear very affected either, which only leaves two areas... Tile Renderer and Overlays. The rapid flipping back and forth means that page flipping is having an issue, but even with page flipping off, it shows this issue. That means the back buffer, even if not in graphics memory, is corrupted. I have disabled the tile renderer, and the problem gets worse. I know a lot of people have said that its broken on other devices too, it's a bug in Chromium, etc... It doesn't matter, if it's related to overlays, we control a good portion of the overlay stack. And we are using the latest and greatest QCOM JB graphics drivers. So do I believe this can be fixed? Yes. In all my observations of the issue, its always corrupted only on the Y axis, meaning the screen doesn't have garbage randomly placed, it's all stacked on top of each other. If it were truly incompatible, we would be seeing garbage, because the chance of it landing not only on a 4-byte pixel boundary, but always on a line boundary are too low to be counted as probable cause. So we're getting the Y offset wrong on the back buffer (likely we're seeing the screen size wrong, and therefore, the blit for the backbuffer is partially on the front buffer). This would explain the strobing we see. Also, we see issues in other apps that use overlays (like video playback), so focus is definitely here.

Codec Issue: Everyone keeps saying the fix is in the media_codecs. It's not. I fixed the media codecs. And by fixed, I mean, we support all the proper hardware decoding we're supposed to, not disabled everything into software rendering. We'll never get to 3D support if we can't use the hardware decoders, they're required for the pipeline to work. That's why I'm not removing all the codecs. Instead, I need to find out why certain codecs are crashing mediaserver and fix the bugs preventing the codecs from running properly.

Audio Issue: This is likely the first and easiest thing I want to tackle. Whenever we open an audio stream, we should apply the volume. Some devices don't require this, as the audio hardware "remembers" the volume correctly (or more likely, doesn't close output streams). We need to reapply volume after initializing a new audio stream, so we don't have to tweak the volume.

Bluetooth: I know that it's still finicky, and I think I know a solid solution. But it's honestly not my top priority.

Battery: I never focus on battery life (except if a wakelock is stuck) until other features are working. It's a polish feature. It's required, but it's not changing the behavior of anything, just ensuring it does things the right way. Right now, without full graphics stack, fixing the power consumption of the display on is pointless. Part of the saving is by using the best methods of display rendering, which we don't have the full selection available to us yet. Do it right once, not twice wrong.

3D: Yes, it can be done. I understand why HTC is dropping support for our phones (from what I've read, they won't continue OS revs for it). Google does not have a solid 3D video and photo engine built in. So every time Google changes how Stagefright works, HTC has to go back to the beginning and re-invent the wheel. We were very close on CM9, and with CM10, it's a mess again. This time, I'm planning to do it right, so it can be bolted into later versions of the OS, and not just redone every time.