Puttin' on the GL(itz)

BogDan bog_dan_ro at yahoo.com
Tue May 15 17:58:50 UTC 2012



[,,]


>>  > 
>>  > So yes, you don't need a EGLSurface!
>>  > ... all you need is a EGL/GL resource you can map a EGLImage around
>>  >      ... a texture is the simplest one. pixelbuffer or FBO are other
>>  > examples.
>>  Ok, but how do I bind a context to the current rendering thread and to the
>> 
>>  EGLImage, I suppose I can not use eglMakeCurrent right ?
> 
> Hmm. why not? ... or better: I'm not sure I got your problem :)
> 

No, believe you didn't :). Please forget OpenMAX for a moment.
Let's say you have an application with more than one top level widget 

which needs also OpenGL ( for a QGLWidget ), it will need a context and 

surface to paint onto, because the only window EGLSurface can not be used, 

where QGLWidget will paint onto ? I think it will need another EGLSurface, right ?



> 
> So I got something like that in mind:
> 1. a multimediakit object gets a "playThisFile" call (not sure what it 
> 
> actually named)
> (for now I assume it's happen in the UI/main thread)
> 2, maybe: QPlatformGLContext::makeCurrent()
> 3. he creates a texture, wrappes a EGLImage around it
> 4. he hands the EGLImage over to openmax al
> 5. openmax al takes it and startes rendering into this EGLImage/texture in the 
> background*****
> 6. multimediakit returns from "playThisFile"
> 
> 7. some when later:
> the multimediakit object has a paint() function which is called in the main 
> thread, which does  glDrawArrays  (draws a rect with the video-texture on it)
> 
> 
> 
> If it's the other way around: OpenMAX AL gives you an EGlImage 
> (I doubt that!...I would bet my money on the first case)
> 
> ... it think you just need to call eglMakeCurrent and use:
> http://www.khronos.org/registry/gles/extensions/OES/OES_EGL_image.txt
> (again you're in the main thread)
> 
> That shouldn't be a problem ... I think :D
> 
> 
> Again I'm very unsure how openmax al actually works, API vice!! 
> I've never looked into it.
> 
> 
> 
> If you're in another thread ... that could get a bit more complicated, but 
> there are things for that as well (context sharing / shared context)
> 
> 
> *****
> All my statements are based on the idea that openmax al is doing his work 
> somehow in the background!!
> This is the case for openmax il ... they have callbacks and all kinds of crazy 
> and ugly stuff to enable that.
> ... I would be surprised if they gave up such a nice feature (background 
> rendering) for a high level API.
> 
> 
[...]


More information about the Necessitas-devel mailing list