Working on the new UI for our upcoming 1.1 release of Wheel of Yum I ran into a bug in how Android renders the alpha channel data of a PNG file laid out above a SurfaceView.
Essentially, we have a custom SurfaceView that, amongst other wonderful things, paints a nice background for our application. For our 1.1 release we decided to add some gradated, semi-opaque buttons over said background. When I laid these buttons out on top of the main SurfaceView they were semi-transparent, however something in Android was causing them to render with a flat grey matte color, ignoring the color gradient applied to the original image. Further, this seemed to cause an odd flicker of the main Android toolbar when touching the screen over the SurfaceView and also slowed down the animation occurring in our SurfaceView (rendered on a separate, non-ui thread).
So, laying out a PNG with lot’s of alpha going on over our SurfaceView was causing:
– incorrect rendering of the PNG
– interference with the Android toolbar
– interference with the rendering thread of the underlying SurfaceView andor the messages it pumps into the UI thread
I’m sure there’s a perfectly good reason for this behavior, but not having time this weekend to dig around Android’s source, I simply implemented a workaround. In our case, I broke up the background into two pieces: an “inner” background that exists near and underneath our SurfaceView’s animation, and an “outer” background that constitutes the trim of our application (with the inner background cut out of it). The inner background is still being painted by the SurfaceView just as before. The outer, however, is completely opaque and laid out on top of the SurfaceView. Our new buttons are then laid out on top of the outer background.
Problem solved … in a hacky sorta way =;)
*I’ll try to update this post with some screen shots at a later date.