iPad touch events performance issues

Scheduler Javascript
#1

Hi there,
I’m having a speed issue with the iPad touch events, when an event finishes it’s drag event it takes about 4-5 seconds where the browser locks up before the loading bar shows to indicate it’s saving. It takes about 3-4 seconds after the drag event ends for the quick info box to appear as well. So about 1 second after the quick info box appears the loading bar appears to start the save process. The save process then takes a further 11 seconds before the events are shown again. So in total it takes 15-16 seconds to adjust an event.

On a PC the entire process all happens in under a second. Both are running on the same network connection and I’m using v4.3.35 Professional of the scheduler.

Is this just an issue with the hardware in the iPad or is there something in the touch events that doesn’t occur on PC slowing things down?

#2

Hi,
Can you please give a link to the problematic page, so we could reproduce the issue?
And which iPad do you use? here is the reference support.apple.com/en-us/HT201471

There shouldn’t be any additional overhead for touch support and most probably the issue happens because iPad has much less computing power than a modern PC, but we can’t tell for sure without seeing what actually happens in the app.

#3

I’m testing on an iPad 4 (Model: MD510X/A).

You can access the login page here: samepage.com.au/purple/signin
And I’ve setup a test account with the username: test@samepage.com.au and the password: test
It should automatically take you to the scheduler from there, if not then using the top navigation go to:
Tools -> Job -> Calendar

#4

Hello,
thanks for the link.
There seems to be two heavy operations, it’s quite possible that thay takes more time on ipad.

screencast.com/t/EVnkxwSpCb - here how the profiler looks if you enable it for drag and drop.
The first highlighted line is synchronous ajax request, which freezes the screen until it’s done. I’m not sure why is it done this way and maybe it’s better to be redone in async way. Although, it’s not likely that this is the bottleneck on the ipad.

The second line - is the data render, which may take quite a lot of time on mobile.
Try adding this code somewhere near scheduler initialization, this patch should speed up data rendering:

[code]// use documentFragment for event rendering
(function () {
var renderData = scheduler.render_data,
locateHolder = scheduler.locate_holder;

var fragments = {};
var locateFragment = function (index) {
	if (!fragments[index]) {
		var fragment = document.createDocumentFragment();

		var originalHolder = locateHolder.apply(this, arguments);
		// some style properties of container that used during rendering
		fragment.clientWidth = originalHolder.clientWidth;
		fragment.style = {
			left: originalHolder.style.left
		};

		fragments[index] = fragment
	}
	return fragments[index];
};
var applyFragments = function () {
	for (var i in fragments) {
		if (fragments[i]) {
			var parent = scheduler.locate_holder(i * 1);
			parent.appendChild(fragments[i]);
		}
	}

	fragments = {};
};


scheduler.render_data = function () {
	// use document fragment for rendering;
	scheduler.locate_holder = locateFragment;

	renderData.apply(this, arguments);

	// put document fragments to calendar layout
	scheduler.locate_holder = locateHolder;

	applyFragments();
}

})();[/code]

Does it fix the issue or it’s still works slowly?

#5

I added in the code you provided but it actually slowed things down another 2 seconds or so, which really just confirms that it’s a hardware issue with all of the javascript that is in play.
I also changed all of the syncs to asyncs just to check (made no difference on load time though), these are mainly all to do with loading and saving additional data that is needed (and can be lost if the user navigates away from the page).

Thanks for your help though :slight_smile: