For Android, one Surface == one Window. So each window has its own dedicated bitmap that it draws in to, and the surface flinger composites the current contents of those buffers to the frame buffer each time the display changes to create the final result. It uses page flipping with the frame buffer so that you don't see any flicker while it is compositing, and it uses double buffering of each surface so that it always has a "good" bitmap for a surface that it can composit without waiting for the application.
On Sat, Jan 31, 2009 at 4:54 AM, gan <[email protected]> wrote: > > Hi: > > I add some log in SurfaceFlinger and according to it I think(Thanks > for correct me if something is wrong): > a)Java "SurfaceSession" would create(native side) a > "mSharedHeapAllocator" for each Surface client, > This is done at native Client::Client in the process "system_server" > b)Java "Surface" would access(native side) "mSharedHeapAllocator" to > allocate 2 buffer > for each Normal Surface(not Buffer,Dim or Blur) client. > This is done at native Client::createAllocator in the process > "system_server"'s another threads. > > My question is: > 1) what is the relationship of these buffers created in b) with the > buffers swapped by EGLDisplaySurface::swapBuffers, > 2) what is the relationship of these buffers with "/dev/graphics/fbX" > or "/dev/fbX", > > Thanks&BstRgds > gan > > > > > > > -- 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. 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 -~----------~----~----~----~------~----~------~--~---
