Last Comment Bug 239074 - onpaint events not working
: onpaint events not working
Status: RESOLVED FIXED
[firebug-p3]
:
Product: Core
Classification: Components
Component: DOM: Events (show other bugs)
: Trunk
: All All
: -- normal with 2 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://www.croczilla.com/~alex/onpain...
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-03-29 07:22 PST by Alex Fritze
Modified: 2011-10-21 11:28 PDT (History)
12 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Alex Fritze 2004-03-29 07:22:40 PST
Mozilla doesn't seem to generate any onpaint events.
Testcase at http://www.croczilla.com/~alex/onpaint.html:
Comment 1 Alex Fritze 2004-03-29 07:25:01 PST
<html>
  <head>
    <script>
      function init() {
        window.onpaint=function(){alert("paint")};
      }
    </script>
  </head>

  <body onload="init()">
  </body>
</html>

This html file never pops up any alert boxes. Other related events such as
onresize work fine.
Comment 2 Boris Zbarsky [:bz] 2004-03-29 19:45:53 PST
I don't believe we've ever done this, in fact... and should we start?  onpaint
is "DOM0", right?
Comment 3 Robert O'Callahan (:roc) (email my personal email if necessary) 2004-03-29 20:23:51 PST
Why do we want to do this?
Comment 4 Alex Fritze 2004-03-29 23:16:49 PST
I (In reply to comment #2)
> I don't believe we've ever done this, in fact... and should we start?  onpaint
> is "DOM0", right?

Yeah, this is DOM0 afaik. There is code that suggests that this was working once
(or was planned). E.g. nsEventReceiverSH (dom/src/base/nsDOMClassInfo.cpp) knows
about "paint" as a valid event name.
Also our documentation mentions it:
http://www.mozilla.org/docs/dom/domref/dom_window_ref69.html

(In reply to comment #3)
> Why do we want to do this?

I don't know whether there are any legitimate uses.
I was wanting to use it for timing document loads including painting from JS.
From a casual reading of widget/src/windows/nsWindow.cpp I got the impression
that this DOM event would be fired after painting (nsWindow::DispatchEvent(){...
mEventListener->ProcessEvent() ... }).
Comment 5 Dave 2006-06-25 20:53:42 PDT
Here's a reason I can think of to do this:  I've had cases where I've had to use JavaScript to position stuff absolutely in a relative manner, by calculating from surrounding element sizes and positions, etc... and using resize/scroll/etc events I'm able to do reasonably well with this technique... except in one case:  when the user changes their font size preference... there's no event for me to capture that I'm aware of!  Currently the user has to refresh the window to get it to redraw correctly in such a case.  Wouldn't a paint event help me solve this?  For surely it would be repainting the window in such a case and firing this event. Then I could simply run through my routine and see if anything needed to be moved during a paint event.  Maybe I wouldn't even need to bother with the other events, we'll see...
Comment 6 Robert O'Callahan (:roc) (email my personal email if necessary) 2006-06-26 02:25:23 PDT
Probably we should fire on onresize event when the text size changes. Sorta bogus but it would work for all those people who do manual layout on onresize.
Comment 7 Dave Townsend [:mossop] 2007-02-23 17:53:46 PST
An xulrunner app I'm developing displays a grid of images. It uses a as many columns as it can fit in the window size. Obviously I need to know how big the area is to do this and right now I have to put in about a 100ms delay after the load event before attempting to read that since at load the size is 0.

Presumably this event would be after layout has been done so I would actually get a sensible size without the hacky delay so this would be real useful to me.
Comment 8 Alex Vincent [:WeirdAl] 2008-11-18 15:06:24 PST
I was wondering why paint events weren't working like I remember them once upon a time... now I know.

Paint events are also useful when you want to pay attention to mutations in a page - and ignore those that don't change the rendering.  For instance, I have a bunch of mutation event listeners which - simply by being attached - degrade performance.  It'd be so much easier with a paint event.
Comment 9 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-11-18 15:10:26 PST
We've implemented MozAfterPaint.
Comment 11 Martijn Wargers [:mwargers] (not working for Mozilla) 2008-11-18 15:13:30 PST
There is now MozAfterPaint event, that might be what you need.
https://developer.mozilla.org/en/Gecko-Specific_DOM_Events
Bug 450930 is the place where it was implemented.

Although, I really would find it useful to know the difference between painting
because of a scroll and painting because of some invalidation.
Comment 12 Martijn Wargers [:mwargers] (not working for Mozilla) 2008-11-19 13:48:20 PST
Also, for me, it would be very useful to be able to listen for MozAfterPaint events on certain elements only, instead of the whole window.
Comment 13 Martijn Wargers [:mwargers] (not working for Mozilla) 2008-11-19 14:17:01 PST
Sorry for spamming, what I especially would like is to detect when an elements has changed in width/height. So a way to detect that kind of invalidation would be great.
Comment 14 Robert Hurst 2011-10-20 01:30:49 PDT
I think that we still need this event. This is a prefect opportunity to allow JavaScript developers to greatly improve the performance of web applications that heavily modify the DOM or CSS. Currently Developers has tried solving DOM performance issues by shoving all new nodes into a DOM fragment, then into the DOM tree, so the browser only reflows once and prevent it from having a 'cardiac arrest', an out of control cascade of reflows.

What if this event could block reflow by returning false? This would enable JavaScript to insert as many nodes and mess with the page without a cascade of reflows.

If you were to build a display system from scratch for an operating system would you not have a way to manually control draw cycles? We are not just coding documents anymore. If we really want to empower developers then we need to give them a way of controlling reflow. I think this is the most consistent.

I prepose the following.

1.) Gecko wants to redraw because something in the DOM has changed.
2.) It fires an onpaint event.
3.) If a function is binded and that function returns false the reflow is delayed a cycle.
4.) If the binded function continues to return false the redraw will continue to be delayed.
5.) If the function returns anything other than false, the page redraws once using the current DOM tree and CSS.

