Don’t Copy That Surface
blog.chromium.org
blog.chromium.org
> This method may internally allocate some memory, so if the buffer supports the IMF2DBuffer interface, you should use the IMF2DBuffer::Lock2D method to lock the buffer instead. For 2-D buffers, the Lock2DSize method can be more efficient than the Lock method, depending on the MF2DBuffer_LockFlags value you specify. Calling Lock2DSize with MF2DBuffer_LockFlags_Read won’t incur a copy back when the buffer is unlocked and calling it with MF2DBuffer_LockFlags_Write won’t incur a copy from the internal buffer. Calling Lock2DSize with LockFlags_ReadWrite behaves the same as Lock and Lock2D and will incur a both copy from and copy back when unlocked. The general guidance for best performance is to avoid using IMFMediaBuffer and IMF2DBuffer whenever possible and instead use IMF2DBuffer2 with the minimum required lock flags. Note that if the buffer is locked using Lock2D, the Lock method might return MF_E_INVALIDREQUEST.
[0]: https://bugs.chromium.org/p/chromium/issues/detail?id=107118...
I'd like to read more blogs where the solution to bad performance isn't just 1) throw more servers at the issue 2) rewrite the service in a different language / framework and hope to not hit the same pathological case again.
Not doing so escalates quickly - copying a 4k10bpp buffer 60 times per second takes up ~5Gbit of memory bandwidth.
I think Bruce Dawson is literally the only person I can think of who still publishes anything like this for Windows, but yes, one person does!
For example, a graphics API like Metal or Direct3D lets you create surfaces that reside either in GPU or CPU memory.
Or, an OS-level interprocess API like Apple's IOSurface lets you create shared surfaces that can be accessed by multiple processes.
Yeah, seems like a poor choice of title without the explanation.
For rendering implementations, "surface" usually refers to a part of memory being rendered into as output or that something else has rendered into that is being used as input, like an image buffer that webcam output is dumped into. One example set of docs: https://docs.microsoft.com/en-us/windows/win32/direct3d9/dir...
I don't know if I've ever really thought about the name. I guess maybe at some point it was more straightforward and a surface was just a part of memory that was going to be blitted directly to screen and so in that sense you're painting a "surface" of that area of the screen? I'd be interested if anyone knows a more detailed etymology.
In D3D terminology I think it's almost always been "surfaces" and "render targets", where the latter is something you can paint into. Surfaces are often broken down into levels, and don't necessarily contain image data (they can contain depth/stencil data for 3D rendering, for example)
I chose the title so long ago that I can't really remember what I was thinking.
> A surface represents a linear area of display memory and usually resides in the display memory of the display card, although surfaces can exist in system memory.
https://stackoverflow.com/questions/1033445/what-exactly-is-...
> broadly speaking, a surface is some 2D image data.
I’ve tried using Discord for video chat and screen sharing on a 4 year old laptop (2.9 ghz dual core i5) and it was not a pleasant experience.