Puttin' on the GL(itz)

[Thomas Senyk]

On Tuesday, May 15, 2012 08:40:25 AM ext BogDan wrote:
> ----- Original Message -----
> 
> > From: Thomas Senyk <thomas.senyk at nokia.com>
> > To: BogDan <bog_dan_ro at yahoo.com>; ext BogDan Vatra
> > <taipanromania at gmail.com> Cc: "necessitas-devel at kde.org"
> > <necessitas-devel at kde.org>
> > Sent: Tuesday, May 15, 2012 5:47 PM
> > Subject: Re: Puttin' on the GL(itz)
> > 
...
> > 
> > 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 :)


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.


> 
> > And EGLImage is what OpenMAX AL deals with
> > (actually I don't know that, but OpenMAX IL(!) does, so I suspect OpenMAX
> > AL
> > 
> > does as well)
> > 
> > 
> > but again: any copy (within the gpu or not)  should not be necessary!
> > 
> >>  Many thanks for your feedback !
> >>
> >>  >>  Any comments, suggestions and *help* will be very appreciated.
> >>  >> 
> >>  >>  Cheers,
> >>  >>  BogDan.
> >>  >> 
> >>  >> 
> >>  >>  [1]
> >>
> > http://mail.kde.org/pipermail/necessitas-devel/2012-May/000900.html
> > 
> >>  >>  [2]
> >>
> > http://code.google.com/p/android-lighthouse/issues/detail?id=4#c28
> > 
> >>  >>  [3]
> >>
> > http://code.google.com/p/android-lighthouse/issues/detail?id=4#c23
> > 
> >>  >>  [4]
> >>  >> 
> >>
> > http://groups.google.com/group/android-developers/browse_thread/thread/8
> > 
> >>  >>  40e
> >>  >>  4e20faab5c31 ,
> >>  >> 
> >>
> > https://developer.qualcomm.com/forum/qdevnet-forums/mobile-gaming-graphi
> > 
> >>  >>  cs-
> >>  >>  optimization-adreno/1969
> >>
> > _______________________________________________
> > 
> >>  >>  Necessitas-devel mailing list
> >>  >>  Necessitas-devel at kde.org
> >>  >>  https://mail.kde.org/mailman/listinfo/necessitas-devel
> >>  >
> >>  > _______________________________________________
> >>  > Necessitas-devel mailing list
> >>  > Necessitas-devel at kde.org
> >>  > https://mail.kde.org/mailman/listinfo/necessitas-devel