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

[Roland Peffer]

Hi Robert,

>> 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 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
>> '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 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
> master.
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
>> 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 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
> texture.
> 
> 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
	cogl_buffer_set_data ,
    	cogl_bitmap_new_from_buffer 
    	cogl_texture_set_region_from_bitmap
    Performance is average as well.
3.) Finally I used
	cogl_buffer_map/unmap		 (to get the data from user space  into the graphics memory)
	cogl_bitmap_new_from_buffer
	cogl_texture_set_region_from_bitmap
    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 
	cogl_buffer_map/unmap
	cogl_texture_new_from_buffer
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. */
      _cogl_framebuffer_flush_journal (to_pop->draw_buffer);
      _cogl_framebuffer_flush_journal (to_pop->read_buffer);
      notify_buffers_changed (to_pop->draw_buffer,
                              to_restore->draw_buffer,
                              to_pop->read_buffer,
                              to_restore->read_buffer);
    }
......

Do you have any idea if and when this batching scenes support could be realized?



Thx,
Roland



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/cogl/attachments/20120124/81ae59eb/attachment.htm>