Multiple readback operations using getImageData are faster with the willReadFrequently attribute set to true about easeljs

[danzen]

We have now been running https://zimjs.org/cdn/1.3.4/createjs.js or https://zimjs.org/cdn/1.3.4/createjs_doc.js for a week and all seems good and the chrome message is gone. Will be looking to adjust the GitHub here in a few days unless anyone has any comments otherwise.

[danzen]

Just trying to look through what uses getImageData() and it seems it is in CreateJS hitTest which is used in handlePointerDown, testMouseOver, masking and filters (some of these might be _ methods). I think maybe if mouseover is true for CreateJS we may as well automatically set willReadFrequently:true on the getContext2D. I am just not sure of any drawbacks to setting the flag to true. Anyone know?

[danzen]

Okay - we have explored this and come up with a potential solution. If anyone would like to try this test version of CreateJS with a flag - we have had a couple of us try it and it removes the warning and seems to work as well as without the flag. We did find that if we put the flag in a other calls to getContext() that it would run more slowly. https://zimjs.com/cdn/1.3.4/createjs_doc_flag.js We will wait to see if we get some more test results before we update here.

[danzen]

We had a couple people over in the ZIM forums test and so far so good. We will adjust our version of CreateJS and run with it for a while. If all looks good we will do a patch here. Cheers. Still, any feedback welcome.

[ArshadSiddiqui]

Hey @danzen Happy to see you addressed this issue. I got the warning for the "cacheCanvas" canvas of DisplayObject as I frequently call context.getImageData() on cacheCanvas.
I think it would make more sense if we have the option of setting flag through function parameter.
For example when I call container.cache() I can set the flag through "options" parameter:
container.cache(x, y, width, height, scale, { willReadFrequently: true });

[danzen]

Sorry - sort of lost the thread here. I think the message is coming up internally a lot... and our solution seems to be running along just fine. So will have another look at it in a bit and do the pullrequest here.