[Cogl] [clutter-announce] Release Cogl 1.9.4 (snapshot)
robert at sixbynine.org
Tue Jan 17 10:57:53 PST 2012
Since my previous reply was so badly mangled by gmail reformatting it
here is the same reply, but hopefully not mangled this time...
On Tue, Jan 17, 2012 at 6:54 AM, Roland Peffer <gdevel at clixxun.com> wrote:
> I just tested the new Version on OSX 1.6.8 64Bit and found the folowing
> 1.) CLUTTER 1.9.2 with COGL 1.9.4
> - clutter 1.9.2 compiled with cogl 1.9.2 , just updated to cogl 1.9.4:
> Clutter Text shows no text rendering anymore.
Can you please try running with CLUTTER_DISABLE_MIPMAPPED_TEXT=1 there
seems to be a recurring problem on OSX with mipmapped text which we
haven't yet managed to get to the bottom of.
> - Then I tried to recompile clutter 1.9.2 and got:
> In file included from ./osx/clutter-backend-osx.c:34:
> ./clutter-private.h:252: error: expected specifier-qualifier-list before
> make: *** [clutter-backend-osx.lo] Error 1
> make: *** [all] Error 2
> make: *** [all-recursive] Error 1
> make: *** [all] Error 2
You need to build with Clutter master until clutter next makes a release.
Clutter internally uses Cogl's experimental APIs which are subject to change
during a development cycle and we recently removed the CoglVector3 type from
Cogl. Alternatively I've also attached a patch that was used to update Clutter
that you might be able to apply against 1.9.2 if you don't want to use clutter
> 2.) Also I noticed that the quartz image option in cogl configure seems not
> to have any effect.
Have you explicitly disabled the gdk-pixbuf backend, using --disable-gdk-pixbuf
I wonder? Taking a look at the configure.ac code I think the gdk-pixbuf backend
will take precedence if that's found. Maybe we should change that so the
quartz backend has higher precedence if enabled.
> 3.) Would it be possible to add an update function like
> cogl_texture_update_from_buffer smilar to cogl_texture_new_from_buffer ?
> I would like to have it because like this I think I could update a video
> through Buffer map/unmap to a texture with not so much overhead.
If you're using the buffer to replace the whole texture then I would recommend
simply creating a new texture object for each update. The cost of allocating
the CoglTexture struct that describes the texture should be trivial compared to
the cost of uploading the data so I don't think we'd see a measurable
performance benefit from a cogl_texture_update_from_buffer(). If you have
some profiling data though that suggests it really would be worthwhile then
I'd be happy to take a look at that.
I think one of the bigger challenges with optimizing video streaming is avoiding
buffer copies and that's sometimes tricky to do without knowing exactly what the
driver is doing under the hood. If you're not lucky then the driver will end
up making copies behind the scenes. Modifying textures mid-scene is one thing
in particular that can upset some drivers which is another reason I'd be weary of
adding an _update_from_buffer() function if it might lead developers unwittingly
into bad performance.
If you aren't updating the whole buffer for each update, then something else to
be weary of is modifying a PixelBuffer that you created a texture from. If the
driver managed to make your texture without copying the pixel buffer then the
driver might not later allow you to modify that buffer (via map/unmap) without
first forcing an internal copy-on-write. For this reason it can be worth
experimenting with double/tripple buffering your pixel buffers and deleting old
textures so you can avoid modifying a buffer that is currently tied to a
Maybe a bit more of a brain dump than you were asking for, but my feeling is
that you may have much more significant issues with regards to avoiding buffer
copies that can impact performance than needing to worry about avoiding
allocating CoglTexture objects.
> Thx ,
> clutter-devel-list mailing list
> clutter-devel-list at clutter-project.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4081 bytes
Desc: not available
More information about the Cogl