Html2canvas: iFrame-less option, and other speed improvements

[mudcube]

I'm working towards getting the speed of a basic renderer down, currently the most basic rendering takes over 100ms on my computer. iFrame generation takes 60ms on it's own for me. I bypassed the createWindowClone and rendering still works the same—it looks like the iFrame is for Chrome and "background-images", is that the only reason? Would you be interested in an option to turn iFrame rendering off, e.g. option.useIFrame = false (true by default)

Another thing I'm noticing is there are a lot of objects being created on each render that don't need to be recreated (could be cached). Some of the easiest to cache would be Support, ImageLoader, much of the code inside of Font() could be setup once and cached, and a bunch of other little things like that. What do you think about a way to create a reference to html2canvas that persists:

var context = new html2canvas();
context.render(document.body).then(function(canvas){ });

[niklasvh]

The iframe is used for a number of reasons, including:

• Avoid mutating the original DOM. A lot of of the features in html2canvas requires to modify the DOM, by using a clone, the original isn't affected
• Allow async rendering. Since it takes a snapshot, the parsing and rendering can be done in a non-blocking way as the DOM of the clone won't change during the time.
• Don't force the scroll position to top of the page. Since it takes a snapshot, the scroll position can be assigned to the same snapshot, allowing the original DOM to be scrollable and won't need to be fixed to the top.

Due to those reasons, I don't see it feasible to make the use of the iframe optional.

Caching those helper utils could be done. The same iframe could be potentially used as well if you want to render multiple times in succession.

[mudcube]

Ahh, I see, thanks for the insight. I'll take a deeper look into caching options.

[usmonster]

:+1: for caching wherever possible.

[Robinfr]

:+1: all for improving the speed. It's one of the major downsides at the moment that is starting to turn me away from using this.

[bdely]

Is there a way to speed up the rendering because it is taking 8 seconds to create the snap shot, and that 8 seconds adds up, because I need it to take anywhere from 15 to 50 snap shots for creating thumb nails of tiles. Is there some way to have it not block the UI for the 8 seconds, I could live with that time if it wouldn't block the UI.

[programmin1]

Just curious, in what browser do you notice this? It is a bit slow but I don't think it could use WebWorkers in background threads because DOM isn't thread-safe and allowed from that context?

[bdely]

I notice it in every browser. Ya i know it will not work in WebWorkers, wish it could though lol. I have tried to clone the element and put it in an iFrame and have the code in the iFrame run the snap shot so that it would do the work and not the main page but it doesn't seem to work.

How long does one snap shot take for everyone else?

[niklasvh]

@bdely Are you using 0.4.1?

[bdely]

I am using 0.5
Just tested the latest build and it takes between 4 and 5 seconds.

[Bigous]

Same to me using 0.5-alpha2... 4-6 seconds each snap.

[Bigous]

Version 0.4.1 takes 0.7s each snap, but it does not suport svg.

[bnolan]

I would absolutely use a version that didn't use iframes, that would be a great example. In SceneVR, I'm rendering dozens or hundreds of divs to canvases, and creating the iframe causes bad lag that results in dropped frames and judder in the oculus rift.

@mudcube do you have a fork with the no-iframe / re-use iframe code patched in? I'm happy to submit a PR, I really need this function. :)

[bnolan]

I hacked this up in scenevr/html2canvas and the performance for rendering many divs is about 100x faster. Would you accept a PR for cacheIframe: true?

[brcontainer]

Try create a loader in "overlay", eg with jQuery:

• http://www.jqueryscript.net/loading/Creating-A-Loading-Indicator-with-jQuery-CSS3.html
• Repo: https://github.com/ninjaonsafari/jquery.loading-indicator

[bnolan]

I'm about to use html2canvas to create a web texture component for aframevr - has there been any progress on reusing an iframe instead of creating a new one for each render?

[mudcube]

One thing to speed things up would be to use a faster Promise implementation. At least, this is what I found back in Dec. It looks like the promise shim was dropped from the dist, which is great. Bluebird will be much faster than native Promises however.

@bnolan Here's a GIST. It's modified from 0.5 alpha-1. I may of disabled some features but forget what exactly (you would notice this by an early return). My main interest was in paragraph rendering.