[Cogl] [clutter-announce] Release Cogl 1.9.4 (snapshot)
gdevel at clixxun.com
Tue Jan 24 03:00:53 PST 2012
>> 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.
Well that worked!. Before I used clutter_set_font_flags (CLUTTER_FONT_HINTING),
but it seems to have not the desired effect anymore!
>> - 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
I did not try the last version yet. Will give you an update if it causes problems.
>> 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.
You are right, if I disable gtk-pixbuf, quartz image gets active!
>> 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.
I played around with various streaming methods:
1.) The most simple is to use cogl_texture_set_region .
Performance is average.
2.) Then I tried a sequence of
Performance is average as well.
3.) Finally I used
cogl_buffer_map/unmap (to get the data from user space into the graphics memory)
Performance is the best so far. I just wonder if replacing the last 2 calls
by a new cogl_texture_update_from_buffer function even could increase performance.
4.) Your advise to use
showed the worst performance off all.
I have also another question: In cogl_pop_framebuffer (void) I found the comment:
/* XXX: eventually we want to remove this implicit journal flush
* so we can log into the journal beyond framebuffer changes to
* support batching scenes that depend on the results of
* mid-scene renders to textures. */
Do you have any idea if and when this batching scenes support could be realized?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Cogl