android flingers

1.learning has a wavy pattern
upper crest starts with abstraction
lower crest is concrete

upper(starts with some names)---lower(processes,dlls)--upper(associations)----lower(interface functions)---upper(categories,channels)----lower(context,binary modules)

mediaserver-->omx-->codec

omx buffer is sent with input buffer and offset,and returns output buffer

audio
======
af-->libaudio.so
af-->libaudio.so (alsa)

video
=====
uses EGL as interface
sf-->libhgl.so
sf-->libagl.so

codec
=====
uses OMX as interface
mediaserver-->omxnnn.so

pixelflinger/libhgl for an activity makes all defined surfaces and passes to sf
sf layers and composes them and renders using fb0

libhgl has inputs and outputs,inputs are surface data and surfaces
output is composed buffer
if this output buffer memory can be fed to fb0 the its efficient
but if it cannot be then a memcpy is required before pushing to fb0

eglbuffertypes
native
pushbuffer
fb0

All these are parallel
cpu
gpu multiple layer composer
display renderer hw
codec hw

an activity indirectly calls the eglswapbuffer,this will send data to gpu to compose,till its
completed activity waits,then the composed buffer is given to fb0

copybit.so can export any /dev/nnn,it has to define interface copybit.h,its used for 2d blit

android code assumes gpu/display to be same hw device /dev/graphics/fb0, different ioctls for operations

maybe before writing to gpu,clipping and other operations are done on figures ,a
nd later one by is rendered