I agree it seems like this could be done more efficiently. Bug 1604412 was already getting quite complex, and so I took a "make it work, then make it fast" approach. It seems like it's time to do some work towards the second part of that :) I can take a crack at implementing this when I get some free cycles, but in case anyone else is inclined to take it on - Probably the solution will involve "remembering" the update region from `StartRemoteDrawingInRegion()` and then sending it to the `remote_backbuffer::Provider` via IPDL during the `EndRemoteDrawing()` call. I'm more inclined to think of this as an "enhancement" rather than a regression, as this is IMO new and unprecedented behaviour. We knew we were going to have to accept some amount of GDI perf hit for this GPU sandbox, and so this seems like an improvement on that initial feature.
Bug 1647877 Comment 2 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I agree it seems like this could be done more efficiently. Bug 1604412 was already getting quite complex, and so I took a "make it work, then make it fast" approach. It seems like it's time to do some work towards the second part of that :) I can take a crack at implementing this when I get some free cycles, but in case anyone else is inclined to take it on - Probably the solution will involve "remembering" the update region from `StartRemoteDrawingInRegion()` and then sending it to the `remote_backbuffer::Provider` via the shared memory region during the `EndRemoteDrawing()` call. I'm more inclined to think of this as an "enhancement" rather than a regression, as this is IMO new and unprecedented behaviour. We knew we were going to have to accept some amount of GDI perf hit for this GPU sandbox, and so this seems like an improvement on that initial feature.