Bug 3273 - XSL Transformations should occur on a separate thread
: XSL Transformations should occur on a separate thread
Status: RESOLVED WONTFIX
Product: WebKit
Classification: Unclassified
Component: XML
: 412
: All All
: P2 Normal
Assigned To: Nobody
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-04 20:26 PDT by Dave Hyatt
Modified: 2010-09-15 08:52 PDT (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dave Hyatt 2005-06-04 20:26:42 PDT
XSL Transformations currently occur on the UI thread.  This means that a long transformation could end 
up beachballing Safari (or another Web Kit application that uses it).  The transformation should take place 
on a separate thread and call back to the UI thread once complete to avoid blocking the UI.
Comment 1 Eric Seidel 2005-12-27 13:29:39 PST
Assigning bugs which hyatt is not actively working on to "nobody" for clarity/consistancy.
Comment 2 Alexander Willner 2008-11-24 21:11:22 PST
Just to update this old ticket: seems to be still valid for the current version. I've duplicated some part of the code within the following example in order to create a 10 MB file:

http://www.w3.org/2001/05/xslt-example/REC-xml-20001006.xml

In contrast to a 10 MB HTML file Safari is "beachballing" while rendering/transforming the page.
Comment 3 Adam Barth 2010-09-15 00:47:38 PDT
Realistically, I don't think we're going to do this.  The DOM isn't threadsafe.
Comment 4 Alexey Proskuryakov 2010-09-15 08:44:00 PDT
The document is serialized to string for XSL transformation, so the actual transformation doesn't touch the DOM. As long as it's the transformation that takes most of the time here, it could be beneficial to use a separate thread.

I'm not sure if it's realistic to expect that we work on this, and whether it's a practical issue. Safari doesn't beachball even on the example from comment 2 on modern desktop hardware.
Comment 5 Robbert Broersma 2010-09-15 08:52:07 PDT
At Xopus we use some very complex XSLTs, and some of our clients have XSLTs that need optimization or are optimized for MSXML. Processing in those cases can take several seconds, and async support would definitely be very helpful to the Safari users and be a huge advantage over other browsers.