I'm not 100% sure that z-order is the issue here, I primarily wanted to confirm that my understanding of this system is correct and also to try to understand what "sequence" refers to in this context. To answer your question anyway... (I've inherited this bug from someone else and I'm not too familiar with Android development, so please excuse me if this is unclear)
We have a custom library that does widget rendering using Skia to draw our final bitmaps onto the screen, we access this low-level stuff via the GraphicsJNI::GetNative* functions. In certain cases, like the notification bar being pulled down or the volume dialog popping up, we see that some of our widgets are "obliterated" and disappear from the screen until an invalidation is triggered directly by mouse or keyboard input. Our usage of the skia resources seems to be in line with what Android does with them, and what the web-based docs and Skia code implies is the correct way of using them, so I decided to trace the problem upwards into SurfaceFlinger instead of downwards into Skia. I've not confirmed that z-fighting is the issue yet, but it's one of the possibilities that I'm pursuing. I noticed in SurfaceFlinger.h that "sequence" seems to be something of a tie-breaker in the case where layer z-values are equal and curiosity made me investigate what "sequence" means and how it works. Even if it's not what I'm looking for I'd like to find out what it's used for and why it's seemingly declared to be a UID but then made non-unique by modification. You may be right that I'm barking up the wrong tree here, so if something in my vague description of my even vaguer understanding of the problem rings any bells please toss me a bone, even if it's a small one :) On Tuesday, 19 June 2012 22:16:33 UTC-4, Dianne Hackborn wrote: > > You shouldn't have surfaces with the same Z order value. The window > manager makes sure of this. What are you doing to get in a situation where > two surfaces get assigned the same Z order? > > On Tue, Jun 19, 2012 at 10:23 AM, Inan Top <[email protected]> wrote: > >> Hi all, >> >> I've been trying to track down a rendering issue in our application, >> and I'm considering z-fighting as a potential root cause. I've tracked >> the z-ordering logic from SurfaceFlinger.h down to LayerBase.cpp. Here >> are my findings, please correct me if I'm wrong: >> >> SurfaceFlinger.h composites the layers in z-order, which is determined >> by the ViewParent classes. In the case that two elements have the same >> z-value their *sequence* is used as the comparison for ordering >> purposes. Sequence appears to be an attempt at a UID for each >> LayerBase instance. >> >> Sequence is initialized to an incremented sSequence, which is a static >> member of the LayerBase class. This guarantees that no two instances >> of LayerBase begin with the same sequence. So far so good. >> >> However each of the transformation operations within LayerBase, i.e. >> setAlpha, setPosition, etc. increment this sequence value. This means >> (as far as I understand) that I can create two LayerBase objects A and >> B, with sequence 1 and 2 respectively to begin with, and then do some >> sort of transformation onto A causing it to increment its sequence to >> 2 also. >> >> This could potentially result in a situation where A and B share the >> same z-order AND the same sequence, in which case ordering is not sane >> and z-fighting issues can occur. >> >> Am I correct in that assessment or am I completely misunderstanding >> this system? I'm completely new to Android so don't worry about >> hurting my feelings if I'm completely wrong. >> >> -- >> unsubscribe: [email protected] >> website: http://groups.google.com/group/android-porting >> > > > > -- > Dianne Hackborn > Android framework engineer > [email protected] > > Note: please don't send private questions to me, as I don't have time to > provide private support, and so won't reply to such e-mails. All such > questions should be posted on public forums, where I and others can see and > answer them. > > -- unsubscribe: [email protected] website: http://groups.google.com/group/android-porting
