I'm not aware of any piece of code that transforms buffer sizes. I'd expect that to require a reallocation too, so it seems unlikely.

The only place I'm familiar with that might change/tranform the buffer size is exo::Surface::buffer_transform_

What happens if you try low latency with http://nacl-latency.firebaseapp.com or https://webgl-latency.firebaseapp.com?
Do you get buffer sizes flipped as well?

The latter doesn't seem to use overlay. 

The former works, but the issue happens when it fails to use overlay with certain clipping, so i couldn't repro the issue. 

I also think I didn't explain this clearly. This happens when the device is rotated, and the client sends the rotated frame.

The biffer size shows rotated (on chrome side) size when overlay is working, but showns original size when not working.

here is the resource information when added to render pass, and candidate info in overlay manager.

When working:

in surface:
 origin=0,112, content_size=2000x2688, resource size=2688x2000, buffer transform=90
overlay candidate:
 transform=1, format=6, buffer_size=2688x2000, display_rect=127.999977,0.000000 2688.000000x2000.000000, crop_rect=0.000000,0.000000 1.000000x1.000000, is_clipped=1, z_order=1


When not working(1px smaller shelf size)
 origin=0,112, quad_rect=0,0 1x1, size=2000x2689, resource size=2689x2000, buffer transform=90
overlay candidate:
 transform=4, format=6, buffer_size=2000x2689, display_rect=127.000000,0.000000 2689.000000x2000.000000, crop_rect=0.000000,0.000000 1.000000x1.000000, is_clipped=1, z_order=1


When working, the candidate information is "post transform", while when not working, the candidate has pre transform information.

Looks like GetOverlayTransform gives different result depending on quad_to_target transform.