[Cogl] Creating sliced textures from data and framebuffer

[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.

>
> I didn't find a public API for CoglTexture->set_filters. Did I miss it,
> if not would it make sense for you to add one? Or should I use
> glTexParameter() in the foreach callback?

In Cogl the filter properties are a property of pipeline layers not
the textures themselves (please see
cogl_pipeline_set_layer_filters()). Notably, later versions of OpenGL
have also adopted a similar approach by adding the idea of sampler
objects.

This does highlight a slight problem with the idea of sharing texture
objects between a Cogl context and a GLES2 context though. If you
modify the texture filtering parameters via GL then that could confuse
Cogl's cached state. Since you don't plan to draw with Cogl though
that may not end up being a real problem.


kind regards,
- Robert

>
> Best regards,
> Tobias