Hi Robert, thank you!
Roland On 25.07.2011, at 23:58, Robert Bragg wrote: On Jul 23, 2011 11:14 AM, "Roland Peffer" <[email protected]> wrote: > Well, > I agree that the CoglBitmap is not the most clearest approach. > But in this case it has some advantage. > As I have actually 3 different Bitmaps in one buffer from a YUV frame, and so > I can create 3 different bitmaps and update the YUV textures and convert them > later using a GLSL shader into an RGBA texture. > A little optimization would be if we could add a kind of > "_cogl_bitmap_update_from_buffer" function instead of always creating a new > bitmap with _cogl_bitmap_new_from_buffer and releasing it after again. This > would at least allow to run textures updates without any memory allocations, > and so cause not any global thread holds. > As far I understand the code a bitmap attached to a buffer just has a pointer > and offset to the buffer object. So no real need to always create a new > bitmap object. ok in the end I made the change as you asked. I initially implemented a cogl_texture_set_region_from_buffer as an alternative, but given we've been planning to do a number of CoglTexture related cleanups, hopefully relatively soon, I figured that either which way I do it, it's pretty likely things will change a bit before we reach 2.0 anyway so this simpler approach seems ok for now. One thing I didn't do with my patch is add the new symbols to the 2.0 reference manual for now and that was because I specifically removed the CoglBitmap api from the 2.0 manual a while back and don't really want to add it back at this point. At least this way you should be able to take advantage of the api for your use-case; it's just that at some point we will hopefully come up an alternative design for 2.0 proper. I hope that helps you, kind regards, - Robert > > Kind regards, > Roland > > On 23.07.2011, at 11:28, Robert Bragg wrote: > > > On Jul 23, 2011 8:01 AM, "Roland Peffer" <[email protected]> wrote: >> >> Hi, >> >> As I wrote recently I found out that cogl_texture_set_region is a little >> performance bottleneck for updating a texture from system memory. >> After Evgeny Zajcev gave me some hints I found a better way. >> >> I use cogl_pixel_buffer_new_with_size , cogl_buffer_set_data and >> cogl_texture_new_from_buffer to create and initialize a new texture. >> Then for updating I use cogl_buffer_set_data, _cogl_bitmap_new_from_buffer >> and _cogl_texture_set_region_from_bitmap. >> >> The problem is that _cogl_bitmap_new_from_buffer and >> _cogl_texture_set_region_from_bitmap are not exported from the cogl library. >> So I quickly patched the library and added cogl_texture_set_region_from and >> cogl_bitmap_new_from_buffer to the exported function list. >> >> So please do me a favour and add these two functions in the master branch to >> the (experimental) API. > > I kind of wonder if we should add cogl_texture_set_region_from_buffer for > this purpose. I'm personally not very happy with the CoglBitmap api, and have > been trying to figure out of how to replace it with a better design which > means ideally I'd like to avoid exporting more CoglBitmap api if possible. > I'll take a look at this today and hopefully i'll cook up a patch to see if > that would be ok for you. If not then yeah we can make the cogl_bitmap api > exported for now. > > Kind regards, > - Robert > >> >> >> Thx >> Roland >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> clutter-app-devel-list mailing list >> [email protected] >> http://lists.clutter-project.org/listinfo/clutter-app-devel-list >
_______________________________________________ clutter-app-devel-list mailing list [email protected] http://lists.clutter-project.org/listinfo/clutter-app-devel-list
