 |
Figure 10 shows the breakdown of the execution time for updating a single image with higher fidelity data. The figure shows that the API calls to replace the image (Display) account for a small portion of the overall latency, similar to what we saw for Outlook in Figure 8. More significantly, the figure shows that for large documents, roughly 60% of the time for upgrading the fidelity of an image is spent making sure the user did not modify the image we are about to update (Detect). Detecting modifications is time-consuming because PowerPoint's API does not support querying whether a component has been changed. Instead, we detect modifications by saving a temporary copy of the presentation on disk, parsing this copy, and comparing it with the local proxy copy of the presentation. Writing out a copy of the presentation to disk dominates the cost of all other factors in the total time taken for detecting modifications.
This experiment represents a worst-case scenario of having to write out the entire document to upgrade a single image. Under normal operation, we expect modification detection to benefit from PowerPoint's ability to write out modifications incrementally, as well as from the possible batching of multiple component upgrades into a single operation (i.e., updating a set of images at a time). Detecting modification is also only necessary if we allow editing of partial-fidelity images. If we disallow editing partial-fidelity images, then the cost to upgrade an image is just a few milliseconds over the time it takes to transmit the image over the bandwidth-limited link.
In any case, the large modification detection time results from specific limitations of the current PowerPoint API (which could be easily fixed by adding an API call for checking if a component has been changed), and is not a fundamental limitation of either adaptation-aware editing or progressive update propagation.