Sotaro Ikeda [:sotaro] Assignee
	Description • 6 years ago

Created by Bug 1481950 comment 6.

	Sotaro Ikeda [:sotaro] Assignee
	Comment 2 • 6 years ago

https://treeherder.mozilla.org/#/jobs?repo=try&revision=471d81ad6434be150c6b105bd70134474cf609e4

	Sotaro Ikeda [:sotaro] Assignee
	Comment 3 • 6 years ago

attachment 8998761 [details] [diff] [review] seems to have a timing dependent bug. The Epoch is delivered to RenderBackend via SceneBuilder thread. But frame generation is delivered directly to RenderBackend without SceneBuilder thread. Therefore there could be a case that frame generation happens before epoch delivery to RenderBackend. If it happens, did composite is not delivered correctly to client side.

	Sotaro Ikeda [:sotaro] Assignee
	Comment 4 • 6 years ago

If transaction has resource updates, it trigger a next frame generation. But if it does not have the resource updates, it does not trigger a next frame generation.

	Sotaro Ikeda [:sotaro] Assignee
	Comment 5 • 6 years ago

To handle empty transaction with ScrollUpdates correctly, we need to trigger a frame generation after SceneBuilder thread handled epoch update message. But the "epoch update message" is delivered via SceneBuilder thread and "frame generation" is delivered directly to RenderBackend thread. So attachment 8998761 [details] [diff] [review] has a risk of do frame generation before "epoch update message".

To avoid this, we need to trigger ScheduleGenerateFrame() after "epoch update message". But current SceneBuilder could not trigger generate frame in this case. Though SceneBuilder could trigger the generate frame if Transaction updates display list or updates resources.

	Sotaro Ikeda [:sotaro] Assignee
	Comment 7 • 6 years ago

Comment on attachment 8999798 [details] [diff] [review]
patch - Fix webrender epoch handling in WebRenderBridgeParent::RecvEmptyTransaction()

:nical, can you feedback to the patch?

	Sotaro Ikeda [:sotaro] Assignee
	Comment 8 • 6 years ago

Hmm, attachment 8999798 [details] [diff] [review] regresses talos scroll performance :(
https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=d8be8e68c4a79bd69ce0a36bdce3547aa85985e4&newProject=try&newRevision=795d3ed2361b6db28c1fadbb8911793e68d8fb70&framework=1

	Sotaro Ikeda [:sotaro] Assignee
	Comment 9 • 6 years ago

By Comment 8, we could not address the problem this way.

	Sotaro Ikeda [:sotaro] Assignee
	Comment 10 • 6 years ago

Since Bug 1489993, it might better to revisit this.