In my debugger I saw a je_malloc(0x400010) which got rounded up to 0x500000 bytes. ImageDataSerializerBase::ComputeMinBufferSize computed the size based on a 1024x1024 |aSize| at 4 bytes per pixel, plus 0x10 bytes for an aligned SurfaceBufferInfo. I stumbled across this while debugging something else. I have no idea whether this is common in practice -- I'm hoping the area experts will know. If I merely hit an unfortunate case, feel free to just resolve. But if these 1024x1024 surfaces are common, this might be worth looking into. mozglue!je_malloc xul!mozilla::layers::MemoryTextureClient::Allocate xul!mozilla::layers::BufferTextureClient::AllocateForSurface xul!mozilla::layers::TextureClient::CreateForRawBufferAccess xul!mozilla::layers::TexClientFactory::Create xul!mozilla::layers::TexClientFromReadback xul!mozilla::layers::CanvasClientSharedSurface::Update xul!mozilla::layers::ClientCanvasLayer::RenderLayer xul!mozilla::layers::ClientLayer::RenderLayerWithReadback xul!mozilla::layers::ClientContainerLayer::RenderLayer xul!mozilla::layers::ClientLayer::RenderLayerWithReadback xul!mozilla::layers::ClientContainerLayer::RenderLayer xul!mozilla::layers::ClientLayerManager::EndTransactionInternal xul!mozilla::layers::ClientLayerManager::EndTransaction xul!nsDisplayList::PaintRoot

This was on http://webglsamples.org/aquarium/aquarium.html

(In reply to David Major [:dmajor] (UTC+13) from comment #0) > In my debugger I saw a je_malloc(0x400010) which got rounded up to 0x500000 > bytes. ImageDataSerializerBase::ComputeMinBufferSize computed the size based > on a 1024x1024 |aSize| at 4 bytes per pixel, plus 0x10 bytes for an aligned > SurfaceBufferInfo. > > I stumbled across this while debugging something else. I have no idea > whether this is common in practice -- I'm hoping the area experts will know. > If I merely hit an unfortunate case, feel free to just resolve. But if these > 1024x1024 surfaces are common, this might be worth looking into. > This can be fairly common, I guess. Depends on the web content. We could separate the header and the pixel data but this code is used by both the in-normal-memory and in-shmem Textures, and in the shmem case we need to not use too many file descriptors so we can't just separate the pixel data and header without doing something smart on the side. We should instrument the wasted proportion of these allocations and add it to about:memory reports.