http://groups.google.com.tw/group/android-platform/browse_thread/thread/f2c5ec9b77b9862e
> I want to change the animations for starting and stopping activities.
> Now I have some questions regarding the animation framework used
> inside the WindowManagerService.
> Just changing the animation’s xml files (activity_open_enter.xml etc.)
> is not enough for our UI, so I have to understand the inner working of
> the framework. Here is what I got so far and some questions:
> The methods refer to class WindowManagerService.I would suggest adding a new kind of animation object instead of mucking
with the window manager, but…
> The applyAnimationLocked chooses the desired animation.
> During a performLayoutAndPlaceSurfacesLocked pass the
> stepAnimationLocked method starts the chosen animation
> (Transformation.getTransformation -> applyTransformation).Yep.
> What are animation layers and why are they needed? What does the
> updateLayers method of class AppWindowToken do?Some animations need to temporarily modify the Z-order of their windows to
achieve a certain effect (see for example the sliding animations). This is
tied to the specific transitions between app window tokens, where exit and
enter animations are running in conjunction at the same time.
> What is the purpose of WindowState.computeShownFrameLocked? Is it
> involved in the animation process?It just computes the real frame of the window. It is involved in animations
because animations move windows.
> The SurfaceFlinger is not involved in animations, right? It just
> composes the surfaces that are produced by the ViewRoot objects.Well.. it doesn’t decide what the animations are, but window animations are
by definition moving surfaces around, and the surface flinger composites
surfaces, so it is required to actually show the animation.
> It seems that the animations are NOT hardware accelerated since they
> are implemented using the Skia framework, right?No true, the window manager only deals in surface transformations, which are
composited by surface flinger, which is hardware accelerated (if you have
implemented the acceleration in your device, which you really want to do).
> One more question: Does that mean that the Surface Flinger does not
> only get the Surface (Layer) from ViewRoot but also a transformation
> matrix from the WindowManagerService that is used during the
> compositing of that surface (layer)? So this transformation matrix is
> used by the OpenGL compositing?Yes the surface buffer is given to the app for drawing in to, and the window
manager controls its position, size, and transformation. The surface
flinger uses these two things to composite the screen.
> What is an AppStartingWindow? It is used by some apps via
> PhoneWindowManager.addStartingWindow.It is not used by apps. It is used by the system to show a preview of the
application that is being launched, to make the UI more responsive.
ok, now I understood what is going on in the WindowManagerService
regarding the animations.
WindowManagerService.WindowState.computeShownFrameLocked computes the
transformation matrix for animations that is later passed to
LayerBase::setMatrix by WMS.performLayoutAndPlaceSurfacesLockedInner.
WMS.performLayoutAndPlaceSurfacesLockedInner drives the animation by
triggering itself every 60Hz as long as stepAnimationLocked returns
true.
Now comes the part inside of the SurfaceFlinger that I don’t really
understand fully.
After having the transformation matrix in LayerBase the SurfaceFlinger
triggers LayerBase::validateVisibility at some point in time.
LayerBase::validateVisibility computes some transformation and the
bounds. Later LayerBase::drawWithOpenGL is called to draw the layer.
But where is the transformation passed to some OpenGL API? I do not
see anything like this here. Or is the translation and scaling done by
setPosition, setSize or implicitly by mapping to layer (texture) to
the display with mTransformedBounds?
I tried to do a rotation when opening an activity but I do not see
that rotation. Is this simply not possible right now because the
SurfaceFlinger does not directly use the transformation matrix
calculated by WindowManagerService?
So can the SurfaceFlinger only do translation and scale animations
with the help of setPosition, setSize and mTransformedBounds but no
rotations?
Or have I missed something?
Sorry I can’t help you with the internals of the surface flinger. I do
trust that the transformation is propagated to OpenGL when it draws the
surface. :)
I did a stupid mistake, doh!
Also rotation surfaces works great!
LayerBase::validateVisibility does the transformation which is
triggered by SurfaceFlinger::threadLoop.
Later SurfaceFlinger::threadLoop triggers LayerBase::drawWithOpenGL
which uses the calculated mVertices in the call to glVertexPointer.
Doh, doh, doh :-) end