[PATCH] Avoid unnecessarily re-allocating texture buffer when the size hasn't changed.

Ander Conselvan de Oliveira conselvan2 at gmail.com
Wed Jun 5 02:24:01 PDT 2013


On 05/29/2013 01:38 AM, Sinclair Yeh wrote:
> On Sun, 26 May 2013 20:03:40 -0400
> Kristian Høgsberg <hoegsberg at gmail.com> wrote:
>
>>> +		/* Only allocate a texture if it doesn't match
>>> existing one */
>>> +		if (((wl_shm_buffer_get_stride(buffer) / 4) !=
>>> gs->pitch) ||
>>> +		    (buffer->height != gs->height)) {
>>
>> I would prefer a little fewer parentheses here - only the () required
>> by if are necessary.  Nitpicks aside, we need to also call
>> glTexImage2D in case we're switching from a egl buffer to a shm
>> buffer.  If we don't the texture will remain backed by the EGLImage
>> from the previous frame and the glTexSubImage2D in flush_damage will
>> write into that buffer.
>>
>> The best way to check if we're coming from a EGLImage buffer is to
>> see if gs->num_images is > 0, which I'd just add to the if statement.

Actually, the EGL images are not destroyed when the switch happens, 
neither is gs->num_images updated. So once the switch happens, if we 
check for gs->num_images we'll end up calling glTexImage2D() on every 
attach. I just sent a patch to fix this, but that makes the check a tad 
more complicated. One needs to save the value of gs->num_images before 
freeing the images to check later.

> I am unfamiliar with this particular case, but I've added the check.
> What is the usage scenario for switching from DRM backed buffer to SHM?

An application could decide to switch to software rendering after using 
GL for releasing resources, for example.

Cheers,
Ander

>
> Also, here do I need to do any of the house cleaning done by the
> "if(!buffer)" condition above or are these going to be cleaned up by a
> different API?
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>



More information about the wayland-devel mailing list