Updating texture

[bibhas]

Hi Guys,

I'm using clutter but my question is Cogl related, so I thought I'd ask the question here.

I'm trying to test out "cogl_texture_set_region" by updating the texture of a ClutterActor during it's repaint seq. However I am not getting it to work. Can anyone have a look at the code and help me out? 

Link: http://f.cl.ly/items/0e441B3Y3C1T0V0Q3x1S/rr3.c

Thanks a lot!

Bibhas

[bibhas]

Oh, forgot to mention: I'm using Clutter 1.6.2 on OSX (quartz backend). Thanks again!

[Robert Bragg]

Hi Bibhas,

Good question; I think there are a few things going on here...

The first thing to note here is that setting the size of the ClutterTexture actor won't affect the size of any underlying texture, rather it will just result in the texture being scaled when painted. I get the impression you're expecting:

clutter_actor_set_size(texture, WIDTH, HEIGHT);

to set the size of the texture but that isn't the case.

When a ClutterTexture is first instantiated I don't think it will have an associated CoglTexture. I haven't tried running your test, so I'm not really sure what happens when you call clutter_texture_get_cogl_texture() but my expectation is that you get NULL here, or a reference to a dummy 1x1 internal texture.

If you want to update a sub region of a ClutterTexture this way you could first either load a texture via clutter_texture_new_from_file() or perhaps use cogl_texture_new_with_size() to create a texture with a certain size but no content followed by clutter_texture_set_cogl_texture()

Another problem I see is definitely as a result of bad documentation for cogl_texture_set_region(). This API is really quite old and on the list of APIs that really needs a replacement with better documentation. The documentation implies that you can set a sub-region of texture from a smaller source region because it lets you specify the source width/height separately from the dest width/height. Actually you can only set a region as large or smaller than the source region, so it won't work to try and repeat your 2x2 greenish source across the whole texture, you actually need to generate data for the whole texture and set that.

Do you really want to fill a region with a small source region, or did you just do try that for testing purposes? If you do need to do that I can explain how you could do it by binding the larger texture into an offscreen framebuffer and then painting the smaller source using cogl_rectangle() which will be able the repeat the source, but this approach will be a bit more involved than what you are doing currently.

I hope that helps a bit.

I'll at least aim to update the documentation for cogl_texture_set_sub_region() to explain this isn't supported - sorry about that.

kind regards,
- Robert

[bibhas]

Hi Robert,

Thanks a lot of replying. I'll quickly try setting a new texture and reply.

As for the dummy data, I was expecting it to be interpolated across the dimensions of the texture (I just wanted something on the screen). So, yeah. I'll get back to you as soon as I get it to work.

Thanks a lot though.

- Bibhas

[bibhas]

Robert,

Can't thank you enough. Got it working (after about 4 days of struggling): http://cl.ly/010q290f151t450a2m01

Just one more question: In general when I use "cogl_texture_set_region", will the update be faster if I do it on a pixel by pixel basis or do block updates? What is the performance like when I use this function? I'm not very well acquainted with OpenGL and GPU in general so this may be a noob question, but does the number of updates per function call affect performance? Does the journal buffer the changes and consolidate all changes into one glTexSubImage2D call (or something similar)?

Thanks again.

Bibhas

[Robert Bragg]

On Tuesday, November 22, 2011 12:15:45 PM UTC, bibhas wrote:

Robert,

Can't thank you enough. Got it working (after about 4 days of struggling): http://cl.ly/010q290f151t450a2m01

Wooo! :-) Sorry that it didn't "Just Work" though. I wrote a small patch for the cogl_texture_set_region documentation which I'll land soon which also adds some explicit runtime asserts, so hopefully no one else will be caught out by the dest size > src size issue.

Just one more question: In general when I use "cogl_texture_set_region", will the update be faster if I do it on a pixel by pixel basis or do block updates? What is the performance like when I use this function? I'm not very well acquainted with OpenGL and GPU in general so this may be a noob question, but does the number of updates per function call affect performance? Does the journal buffer the changes and consolidate all changes into one glTexSubImage2D call (or something similar)?

 

The api is not really geared towards pixel level updates no. The journal isn't involved here or any kind of batching. A call to cogl_texture_set_region basically corresponds to a call to glTexSubImage2D.

The size of the region updated will affect performance if you micro benchmark this yes, but I would expect the per-call cost of cogl_texture_set_region (ignoring the cost associated with the region size) to be rather high too so it would be unlikely that you could improve performance by resorting to pixel level updates because the per-call cost will quickly add up to more than the cost of updating a larger region. To some extent this is something that could vary quite a bit between different drivers though and depending on exactly the kinds of updates you expect to be making it could well be worth experimenting with multiple strategies if performance here really does end up being a bottleneck for you.

kind regards,
- Robert
 

Thanks again.

Bibhas