SurfaceFlinger doesn't touch these. It gives them to applications to applications for them to draw in to, and passes them to the HAL (or OpenGL) to composite to the screen. And whether you can touch it depends on your hardware. For example, if the application has asked for a surface it will do OpenGL rendering in then the surface buffer needs to be something the hardware can render in to, so you don't know what it may be. Or if it is for doing a camera preview, it may be some kind of YUV surface that the camera hardware pushes data to.
On Wed, May 25, 2011 at 11:45 AM, drjunior <[email protected]> wrote: > > Thanks for your help, but I'm still quite confused! My big question > is: can I access the bitmap that the NativeBuffer supposedly should > have? Or it's only accessible on the hardware side?(I don't have > access to the proprietary source of the driver, so I would like to use > some existent function implemented by the driver that returns the > bitmap). > > Is this possible? > > On May 25, 5:26 pm, Dianne Hackborn <[email protected]> wrote: > > The surface flinger doesn't draw the buffer, the application does. > > > > > > > > > > > > > > > > > > > > On Wed, May 25, 2011 at 7:57 AM, drjunior <[email protected]> > wrote: > > > Version 2.3.3. > > > > > int FramebufferNativeWindow::queueBuffer(ANativeWindow* window, > > > android_native_buffer_t* buffer) > > > { > > > FramebufferNativeWindow* self = getSelf(window); > > > Mutex::Autolock _l(self->mutex); > > > framebuffer_device_t* fb = self->fbDev; > > > buffer_handle_t handle = static_cast<NativeBuffer*>(buffer)- > > > >handle; > > > > > const int index = self->mCurrentBufferIndex; > > > GraphicLog& logger(GraphicLog::getInstance()); > > > logger.log(GraphicLog::SF_FB_POST_BEFORE, index); > > > > > int res = fb->post(fb, handle); > > > > > logger.log(GraphicLog::SF_FB_POST_AFTER, index); > > > > > self->front = static_cast<NativeBuffer*>(buffer); > > > self->mNumFreeBuffers++; > > > self->mCondition.broadcast(); > > > return res; > > > } > > > > > There are a lot of "buffers"here! (framebuffer_device_t* fb, self- > > > >front, handle..) > > > I can't see where is the "fill" of the buffers with some content. I > > > would like to find some kind of memcpy or something related with that. > > > > > On May 25, 2:38 pm, extrapedestrian <[email protected]> > > > wrote: > > > > What version of Android? > > > > > > in Froyo 2.2 there is FramebufferNativeWindow::queueBuffer and > > > > FramebufferNativeWindow::dequeueBuffer > > > > called in SwapBuffers before flip(). > > > > > > I think you can access native buffer there. > > > > > > On May 24, 8:28 pm, drjunior <[email protected]> wrote: > > > > > > > I've been digging around SurfaceFlinger service implementation > trying > > > > > to understand how it is implemented. I started studying the / > > > > > frameworks/base/services/surfaceflinger/SurfaceFlinger.cpp file and > > > > > the methods handleRepaint() and composeSurfaces(). What I would > like > > > > > to know is how I can access the buffers(if I can do that) that has > the > > > > > bitmap of the rectangle changed. I already found where the flip is > > > > > done( /frameworks/base/services/surfaceflinger/DisplayHardware/ > > > > > DisplayHardware.cpp::flip() ) and here I could confirm the size of > the > > > > > rectangle(within the entire surface) that had changes. Now, I would > > > > > like to access the buffer of the surface that has the content with > the > > > > > bitmap changed. There are a lot of files to search and without > > > > > documentation it's really difficult to find how to do that. > > > > > > > Thank you for your help. > > > > > -- > > > 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 > -- 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
