[Cogl] [clutter-announce] Release Cogl 1.9.4 (snapshot)

[Robert Bragg]

On Tue, Jan 17, 2012 at 6:54 AM, Roland Peffer <gdevel at clixxun.com>
wrote:> Hi,>> I just tested the new Version on OSX 1.6.8 64Bit and
found the folowing> issues:>> 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 Thereseems to be a
recurring problem on OSX with mipmapped text which wehaven'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> 'CoglVector3'> make[3]: *** [clutter-backend-osx.lo] Error 1> make[2]: *** [all] Error 2> make[1]: *** [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 changeduring a development cycle and we recently removed
the CoglVector3 type fromCogl. Alternatively I've also attached a
patch that was used to update Clutterthat you might be able to apply
against 1.9.2 if you don't want to use cluttermaster.
>> 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-pixbufI wonder? Taking a look at the configure.ac code I
think the gdk-pixbuf backendwill take precedence if that's found.
Maybe we should change that so thequartz 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> stream> 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
recommendsimply creating a new texture object for each update. The
cost of allocatingthe CoglTexture struct that describes the texture
should be trivial compared tothe cost of uploading the data so I don't
think we'd see a measurableperformance benefit from a
cogl_texture_update_from_buffer(). If you havesome profiling data
though that suggests it really would be worthwhile thenI'd be happy to
take a look at that.
I think one of the bigger challenges with optimizing video streaming
is avoidingbuffer copies and that's sometimes tricky to do without
knowing exactly what thedriver is doing under the hood. If you're not
lucky then the driver will endup making copies behind the scenes.
Modifying textures mid-scene is one thingin particular that can upset
some drivers which is another reason I'd be weary ofadding an
_update_from_buffer() function if it might lead developers
unwittinglyinto bad performance.
If you aren't updating the whole buffer for each update, then
something else tobe weary of is modifying a PixelBuffer that you
created a texture from. If thedriver managed to make your texture
without copying the pixel buffer then thedriver might not later allow
you to modify that buffer (via map/unmap) withoutfirst forcing an
internal copy-on-write. For this reason it can be worthexperimenting
with double/tripple buffering your pixel buffers and deleting
oldtextures so you can avoid modifying a buffer that is currently tied
to atexture.
Maybe a bit more of a brain dump than you were asking for, but my
feeling isthat you may have much more significant issues with regards
to avoiding buffercopies that can impact performance than needing to
worry about avoidingallocating CoglTexture objects.
kind regards,- Robert
>> Thx ,> Roland>>>    >> _______________________________________________> clutter-devel-list mailing list> clutter-devel-list at clutter-project.org> http://lists.clutter-project.org/listinfo/clutter-devel-list>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Remove-use-of-CoglVector3.patch
Type: text/x-patch
Size: 4080 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/cogl/attachments/20120117/044a0e69/attachment.bin>