1416487 - Don't create back buffer for ContentClientDoubleBuffered until we know what we need

Status: RESOLVED WONTFIX

(Core :: Graphics: Layers, enhancement, P4)

Description

[Ryan Hunt [:rhunt] (on leave until early May)]

ContentClientDoubleBuffered currently has the limitation that the back buffer and front buffer must have equal dimensions. So if we are creating a new back buffer we will make its dimensions match the front buffer, even if the visible region has shrunk. This isn't necessary and could be improved.

Comment 1

[Ryan Hunt [:rhunt] (on leave until early May)]

Another optimization for double buffered content clients will be backed out in bug 1416921. This leaves us back at the existing behavior before bug 1399692, which is quite naive.

I will try and write up all the knowledge I have of what is bad and what code implicitly depends on what, so that this might be able to fixed in the future.

Comment 2

[Ryan Hunt [:rhunt] (on leave until early May)]

Dumping my thoughts on this before it is forgotten:

# Problems with ContentClientDoubleBuffered

1. We create a new buffer with EnsureBackBufferIfFrontBuffer before we decide what kind of buffer we need this frame. This means that we could end up deleting the newly created buffer in the same frame. We also will end up creating a buffer with the same size as the front buffer even if the visible region has shrunk. If the visible region has grown then we will throw it away!

2. Using EnsureBackBufferIfFrontBuffer is subtlely important for syncing the front and back buffer.
	1. The new back buffer is the same size as the front buffer
	2. The new back buffer starts at the same buffer rect as the front buffer
	3. ContentClientDoubleBuffered::BeginPaint and FinalizeFrame rely on those two properties to sync the front and back buffer. They will set the back buffer rect and rotation to the front buffer rect and rotation, then they will blit the pixels that changed between frames. Because they are the same size [1] and always start at the same buffer rect [2] this process will work.

3. The code that initializes a new back buffer will throw away the front buffer to enforce the same size and buffer rect rule, which is potentially wasteful.

# Steps in BeginPaint to avoid wasting creating back buffers

1. Don't create a new buffer with EnsureBackBufferIfFrontBuffer

2. We make the decision for the current frame aware that there is a front buffer and maybe not a back buffer. It will request a new buffer, just like how it does when the visible region expands.

3. If we have an existing back buffer then
	1. (Don't set the back buffer rect and rotation to the front buffer's)
	2. Do a backBuffer->AdjustTo(destinationRect) (potentially rotating to the destination)
	3. Do a backBuffer->Unrotate() if necessary
	4. Do a backBuffer->UpdateDestinationFrom(frontBuffer, frontUpdatedRegion - drawRegion)

4. If we don't have an existing back buffer or must create a new one then
	1. Do a CreateBuffer(destinationRect)
	2. Do a newBackBuffer->UpdateDestinationFrom(frontBuffer, destinationRect - drawRegion)

I believe this should work, as the buffer syncing would use methods that are fully aware that the buffers may have different buffer rect/size and rotation.

Comment 3

[Darkspirit]

bug 1727623