RenderCompositorSWGL::BeginFrame calls StartRemoteDrawingInRegion but doesn't do anything with the requested bufferMode.
This means that either we're using an unnecessary buffer and leaving performance on the table, or we're not buffering rendering when we should be, leading to potentially partially-drawn frames on the screen. I haven't read the code enough to know which of these is the case.

Or maybe bufferMode happens to be NONE whenever the call to mDT->LockBits succeeds, and BUFFERED whenever LockBits fails. If that's the case, everything is already working correctly. (I think on Windows the two cases are remote backbuffer vs gdi DrawTarget.)

A GDI Cairo surface I think would fail LockBits? (Looking at the code, this might not necessarily be the case, however) Whereas for X11, we're just drawing into a XShm buffer that needs to be explicitly committed after the fact and which is always BUFFER_NONE anyway.

I was under the impression our GDI blit was already somewhat slow. If it were to require adding another layer of copying here (assuming LockBits was succeeding in a case where BUFFERED was requested), I would imagine this would be even slower... Maybe less important now that we have a D3D11 compositor. I guess it hinges on what is actually going on with LockBits for the GDI case on whether or not we want to deal with this by adding a check before the call to LockBits to make sure it's not doing it for BUFFERED.

Jeff, could you take a look?

This bug seems to be related to Bug 1679215.

Matt Woodrow investigated this and determined that in the GPU process case we are creating a shmem DT on which LockBits succeeds, which is fine. Without the GPU process with GDI, LockBits will fail and thus end up buffering for us anyway. CompositorWidgetParent in Windows widget code looks like it reports BUFFER_NONE for us in this remote case so that we can actually check the value of bufferMode without problems here. The D3D11 compositor will bypass most of this issue for us in any case. Gtk widget looks like it properly reports buffer modes as BUFFER_NONE.

https://hg.mozilla.org/mozilla-central/rev/09f2e9068953