We Keep Coding

Adobe Animate HTML5 Canvas issue w/ Google Chrome only. Animation is Lagging

We have published an HTML5 Canvas through Adobe Animate. And have reduced the file size down to under 2MB total and it loads in under 3 seconds on all browsers. But we are having frame (FPS) lagging issues on Google Chrome only.
We deactivated the 2D canvas chrome accelerator in Chrome Flags, but are still having issues getting the animation run smoothly at larger screen sizes.
Is there a way to publish the canvas in Animate so this doesn't happen? Or is there some JavaScript code to allow for Chrome to load the animation at the correct FPS?
We have tested in IE, Edge, and FF and all of those browsers run smoothly. It is only Google Chrome that is experiencing the issue.

Having profiled this, I have found that the code makes a large number of calls to drawImage. On my machine, it spent 86% of its time in calls to drawImage.
Its possible that its redrawing the large images every frame. See if there is a way to stop this from occurring.
Try removing the background images and having just the lines, if the lag disappears, you have your answer.
Potentially relevant:
Why does chrome struggle to display lots of images on a canvas when the other browsers don't?

Why does IE10 Mobile render my in-canvas PNG incorrectly?

I'm using a "mask" image as an input, draw it to a canvas, then use getImageData to detect the colour of pixels.
This works perfectly under Safari, Chrome, Firefox, their mobile versions, and Android's stock Browser. It also works in IE11 (the only version I currently have as a Virtual Machine).
Under IE10 Mobile, its display is completely wrong.
I've put together a JSFiddle to demonstrate the problem. On a compatible browser, it should show two grids. The first is white and red (red is the mask colour I chose), and the second is the processed version; black and white.
Like so:
However, IE10 Mobile on Windows Phone 8 renders it completely wrong, sort-of like this:
(Ignore the JPEG artifacts, that's a side effect of sharing a screenshot).
The actual drawing code is extremely simple:
var source = document.createElement('canvas');
source.width = this.width;
source.height = this.height;
source.getContext('2d').drawImage(this, 0, 0);
body.appendChild(source);
As you can see in the fiddle, I've attempted to disable image smoothing in a variety of ways without success. Does anybody know why this doesn't work, and how to fix it?

Full screen background images scaling in IE11 strange behavior?

I stumble upon a strange behavior on one off my websites. The website makes use of superbgimage.js jquery script, which scales an image fullscreen and is part of a slider.
Now on Chrome and Firefox the images are scaled as expected (mostly scaled down as i make the images intentially a little bigger). The images are not looking scaled in IE11. The strange thing is when i hit F12 (to see developersmode) and hit F12 again, the images are scaling correctly in IE11.
This only occurs when F12 developers window is pinned not when the developers window is "free floating". So i guess it has to do with the browser height in IE11 not the same on initialize and after hitting F12
I already have
img {-ms-interpolation-mode: bicubic;}
Any suggestions?

webkit performance analysis on image resizes

Doing performance profiling using the chromium tracing panel I've found many image resizes, especially on scroll.
I've removed all (I think) of the image resizes from the front-end, and simplified the dom for testing purposes to be mostly just static image elements at this point.
I have a few theories:
All images resize/resample internally
looking at the chromium source, I've found evidence that everything is calling "NativeImageSkia::resizedBitmap"
Using a retina display mac causes the images to be sampled up
This is backed up by seeing a "dst_pixels" size 4x the src_pixels in the tracer
Can someone confirm or deny any of the above?
Also:
Is it possible to track down which image is being resized?

After working with some of the guys at google I've determined that this is in fact a webkit bug related to the handling of the high PPI monitors on the retina macbook pros.
You can see on a non-retina display (same mac, external monitor) there are only "Image Decode" events. Same content, same mac, rendered on the retina display you can see there are both "Image Decode" and "Image Resize" events.
Tested with 24 and 25.0.1329.0
Also, it is currently not possible to find out what image is being resized from the runtime instrumentation in chrome.

create a canvas from a css resized image, mantaining the browser interpolation on it

I'm trying to draw a css resized image in a canvas (I'm using mootools, but it really doesn't matter):
var width = $('canvas').get('width');
var height = $('canvas').get('height');
$('image').set({ 'width': width, 'height': height });
$('canvas').getContext('2d').drawImage($('image'), 0, 0, width, height);​
Everything works fine in firefox, but not on webkit.
The image in FF is drawn with the browser interpolation (which is good), but on webkit it's not interpolated.
Here's the fiddle
http://jsfiddle.net/a2co/KyhEE/
Anyone knows how can I solve the problem?
thanks
edit:
i added an image to quickly show what i want to do.

Unfortunately this may be discrepant between browsers for some time, since the spec says that the spec doesn't care:
This specification does not define the algorithm to use when scaling the image, if necessary.
But hold on a minute: The canvas representation of your fiddle in Firefox, Webkit, Chrome and IE9 are all consistent. The only inconsistent piece that I see is how webkit scales the <img>. Here's Firefox 10, IE9 and Chrome 19 (from top to bottom):
WebKit (both chrome and Safari) is the odd one out here, and its not a Canvas thing. The <img> alone in WebKit looks different, all of the canvases look the same!
Chrome (possibly webkit) has been changing their anti-aliasing madly these past few months (very evident if you use the developer channel of chrome because it will often be broken in some way with respect to canvas drawing)
Anyway do you see something different here? Nothing looks out of the ordinary.
Edit: There's a webkit CSS property: image-rendering: -webkit-optimize-contrast which allows the image to look just as bad as the Canvas. This leads me to believe that how the Canvas looks on WebKit is an honest bug. In other words, in WebKit, its as if image-rendering: -webkit-optimize-contrast is always on for canvases, with no way to turn it off.