[Cogl] Creating sliced textures from data and framebuffer
robert at sixbynine.org
Sat Jan 21 04:59:12 PST 2012
I accidentally hit reply instead of reply-to-all so forwarding back to
---------- Forwarded message ----------
From: Robert Bragg <robert at sixbynine.org>
Date: Fri, Jan 20, 2012 at 2:43 PM
Subject: Re: [Cogl] Creating sliced textures from data and framebuffer
To: Tobias Hansen <Tobias.Hansen at physik.uni-hamburg.de>
On Fri, Jan 20, 2012 at 11:50 AM, Tobias Hansen
<Tobias.Hansen at physik.uni-hamburg.de> wrote:
> I ported a 2D adventure game engine to OpenGL|ES 2 and to my delight I
> found out today
> that there is Cogl to circumvent device specific texture size
> restrictions. I know
> that this is still in the making, so I only would like to know if the
> following things
> are planned.
> * cogl_texture_2d_sliced_new_from_data: I found
> in the private header. I could use that, but that would require me to
> copy data that
> is already in memory to a bitmap.
To avoid exposing lots of _new_from_data() texture constructors for
all of the different texture types I was hoping that we could instead
get away with just having _new_with_size() constructors for most of
them and then you can set the data using cogl_texture_set_region().
Actually at some point I want a replacement for
cogl_texture_set_region() since it takes a ridiculous number of
arguments making it confusing to use but still the plan would be to
use a common function like cogl_texture_set_data() to set data for all
Conceptually all textures, including sliced textures, implement the
CoglTexture interface and can be cast to a (CoglTexture *) to use with
the cogl_texture api.
There shouldn't be any performance impact from separating the texture
allocation done with cogl_texture_2d_sliced_new_with_size() followed
by cogl_texture_set_region() since we don't redundantly initialize the
texture data when calling _new_with_size().
Hopefully that makes sense and would be ok for you?
> * Creating sliced textures from framebuffer to replace
> glCopyTexImage2D and glCopyTexSubImage2D. Or is this already possible
Ah yeah this is a good point, we don't currently have api for doing
this. My gut feeling is that we should add some common cogl_texture_
api for this, something like cogl_texture_set_data_from_framebuffer()
and then we would internally use apis like glCopyTexImage2D.
There may also be cases where we can avoid any copy at all if we
internally know that the source framebuffer's color buffer already
comes from a CoglTexture or can be wrapped as a CoglTexture.
I hope that helps,
> Best regards,
> Cogl mailing list
> Cogl at lists.freedesktop.org
More information about the Cogl