[Cogl] Creating sliced textures from data and framebuffer

[Tobias Hansen]

Am 22.01.2012 13:29, schrieb Robert Bragg:
>> So if I want to use Cogl only for texture slicing, would it work if I
>> just create CoglMetaTextures instead of GL textures, and do drawing in
>> the callback from cogl_meta_texture_foreach_in_region? (I don't need
>> repeated texturing, every texture is drawn just once.)
>>
>> cogl_texture_get_gl_texture() is in cogl-texture.h, but not in the
>> reference manual.
> 
> cogl_texture_get_gl_texture() is exposed in the Cogl 1.x reference
> manual but currently not in the 2.x manual. So far I've avoided
> exposing this since there aren't many safe uses for accessing the GL
> texture directly. If we do expose something like this for the 2.0 api
> it should probably have a tweaked name like
> cogl_gl_texture_get_handle() to be consistent with other
> platform/feature specific apis.
> 
> In general its quite tricky to mix and match use of Cogl and direct
> use of GL because you risk modifying something about the GL state that
> Cogl caches. Actually one of the reasons we have Cogl in the first
> place is because its so awkward for multiple independent components to
> use one OpenGL context without stepping on each others toes.
> 
> Recently Tomeu Vizoso working at Collabora has been investigating
> adding much improved support in Cogl for intermixing GLES2 and Cogl
> usage, which can be seen in the wip/gles2-context branch. We still
> have some work to do here before we can land this in master but
> conceptually I think something like this is the right way to go for us
> to reliably be able to handle applications wanting to use both APIs.
> At least to start with this branch will force two separate GL contexts
> but the API will allow us to avoid explicitly separate contexts as an
> optimization later.
> 
> The only way currently that Cogl supports intermixing GL usage is via
> cogl_begin_gl() and cogl_end_gl() but they have very strict
> requirements that the GL state must be restored exactly as it was
> found which makes them rather awkward to use for any complex use of
> GL. The only user of this api we know of currently is gnome-shell, and
> they just use it to create GL_TEXTURE_RECTANGLE textures because Cogl
> didn't used to have native support for rectangle textures, but they
> don't do any drawing with GL.
> 
> Something we could potentially add quite easily would be some api to
> query the EGLContext we create internally for Cogl. In conjunction
> with cogl_egl_renderer_get_egl_display() that would give enough
> information to let you create your own EGL context manually with the
> Cogl context listed as a shared_context so that texture objects made
> by Cogl could be shared with your own GLES rendering context.
> 
> The disadvantage compared to the approach we are aiming for with
> Tomeu's branch is that you still have to manually use EGL and also it
> can't support GLES2 on top of a GL driver but since you must already
> be dealing with EGL manually anyway that may be fine for you.


Sounds like sharing one EGLcontext would be the best thing for me. Yes
right now I'm creating an EGL context myself. What are the implications
of having two GL contexts like int the wip/gles2-context branch?

I hope that confusing Cogls cached state is not a terribly big problem
if I only use it for data in, textures out.

Another thing I need is multitexturing... Does Cogl support that in any
form? (I still have to consider switching to Cogl entirely, if it can do
everything I need. Would be nice, but quite much work.)

Otherwise... Do you see another reasonable way to use multiple sliced
textures for multitexturing than a cogl_meta_texture_foreach_in_region
variant that accepts multiple CoglMetaTextures and sets of texture
coordinates and iterates over regions that don't cross borders of any of
the native GL textures involved?

Best regards,
Tobias