Forums - Remove padding for GraphicBuffers?

4 posts / 0 new
Last post
Remove padding for GraphicBuffers?
emilwestergren
Join Date: 4 Jul 14
Posts: 6
Posted: Tue, 2014-09-30 01:35

Hello,

I posted a problem here a while ago where the pixel layout in a GraphicBuffer rendered to with OpenGLES and EGLImage was padded for every row (https://developer.qualcomm.com/forum/qdn-forums/maximize-hardware/mobile...). I needed the data to be sequential without padding so I simply used memcpy to copy the rows into a new buffer. My question is if there is a way to prevent this padding or some other way of removing the need to copy the data row by row? Performance is a major factor.

  • Up0
  • Down0
mhfeldma Moderator
Join Date: 29 Nov 12
Posts: 310
Posted: Tue, 2014-09-30 07:28

Could you explain a bit more where you are seeing the padding?

From your last post: I am rendering RGBA8888 to a 480x1080 texture and the resulting texture was padded to 640x1080"

Could you review in more detail and code where the 480 and 640 are coming from? 

  • Up0
  • Down0
emilwestergren
Join Date: 4 Jul 14
Posts: 6
Posted: Tue, 2014-09-30 09:32

Thanks for posting.

Creation of GraphicBuffer:

buffers[index] = new GraphicBuffer(480, 1080, HAL_PIXEL_FORMAT_RGBA_8888, GraphicBuffer::USAGE_SW_READ_OFTEN | GraphicBuffer::USAGE_HW_RENDER | GraphicBuffer::USAGE_HW_TEXTURE);

The reason I use a 480x1080 texture is I render a monochrome (R8) 1920x1080 texture and if I understand correctly EGLImage with GraphicBuffers only supports RGBA8888 and RGB565.

I render a 480x1080 RGBA texture in OpenGLES to the graphicbuffer with this viewport set:

glViewport(0, 0, 480, 1080)

 

Get pointer to the pixels:

void* pixels;

buffers[index]->lock(GraphicBuffer::USAGE_SW_READ_OFTEN, &pixels);

When I iterate over the buffer (as byte array), after each row of pixels (1920 bytes) there is 640 bytes of padding (with value 0). So for example the second row starts at:

(char*)pixels[1920 + 640]

So I wonder if there is a way to prevent this padding? Building Android 4.4.4 for Nexus 5 by the way.

  • Up0
  • Down0
mhfeldma Moderator
Join Date: 29 Nov 12
Posts: 310
Posted: Tue, 2014-09-30 13:30

Implementation of GraphiBuffer is fairly hardware dependent and it's overall size is a performance optimization.  The padding amount will vary on different devices and even change in the future.  Our recommendation is to use a different approach to capture the frame and avoid doing the memory copy.

  • Up0
  • Down0
or Register

Opinions expressed in the content posted here are the personal opinions of the original authors, and do not necessarily reflect those of Qualcomm Incorporated or its subsidiaries (“Qualcomm”). The content is provided for informational purposes only and is not meant to be an endorsement or representation by Qualcomm or any other party. This site may also provide links or references to non-Qualcomm sites and resources. Qualcomm makes no representations, warranties, or other commitments whatsoever about any non-Qualcomm sites or third-party resources that may be referenced, accessible from, or linked to this site.