Currently Flash can request a number of rendering modes. Specifically -
https://wiki.mozilla.org/Plugins/Async_Drawing

• NPDrawingModelSyncWin - This is a synchronous rendering mode leveraged when we paint windowless plugin content. It is backed by a mozilla::gfx::SharedDIBSurface which is a GDI bitmap with a handle shared between processes.
• NPDrawingModelAsyncBitmapSurface - This is an async mode leveraged when Flash or Firefox do not support acceleration. On our end we fail to support acceleration for blocked graphics drivers. Flash may also block using acceleration for similar reason internally. It is backed by an IPDL shared memory buffer that is platform agnostic.
• NPDrawingModelAsyncWindowsDXGISurface - This is an async mode leveraged when Flash and Firefox support graphics acceleration. Firefox exposes an API that supports the creation and management of accelerated graphics memory objects which Flash paints directly to.

This bug is about swapping the use of SharedDIBSurface for an ipdl based shared memory buffer.

This bug is about swapping the use of SharedDIBSurface for an ipdl based shared memory buffer.

Hey David, when you have some free time, could you poke at this and figure out if this is doable.

(In reply to Jim Mathies [:jimm] from comment #1)

This bug is about swapping the use of SharedDIBSurface for an ipdl based shared memory buffer.

Hey David, when you have some free time, could you poke at this and figure out if this is doable.

Doesn't flash need a GDI DC to do its drawing in this case? See: https://searchfox.org/mozilla-central/source/dom/plugins/ipc/PluginInstanceChild.cpp#3052

(In reply to Jeff Muizelaar [:jrmuizel] from comment #3)

(In reply to Jim Mathies [:jimm] from comment #1)
Doesn't flash need a GDI DC to do its drawing in this case? See: https://searchfox.org/mozilla-central/source/dom/plugins/ipc/PluginInstanceChild.cpp#3052

Yep.

It turns out we don't need to do this. The only case we care about here is WebRender (since the sandbox goal of win32k-lockdown is not possible without it). In the sync rendering case (NPDrawingModelSyncWin), this ends up compositing via readback, which doesn't require any kernel operations in content -- it uses DataSourceSurfaces for the content process part. I have confirmed this by collecting Win32-kernel stacks (unless there are somehow some edge cases I haven't run). Note that it NPDrawingModelSyncWin does need Win32k when not using WR -- again, confirmed with stacks. ...but we don't care.

(That is not 100% true -- there is incidental use of gfxPlatform that sneaks into WR NPDrawingModelSyncWin behavior but isn't really used -- it's addressed in bug 1577336.)