Hi, AFAIK, Inside buffer, there is an opaq handle which represent vendor specific object on gpu, GL app directly render into it and there is update buffer api available for non-gl app which updates these buffers again on update of these buffer gpu objects are also updated using a vender specific implementation. Then to display apps output, Surfaceflinger creates eglImage and bind gl_texture_external_oes to draw whatever in these handle to display in on screen.
Upto Jellynean Surfaceflinger used OGLES 1.1 api and Kitkat onwards it uses OGLES 2.0 api. Thank you On Thu, Apr 9, 2015 at 9:12 PM, Eyal Bellisha <[email protected]> wrote: > Hi, > I have a few questions regarding the SurfaceFlinger: > 1) I understand that the app writes to the Surface itself and then moves > the buffer to the SurfaceFlinger (let's assume I am using a Hardware Canvas > or EGL). What is inside the buffer? raw pixels? compiled openGL code? > Can the buffer hold pixels on one transaction and another type of data on > another? > 2) I read somewhere that the SurfaceFlinger writes to the > HWC/DisplayController commands using the OpenGL ES 1.0 API. Is that true? > If it is, then how are version 3.0 commands translated into version 1.0 > commands, and where? > > Thank you > > -- > -- > unsubscribe: [email protected] > website: http://groups.google.com/group/android-porting > > --- > You received this message because you are subscribed to the Google Groups > "android-porting" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- -- unsubscribe: [email protected] website: http://groups.google.com/group/android-porting --- You received this message because you are subscribed to the Google Groups "android-porting" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
