android surface flinger

1.libhgl.so and libagl.so are loaded into sf.
2.every activity can have one or more surfaces
3.these surfaces may be of different types
4.some of these surfaces will use hw accel some are software
5.before pushing to fb0 surfaces will be composited

6.a combination of libEGL.so and libGLESv2.so will route gl calls to libhgl or libagl.

7.can an activity have hw surface and sw surface parallelly.can these two surfaces be composited together into fb0.
8.maybe both libhgl and libagl will be loaded parallelly and activity will decide if its using libagl or libhgl.
libagl and libhgl calls have one to one correspondence,so partial use of libagl and libhgl is not possible.

8.hardware codec support can be given in android by 2 ways.within a framework or outside
1.within framework --- get the working codec driver in openmax,modify it
take a template code from framework node,change it to work like above
this will work with standard android player.openmax can be adapted to fit into android framework
2.implement a player,within the player code interface with sf and af
if gstreamer already has the codec integrated,use it with a new player engine.

9.in a accelerated codec scenario application pushes a frame desciptor to driver to hardware,descriptor has source buff addr and destination buff addr.on decoding the frame the
frame is pushed to destination buffer.from here application takes it and send to fb0.

10.video acceleration === hardware codec
display acceleration === hadware gl(compositing)
audio accel ===
audio mixing === hadware level