What steps will reproduce the problem?
Create a large SVG image with lots of nodes and add a lot of event listeners to
it and then add the whole tree to the svg document.
What is the expected output? What do you see instead?
Ideally, this should be one message to flash. Instead, there is one message for
the xml, and one message for each event listener that was added into that tree.
If the child is a document fragment, there is one message to suspend redraw,
another message for the xml, and a final message that unsuspends and adds all
the event listeners.
The one-message ideal solution is difficult to implement because the
addEventListener code is in a routine which is decoupled from the code that
sends the xml to flash and so it is not clear how we can bring those messages
together. Perhaps suspending at a higher level might do it.
The next best solution is to use the suspend and unsuspend technique for more
than just document fragments in order to consolidate the addEventListener
messages whenever nodes are added. Consider that it is more likely that a
script author will be building a large detached <g> or <svg> element and add
that to the svg document rather than using a document fragment, so the
optimization coded for document fragments should apply in this case as well.
By delaying the addition of elements to the live document until the very end,
heavy svg scripting currently produces messages in the O(n) level: a minimum of
1+n*p, where n is the number of nodes and p is the average number of event
listeners per node. But after applying the change above, the minimum number of
messages drops to 2 for a tree of nodes with event listeners. This is not the
panacea for performance, but every bit helps and heavy SVG Web scripters should
take note to build up their SVG elements as a large tree before adding to the
live SVG document if they want this performance benefit. And use a document
fragment if you have a forest instead of a tree.
Note that the figures above include another optimization. The current
implementation of processAppendedChildred sends a message to flash to suspend
redraw. This is not meant to save rendering time, but merely as a way to
trigger the message queuing code for the list of event listeners. Ironically,
the code is sending a message in order to save messages. But that does not
always work ;) The proposed solution is to also eliminate this extra message
by adding a flag to the JavaScript side of suspendRedraw and unsuspendRedraw in
order to tell them not to send the suspend message to flash and instead to just
start queuing or dequeuing messages.
Original issue reported on code.google.com by grick23@gmail.com on 30 Jun 2010 at 2:47
Original issue reported on code.google.com by
grick23@gmail.com
on 30 Jun 2010 at 2:47