Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2248183003:
Save latency info for skipped frames with the wrong size. (Closed)
|
Created:
4 years, 4 months ago by Eric Seckler Modified:
4 years, 4 months ago Reviewers:
piman CC:
chromium-reviews, jam, sievers+watch_chromium.org, jbauman+watch_chromium.org, darin-cc_chromium.org, piman+watch_chromium.org, kalyank, danakj+watch_chromium.org, danakj, dgozman, Sami, svartmetal Base URL:
https://chromium.googlesource.com/chromium/src.git@master Target Ref:
refs/pending/heads/master Project:
chromium Visibility:
Public. |
DescriptionSave latency info for skipped frames with the wrong size.
We observed that if a screenshot is captured while simultaneously the frame
is resized, it is possible that the screenshot is lost. This is because the latency
info (which identifies a CompositorFrame as the screenshot's frame) is sent
from the renderer within a wrongly sized CompositorFrame, which is then
skipped by DelegatedFrameHost.
For situations with an active resize lock, the latency info attached to dropped
frames is saved by the DFH and re-attached to the first frame that is not
dropped. However, this does not happen if the frame is dropped further down
the line, because it is not of the desired size of the RWHV.
This patch also saves the latency info for such wrongly sized frames in DFH,
until a correctly sized frame is submitted.
BUG=637066
Committed: https://crrev.com/2c33a82ea31e68a16e936668c4a0f4db7b2ef20b
Cr-Commit-Position: refs/heads/master@{#414372}
Patch Set 1 #
Messages
Total messages: 17 (11 generated)
Description was changed from ========== Save latency info for all skipped frames. BUG= ========== to ========== Save latency info for skipped frames with the wrong size. We observed that a screenshot that is captured while simultaneously the frame is resized, it is possible that the screenshot is lost. This is because the latency info (which identifies a CompositorFrame as the screenshot's frame) is sent from the renderer within a wrongly sized CompositorFrame, which is then skipped by DelegatedFrameHost. For situations with an active resize lock, the latency info attached to dropped frames is saved by the DFH and re-attached to the first frame that is not dropped. However, this does not happen if the frame is dropped further down the line, because it is not of the desired size of the RWHV. This patch also saves the latency info for such wrongly sized frames in DFH, until a correctly sized frame is submitted. BUG=637066 ==========
Description was changed from ========== Save latency info for skipped frames with the wrong size. We observed that a screenshot that is captured while simultaneously the frame is resized, it is possible that the screenshot is lost. This is because the latency info (which identifies a CompositorFrame as the screenshot's frame) is sent from the renderer within a wrongly sized CompositorFrame, which is then skipped by DelegatedFrameHost. For situations with an active resize lock, the latency info attached to dropped frames is saved by the DFH and re-attached to the first frame that is not dropped. However, this does not happen if the frame is dropped further down the line, because it is not of the desired size of the RWHV. This patch also saves the latency info for such wrongly sized frames in DFH, until a correctly sized frame is submitted. BUG=637066 ========== to ========== Save latency info for skipped frames with the wrong size. We observed that a screenshot that is captured while simultaneously the frame is resized, it is possible that the screenshot is lost. This is because the latency info (which identifies a CompositorFrame as the screenshot's frame) is sent from the renderer within a wrongly sized CompositorFrame, which is then skipped by DelegatedFrameHost. For situations with an active resize lock, the latency info attached to dropped frames is saved by the DFH and re-attached to the first frame that is not dropped. However, this does not happen if the frame is dropped further down the line, because it is not of the desired size of the RWHV. This patch also saves the latency info for such wrongly sized frames in DFH, until a correctly sized frame is submitted. BUG=637066 ==========
eseckler@chromium.org changed reviewers: + piman@chromium.org
piman, PTAL. +cc folks from SwapPromise patch, as it is related (https://codereview.chromium.org/2185823005/). We ran into this while testing sized screenshots, see work-in-progress patch https://codereview.chromium.org/2254923002/. Our test resizes the RWHV and directly afterwards issues a screenshot (ForceRedraw). In some cases, this works fine, in other, the screenshot/latency info is dropped after it reaches the DFH, because it's attached to a frame of the pre-resize size. The latency info is not terminated, so we figure the frame (and attached latency info) is somehow discarded after it is submitted to the SurfaceFactory. To work around this, we're saving away the latency info of such frames and attach it to the next correctly sized one. Does that make sense? We're not entirely sure if this change may break anything...
Description was changed from ========== Save latency info for skipped frames with the wrong size. We observed that a screenshot that is captured while simultaneously the frame is resized, it is possible that the screenshot is lost. This is because the latency info (which identifies a CompositorFrame as the screenshot's frame) is sent from the renderer within a wrongly sized CompositorFrame, which is then skipped by DelegatedFrameHost. For situations with an active resize lock, the latency info attached to dropped frames is saved by the DFH and re-attached to the first frame that is not dropped. However, this does not happen if the frame is dropped further down the line, because it is not of the desired size of the RWHV. This patch also saves the latency info for such wrongly sized frames in DFH, until a correctly sized frame is submitted. BUG=637066 ========== to ========== Save latency info for skipped frames with the wrong size. We observed that if a screenshot is captured while simultaneously the frame is resized, it is possible that the screenshot is lost. This is because the latency info (which identifies a CompositorFrame as the screenshot's frame) is sent from the renderer within a wrongly sized CompositorFrame, which is then skipped by DelegatedFrameHost. For situations with an active resize lock, the latency info attached to dropped frames is saved by the DFH and re-attached to the first frame that is not dropped. However, this does not happen if the frame is dropped further down the line, because it is not of the desired size of the RWHV. This patch also saves the latency info for such wrongly sized frames in DFH, until a correctly sized frame is submitted. BUG=637066 ==========
The CQ bit was checked by eseckler@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
On 2016/08/17 18:50:47, Eric Seckler wrote: > piman, PTAL. Friendly ping :) Thanks!
LGTM, apologies, this fell through the cracks. Feel free ping me if I don't respond within 24h unless my status was changed to indicate I'm OOO.
The CQ bit was checked by eseckler@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Message was sent while issue was closed.
Description was changed from ========== Save latency info for skipped frames with the wrong size. We observed that if a screenshot is captured while simultaneously the frame is resized, it is possible that the screenshot is lost. This is because the latency info (which identifies a CompositorFrame as the screenshot's frame) is sent from the renderer within a wrongly sized CompositorFrame, which is then skipped by DelegatedFrameHost. For situations with an active resize lock, the latency info attached to dropped frames is saved by the DFH and re-attached to the first frame that is not dropped. However, this does not happen if the frame is dropped further down the line, because it is not of the desired size of the RWHV. This patch also saves the latency info for such wrongly sized frames in DFH, until a correctly sized frame is submitted. BUG=637066 ========== to ========== Save latency info for skipped frames with the wrong size. We observed that if a screenshot is captured while simultaneously the frame is resized, it is possible that the screenshot is lost. This is because the latency info (which identifies a CompositorFrame as the screenshot's frame) is sent from the renderer within a wrongly sized CompositorFrame, which is then skipped by DelegatedFrameHost. For situations with an active resize lock, the latency info attached to dropped frames is saved by the DFH and re-attached to the first frame that is not dropped. However, this does not happen if the frame is dropped further down the line, because it is not of the desired size of the RWHV. This patch also saves the latency info for such wrongly sized frames in DFH, until a correctly sized frame is submitted. BUG=637066 ==========
Message was sent while issue was closed.
Committed patchset #1 (id:1)
Message was sent while issue was closed.
Description was changed from ========== Save latency info for skipped frames with the wrong size. We observed that if a screenshot is captured while simultaneously the frame is resized, it is possible that the screenshot is lost. This is because the latency info (which identifies a CompositorFrame as the screenshot's frame) is sent from the renderer within a wrongly sized CompositorFrame, which is then skipped by DelegatedFrameHost. For situations with an active resize lock, the latency info attached to dropped frames is saved by the DFH and re-attached to the first frame that is not dropped. However, this does not happen if the frame is dropped further down the line, because it is not of the desired size of the RWHV. This patch also saves the latency info for such wrongly sized frames in DFH, until a correctly sized frame is submitted. BUG=637066 ========== to ========== Save latency info for skipped frames with the wrong size. We observed that if a screenshot is captured while simultaneously the frame is resized, it is possible that the screenshot is lost. This is because the latency info (which identifies a CompositorFrame as the screenshot's frame) is sent from the renderer within a wrongly sized CompositorFrame, which is then skipped by DelegatedFrameHost. For situations with an active resize lock, the latency info attached to dropped frames is saved by the DFH and re-attached to the first frame that is not dropped. However, this does not happen if the frame is dropped further down the line, because it is not of the desired size of the RWHV. This patch also saves the latency info for such wrongly sized frames in DFH, until a correctly sized frame is submitted. BUG=637066 Committed: https://crrev.com/2c33a82ea31e68a16e936668c4a0f4db7b2ef20b Cr-Commit-Position: refs/heads/master@{#414372} ==========
Message was sent while issue was closed.
Patchset 1 (id:??) landed as https://crrev.com/2c33a82ea31e68a16e936668c4a0f4db7b2ef20b Cr-Commit-Position: refs/heads/master@{#414372} |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
