Our pure JavaScript Scheduler component


Post by Robert Hirst »

How much re-rendering of other events should be expected when updating a single event?

For me, changing a single event causes a large amount of time (nearly 100ms!) to be spent by the scheduler on a renderFromRow call. Part of that is that I need a fairly complex renderer, as I'm using event nesting, but even so the individual calls to the custom renderer are in the region of 1.5-2ms.
renderFromRow.png
renderFromRow.png (59.67 KiB) Viewed 1247 times
In total, during the update I profiled above, there were 37 calls to my custom render code during setStartEndDate, roughly the number of items on my schedule view at the time, so it seems like updating a single event is (for me) causing the whole visible set of events to be re-rendered.

Is this the expected behaviour?

I can understand it would be needed when using eventLayout: 'stack' or 'pack', as the row or event heights might change, but I'd like ideally to just have the single event I'm changing re-rendered and re-positioned as I'm using eventLayout: 'none'.

I might get messages to update a lot of events in a sort space of time, and this can cause a bit of a UI freeze due to the amount of work each setStartEndDate causes.

If this is just how it must work at a fundamental level, I'll invest the time in putting in a buffer for my real time messages to try and save them up a bit and work through updates in within beginBatch()/endBatch() on the eventStore to try and limit the amount of render calls, but I thought I would just ask first as perhaps there is a better solution I've missed.

Many thanks for any help which can be offered!

Post by johan.isaksson »

Hi,

We do not currently take the eventLayout into account when determining what needs redrawing. Changing an event on a row triggers drawing of all events on that row and below, since the change might (in the other modes) affect the layout of those.

But as you say, this could probably be simplified when not stacking or packing. I have created a feature request on changing this behaviour:

https://app.assembla.com/spaces/bryntum/tickets/8093
Best regards,
Johan Isaksson

Post by Robert Hirst »

Thanks, I'll keep an eye on that for future versions.

I've implemented an incoming message buffer now, which processes the incoming websocket messages using the batch functions on eventStore, so the performance is acceptable enough even when I'm getting a 40 or 50 updates in a single second.

If this feature does get added, then I'll probably detect when the buffer is below a certain threshold, and apply changes 'live' without starting a batch or triggering the refresh afterwards.

Post Reply