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

[Robert Bragg]

Wow, gmail has totally butchered the formatting of my reply, sorry
about that :-/

Hopefully you can pick out what I said. I'm not sure I should dare try
fixing it since
I imagine it'll end up in an even bigger mess.

regards,
- Robert

On Tue, Jan 17, 2012 at 1:13 PM, Robert Bragg <robert at sixbynine.org> wrote:
> 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>