Reporter@ - Thanks for filing this issue. Could you please provide any manual test case to check this issue from chrome TE end. It will be helpful in further triaging.

Thanks!

I'm going to try to illustrate but the code is scattered over a few files.

The page in question can be found here: http://tissuestack.org/desktop.html

There is a loop over the tile range which calls a renderTile method which contains:

        preContext.drawImage(image,
            imageOffset[0], imageOffset[1], width, height, // tile dimensions
            canvas[0], canvas[1], width, height); // canvas dimensions

I'm in this version that's online using an offline canvas for pre-render but it really doesn't change this particular issue which occurred as I described originally in the versions that renders to the canvas directly already.

Similarly the problem was not alleviated by keeping the tiles in memory once loaded: 

                if (this.cache[src] instanceof Image) {
                    var args = {
                        image: this.cache[src],
                        timestamp: timestamp,
                        imageOffset : [imageOffsetX, imageOffsetY],
                        canvas: [canvasX, canvasY],
                        dims: [width, height],
                        delta: [deltaStartTileXAndUpperLeftCornerX,
                                deltaStartTileYAndUpperLeftCornerY],
                        };
                    this.renderTile(args);
                } else {
                    var imageTile = new Image();
                    imageTile.crossOrigin = '';
                    imageTile.src = src;

The 'queue part' is a temporary setInterval that is kicked off after user input and stopped once the events have been processed, taking the latest only every x millis and calling the renderTile via drawMe():


		this.queue_handle = setInterval(function() {
			if (_this.requests.length == 0) {
				_this.stopQueue();
				return;
			};

			var latestRequest = $.extend(true, {}, _this.requests[_this.requests.length-1]);
			_this.clearRequestQueue();

	 // ... more stuff
                _this.canvas.drawMe(latestRequest.timestamp);
}, this.drawingIntervalInMillis);


The default value for the 'drawing interval is set to 100ms. This used to be good compromise for all browsers, chrome performed better than others, I could actually reduce the interval to 50ms as well which would make for smoother appearance.

Hope that helps. I realize it's not an ready to run code 'test case', sorry, but to code it I would have to dissect the entire codebase. If nothing else it should hopefully demonstrate the difference by using the test site I provided given you have a similar os setup.

sorry, forgot to add. the aforementioned drawing interval can be played with by adjusting the value in the settings section: http://localhost/desktop.html#admin

also, the issue can be most prominently seen in the big (middle) canvas because even with the Image object in memory, the interaction that used to be nice and smooth is now jerky.

Thank you for providing more feedback. Adding requester "brajkumar@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Could you give more explicit steps to reproduce the problem? I'm not quite sure which part is no longer smooth.

Also, it would be helpful if you could record a Chrome trace of the problem and attach it here: https://www.chromium.org/developers/how-tos/trace-event-profiling-tool/recording-tracing-runs

(Note that the trace file contains information about all open tabs, so you might want to record it using a fresh profile.)

Apologies everyone. 

it seems to have been caused by the horrible html layout of the page, perhaps in connection with my smaller screen dimensions, in particular a "overflow-y: visible" style setting. when I change the applications zoom level via the mouse wheel, it exhibits that sluggish behavior but the moment I set the overflow-y to hidden it's crazy fast again. I don't know why exactly but it's clearly not the canvas, the layout of that page is beyond bad and uses jquery mobile ui for the desktop.



once again, sorry for wasting your time.

No problem, let me close the report. If you think there's a problem with layout performance and are able to narrow it down, please file a new bug.