Closed Bug 1407480 Opened 7 years ago Closed 7 years ago

TalosError("timeout") on tabpaint

Categories

(Core :: Graphics: WebRender, defect, P1)

defect

Tracking

()

RESOLVED FIXED
mozilla58
Tracking Status
firefox57 --- unaffected
firefox58 --- unaffected

People

(Reporter: vliu, Assigned: vliu)

References

(Blocks 1 open bug)

Details

(Whiteboard: [wr-reserve])

Attachments

(1 file, 1 obsolete file)

It is still has this timeout error with recent try build. Please see [1] for detail.

[1]: https://treeherder.mozilla.org/logviewer.html#?job_id=135642600&repo=try&lineNumber=4283
Assignee: nobody → vliu
Status: NEW → ASSIGNED
Priority: P3 → P1
Whiteboard: [wr-reserve]
The timeout happens because rect.width and rect.height became zero and caused a early return[1]. In this case, the async message TabPaint:Painted didn't called and finally timeout.

[1]: http://searchfox.org/mozilla-central/rev/31606bbabc50b08895d843b9f5f3da938ccdfbbf/testing/talos/talos/tests/tabpaint/content/target.html#25
Hi kats,
The attached patch intends to fix the timeout for tabpaint tolas test. Like the description in Comment, timeout happens because rect.height became zero.
The thing is zero width and height was passed when we called NotifyInvalidation() in [1] in layers-free mode. To solve it, I tried to get valid Rect from nsIFrame and passed into it. I'd sent this patch and it can pass the try. Please see [2].

[1]: http://searchfox.org/mozilla-central/rev/31606bbabc50b08895d843b9f5f3da938ccdfbbf/layout/painting/nsDisplayList.cpp#2189
[2]: https://treeherder.mozilla.org/#/jobs?repo=try&revision=1ed76d6a38c87d649ba4743e719fb624c12a0883

Could you please have a review? Thanks
Attachment #8917711 - Flags: review?(bugmail)
Per discussion with Vincent, looks like the talos test checks if the invalidation region is empty before starting. So we should pass a non-empty rect. Originally we pass an empty rect is because we are not sure who uses the invalidation rect. For WR, I think the invalidation rect should be the whole frame.
Comment on attachment 8917711 [details] [diff] [review]
0001-Bug-1407480-Carry-valid-Rect-when-calling-NotifyInva.patch

Review of attachment 8917711 [details] [diff] [review]:
-----------------------------------------------------------------

::: layout/painting/nsDisplayList.cpp
@@ +2186,5 @@
>      }
>  
>      if (presContext->RefreshDriver()->HasScheduleFlush()) {
> +      nsRect rect = frame->GetRect();
> +      presContext->NotifyInvalidation(layerManager->GetLastTransactionId(), rect);

I think you can pass 'frame->GetRect()' directly.
(In reply to Ethan Lin[:ethlin] from comment #4)
> Comment on attachment 8917711 [details] [diff] [review]
> 0001-Bug-1407480-Carry-valid-Rect-when-calling-NotifyInva.patch
> 
> Review of attachment 8917711 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: layout/painting/nsDisplayList.cpp
> @@ +2186,5 @@
> >      }
> >  
> >      if (presContext->RefreshDriver()->HasScheduleFlush()) {
> > +      nsRect rect = frame->GetRect();
> > +      presContext->NotifyInvalidation(layerManager->GetLastTransactionId(), rect);
> 
> I think you can pass 'frame->GetRect()' directly.

Sure. it is more clear for the patch.
Attachment #8917711 - Attachment is obsolete: true
Attachment #8917711 - Flags: review?(bugmail)
Attachment #8917735 - Flags: review?(bugmail)
Comment on attachment 8917735 [details] [diff] [review]
0001-Bug-1407480-Carry-valid-Rect-when-calling-NotifyInva.patch

Review of attachment 8917735 [details] [diff] [review]:
-----------------------------------------------------------------

This seems reasonable to me. Thanks!
Attachment #8917735 - Flags: review?(bugmail) → review+
Blocks: 1388995
Pushed by vliu@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/6ead77d51be9
Carry valid Rect when calling NotifyInvalidation() in layers-free mode. r=kats
https://hg.mozilla.org/mozilla-central/rev/6ead77d51be9
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla58
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: