Repetitive dispatches of MozAfterPaint

RESOLVED INVALID

Status

()

RESOLVED INVALID
10 years ago
10 years ago

People

(Reporter: mossop, Unassigned)

Tracking

Trunk
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 obsolete attachment)

(Reporter)

Description

10 years ago
I'm experimenting with the MozAfterPaint method and I'm hitting a case where it is being sent what appears to be an infinite number of times. It is reproducable I guess maybe 10% of the times I load tinderbox. I have it zoomed out a couple of steps, don't know if that makes a difference.

This is in a non-debug build, but dtrace is telling me the following stack which looks kinda recursive but without knowing the pointers I guess it could be a deep frame tree:

  0  18627 nsPresContext::NotifyInvalidation(nsRect const&, int):entry 
              XUL`nsPresContext::NotifyInvalidation(nsRect const&, int)
              XUL`nsHTMLScrollFrame::InvalidateInternal(nsRect const&, int, int, nsIFrame*, unsigned int)+0x11b
              XUL`nsIFrame::InvalidateInternalAfterResize(nsRect const&, int, int, unsigned int)+0x59
              XUL`nsIFrame::InvalidateInternal(nsRect const&, int, int, nsIFrame*, unsigned int)+0xa1
              XUL`nsIFrame::InvalidateInternalAfterResize(nsRect const&, int, int, unsigned int)+0x59
              XUL`nsIFrame::InvalidateInternal(nsRect const&, int, int, nsIFrame*, unsigned int)+0xa1
              XUL`nsBlockFrame::InvalidateInternal(nsRect const&, int, int, nsIFrame*, unsigned int)+0xe5
              XUL`nsIFrame::InvalidateInternalAfterResize(nsRect const&, int, int, unsigned int)+0x59
              XUL`nsIFrame::InvalidateInternal(nsRect const&, int, int, nsIFrame*, unsigned int)+0xa1
              XUL`nsBlockFrame::InvalidateInternal(nsRect const&, int, int, nsIFrame*, unsigned int)+0xe5
              XUL`nsIFrame::InvalidateInternalAfterResize(nsRect const&, int, int, unsigned int)+0x59
              XUL`nsIFrame::InvalidateInternal(nsRect const&, int, int, nsIFrame*, unsigned int)+0xa1
              XUL`nsIFrame::InvalidateInternalAfterResize(nsRect const&, int, int, unsigned int)+0x59
              XUL`nsIFrame::InvalidateInternal(nsRect const&, int, int, nsIFrame*, unsigned int)+0xa1
              XUL`nsIFrame::InvalidateInternalAfterResize(nsRect const&, int, int, unsigned int)+0x59
              XUL`nsIFrame::InvalidateInternal(nsRect const&, int, int, nsIFrame*, unsigned int)+0xa1
              XUL`nsIFrame::InvalidateInternalAfterResize(nsRect const&, int, int, unsigned int)+0x59
              XUL`nsIFrame::InvalidateInternal(nsRect const&, int, int, nsIFrame*, unsigned int)+0xa1
              XUL`nsIFrame::InvalidateInternalAfterResize(nsRect const&, int, int, unsigned int)+0x59
              XUL`nsIFrame::InvalidateInternal(nsRect const&, int, int, nsIFrame*, unsigned int)+0xa1
You expect to see deep stacks like that. As long as you're not hitting stack overflow that's fine.

Not sure what you mean by "an infinite number of times". If your MozAfterPaint handler does anything to cause painting in the document you're observering, you'll trigger an infinite series of paints, of course.
(Reporter)

Comment 2

10 years ago
No it doesn't make any changes to the document at all. And by infinite I mean I can sit there and watch it dispatching a paint event for the same region seemingly forever until I close the tab.
(Reporter)

Comment 3

10 years ago
Created attachment 341514 [details]
fuller stack

This is a fuller stack from a debugger. The clientrect it is claiming has been repainted is well outside of the window in view, in this case the window was 1900x1143 and it was claiming a paint of 4308x4453. This is tinderbox though so I guess the full page is that wide I wasn't expecting to see paint events from outside of the visible area.
Attachment #341514 - Attachment mime type: application/text → text/plain
That stack looks like it's invalidating a chrome window. Where did you attach the event listener?
(Reporter)

Comment 5

10 years ago
It is attached to the xul browser element for the tab.
It's actually not clear that this is causing dispatch of the DOM event. You want to set a breakpoint at the call to NS_DispatchToCurrentThread in nsPresContext::NotifyInvalidation.
(Reporter)

Updated

10 years ago
Attachment #341514 - Attachment is obsolete: true
(Reporter)

Comment 7

10 years ago
Oops my bad. Obviously there are lots of paints going on, that stack is from something in chrome. Once I caught the stack for the html document I realised immediately what was going on. Tinderbox uses an animated gif for burning boxes, MozAfterPaint is just getting dispatched for every frame.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.