Here are some possible use cases:
- Single page applications.
- Libraries that handle the DOM and/or CSS such as jQuery
- Games that use the DOM (Though this might not be the best idea).
- Possibly canvas, but that depends on how Gecko handles canvas redraws.
Comment 15 Jacob Hansson 2011-10-21 07:01:08 PDT
Robert: Your suggestion generated a bit of buzz on reddit, see sporkexec's suggestion for an improvement to the idea:

http://www.reddit.com/r/javascript/comments/ljm7p/should_javascript_be_able_to_control_reflow/c2t8fva
Comment 16 Martijn Wargers [:mwargers] (not working for Mozilla) 2011-10-21 09:17:32 PDT
I think there is already something for that that might be doing what is wanted there:
http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/RequestAnimationFrame/Overview.html

Implemented in Mozilla as  mozRequestAnimationFrame :
http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/base/nsIDOMWindow.idl#421
Comment 17 Boris Zbarsky [:bz] 2011-10-21 09:30:27 PDT
That would not address the use case of comment 5.

The use case of comment 14 is already solved: we don't reflow while a script is running unless the script _explicitly_ requests layout information.  The "build the DOM in a document fragment" hacks are not really that relevant in a world with lazy reflow, lazy style reresolution, and lazy frame construction (which is where we are now).  Or is comment 14 talking about preventing reflow while running things off timeouts?
Comment 18 Robert Hurst 2011-10-21 11:28:58 PDT
(In reply to Jacob Hansson from comment #15)
> Robert: Your suggestion generated a bit of buzz on reddit, see sporkexec's
> suggestion for an improvement to the idea:
> 
> http://www.reddit.com/r/javascript/comments/ljm7p/
> should_javascript_be_able_to_control_reflow/c2t8fva

Yea I see that. He has a good point and so I've revised my proposal. http://www.reddit.com/r/javascript/comments/lk6ck/how_javascript_reflow_control_might_look

Note You need to log in before you can comment on or make changes to this bug.