On Jan 5, 2010, at 4:50 PM, Chris Marrin wrote:
There is a bug posted (https://bugs.webkit.org/show_bug.cgi?id=8191)
about the implementation of DOMAttrModified events. The
implementation is quite far along and there are many posts begging
for it, but it is stalled because of one comment (https://bugs.webkit.org/show_bug.cgi?id=8191#c17
) which is opposed to it on the grounds that it would be slow and
buggy, and that there is an alternative proposal.
I'm interested in this issue because of WebGL. There is currently an
implementation of a subset of X3D in WebGL (http://x3dom.org), which
allows you to add a 3D scene as a hierarchy of nodes rendered by
WebGL. They have an example of using mutation events to allow the
DOM to change the attributes of nodes in the hierarchy and have that
redraw the rendered scene. That's just one of the many uses of
mutation events. Others are sprinkled throughout the bug log.
I don't think the discussion here should be whether or not mutation
events a A Good Thing or not. They are being put to good use in
Firefox already and they are part of DOM Level 2 already. The
question should be whether they would add value to WebKit without
penalizing performance when they are not used. I think there is
enough evidence to say that they would be useful for many purposes.
And from a cursory look at the patch it appears that, while there
would be overhead in doing the checks, it would be fairly minor
unless an event were actually attached to an attribute. And more
might be done to short circuit earlier and further reduce the
overhead. But I haven't actually tried the patch to see what the
baseline overhead is.
If we reach consensus that we should add this feature, I would be
happy to get some numbers about the overhead.
I think DOM mutation events in general and DOMAttrModified in
particular are not so great. It's pretty hard to implement mutation
events not to hurt performance when they are not used, though
possible. However, it's even harder to avoid even a single mutation
event anywhere putting the whole DOM into slow mode. In addition,
mutation events have poorly defined semantics which make it much more
complex to ensure that DOM code is correct. They tend to be fired at
awkward points, often in the middle of compound operations, and they
are allowed to themselves make arbitrary DOM mutations. Coding
defensively against this adds a lot of complexity, for the mutation
events we already support. And it has been a major source of bugs,
including security bugs.
If at all possible, I would prefer to help develop and promote a
superior alternative to DOM events rather than extending our DOM event
support.
That being said, this is not a strong line in the sand. If enough
interesting content comes to depend on DOMAttrModified, then it may be
worth implementing it notwithstanding the risks.
- Maciej
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
