I was just checking the responsiveness of the api on Internet explorer 11 (edge) and i found that creating events on the timeline incurs some lag ( is slow) i.e when i dragged my mouse over the timeline it takes some time ( ms) before i can actually see the events.
The number of resources ( sections ) i had on the view were around 100 and with each section having 1 event each. Also I noticed that the lag and slowness in creating shifts keeps on increasing with the number of resources i.e if i have around 200 resources (sections ) then the lag is more.
I can’t find the link of the thread on where I found the “fix” for it, but I did encounter the same issue you were having (slow on IE).
What I ended up doing is turning off “update_render”.
On my initialization I basically have this:
/* this configuration is for IE since it slows down the calendar a lot on that browser */
if (isIE()) scheduler.config.update_render = false;
The function “isIE” is defined as:
/* used to check if client is IE */
/* needed since IE seems to be slow when rendering data */
function isIE () {
if (navigator.userAgent.indexOf('MSIE') !== -1 || navigator.appVersion.indexOf('Trident/') > 0) {
return true;
}
return false;
}
The only drawback is that the custom CSS styles won’t get applied on every calendar render, but on our calendar, that isn’t really an issue. Besides, we’d rather have speed than perfect CSS styling.
Anyway, that drawback, just to add, only affects IE. Since most of our clients are Mac users (probably about 90/10), that fix’s drawback is hardly an issue nor noticeable. Overall satisfied with that approach.
the update_render property is set to false by default ( ) and it will affect the performance only in cases when we have surrounding events around the moved/new created event.
What i was referring to as lag in creating events is i think related to how the the shift is rendered when we move the mouse after hitting the mousedown event.
I think we doing a lot of stuff ( checks/logic ) in the function ( scheduler._on_mouse_move ?? ) which is responsible for creating events by dragging. I mean we might have to perform all this checks and logic to implement myriad number of functionalities and events the scheduler timeline API provides.
But this doesn’t mean that we should overlook the API’s responsiveness and speed ( esp. in slow browsers - which we somehow have to support looking at our target audience/users ).
I think there should be a bare bones faster version for these methods (esp create,move,drag etc ) without all the add on’s and if we wish to later add the functionalities then these methods can be somehow extended ( knowing beforehand that these add on’s might slow down these methods ).
I mean whats the point of all those add on’s/functionalities if I cannot do somethings basic as dragging or creating an event properly/smoothly in Some Browsers ( esp. Internet Explorer ).
While doing so can take a lot of time and thinking, Meanwhile can somebody please help me in Monkey Patching the Shift Creation Method so that I can get rid of most the additional functionality and make this method bare bones so that I am able to render the Shifts on the view more smoothly and without any lag. I am only concerned with event callbacks once I am done with creating events and hit the mouseup event.
I really really need this to make it happen. Moderators, old users kindly help me with this one. Any Help would be greatly appreciated.
Get a guaranteed answer from DHTMLX technical support team
under the most suitable support plan
) and it will affect the performance only in cases when we have surrounding events around the moved/new created event.