Delay before seeing upload notifications after pasting image from MS Paint.

[Steve James]

Win7/IE11/ckeditor instance in jQuery UI modal dialog.

I am seeing a noticeably long delay before seeing the progress notification when pasting a large image copied from MS Paint into an editor instance. In Chrome, I see the notification right away. In IE, a user may be inclined to think the editor is hung up when pasting a large file.

I think this could be a case of upload progress events not being consistently fired from one browser to another--you may need a smaller period to update progress. I have seen this before. It is important to show a 0% Progress Notification right away before initiating the upload (don't depend solely on progress events), so the user knows something is going on.

[Jakub Ś]

According to #11526 pasting from MS Paint works (tests confirm it).

D&D of images works pretty fast. Pasting images from MS Paint however does not. IMHO it is slow in every browser. Chrome is the fastest but still slow.

When you paste large image from MS paint (tested with 3.5MB image) it looks like CKEditor processes it for a longer minute before any request is sent or notification is shown. When you get irritated and start clicking you are getting busy cursor.

Something that should be checked and I agree - the upload icon should be shown at once.

[Jonathan]

This is too slow in all browsers, though IE11 is the worst. Pasting does not need to come from MS Paint. Pasting in a copy of a photograph via Print Screen and then pasting the buffer can freeze the browser for 30 seconds in IE11.

[Jonathan]

I'd also point out the memory usage in IE11 appears to go up an extra 150MB temporarily during the time that the browser freezes and then backs down again.

[Jonathan]

For IE11 and Firefox we worked around this by compressing the image in editor's paste event.

It now takes 4 seconds instead of 30. The image size changed from 2.7M to 115K. Presumably, if we were allowed to process the image earlier on in the paste event we could shave off even more time. The only downside to this approach is that it doesn't use the Image.onload event because we need the processing to be handled synchronously. My understanding is that in some browsers the image may not be available to manipulate until the onload event fires. It doesn't seem to have any problems in IE11 or Firefox though when passing the raw data.

It would be nice if something like this could occur in the initial paste event and controlled by some sort of config settings.

//make sure pasted images aren't too big, compress if needed
html = html.replace(/<img\s*src="(data[^"]*)/gi, function (match, imageData)
{
	var imgLength = imageData.length;
	if (imgLength > 100000)
	{
		var image = new Image();
		image.src = imageData;

		var canvas = document.createElement("canvas");
		canvas.width = image.width;
		canvas.height = image.height;

		var context = canvas.getContext("2d");
		context.drawImage(image, 0, 0);

		var newData = canvas.toDataURL("image/jpeg", .85);
		if (imgLength > newData.length)
		{
			imageData = newData;
		}
	}
	return "<img src=\"" + imageData;
});

[Steve James]

I am thinking this might be related to #13533, which you have slated for the 4.5.3 milestone. My original impression was that the lack of progress notifications contributed to a perception of "slowness".