Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

optimize event rerendering #3003

Open
jcope2013 opened this issue Jan 14, 2016 · 14 comments
Open

optimize event rerendering #3003

jcope2013 opened this issue Jan 14, 2016 · 14 comments
Milestone

Comments

@jcope2013
Copy link

@jcope2013 jcope2013 commented Jan 14, 2016

every time I drag an event, eventDestroy is called for every event in the view instead of only being called for the event that was just dragged, alongside this the eventAfterRender is called for every event in the view instead of only being called for the event that was just dragged, this leads to duplication of extra javascript work

Replicate:

  1. Open Console
  2. Drag Event
  3. You will see eventDestroy and eventAfterRender logs for events in the calendar including some listed twice

screen shot 2016-01-14 at 1 52 45 pm

http://jsbin.com/monativoku/edit?html,css,js,output

@arshaw

This comment has been minimized.

Copy link
Member

@arshaw arshaw commented Jan 15, 2016

anytime one single event needs to be rerendered, there needs to be some sort of rerendering for all of the events, because the positioning of the new event may affect the positioning of the others. We could do some optimizations though (only rerender events in the given row or something).

however, you bring up a good point about reusing the DOM nodes from one event render to another

@arshaw arshaw added the Discussing label Jan 15, 2016
@arshaw arshaw changed the title eventDestroy and eventAfterRender unnecessary called extra times optimize event rerendering Jan 15, 2016
@matiaslarsson

This comment has been minimized.

Copy link

@matiaslarsson matiaslarsson commented May 10, 2016

For reference, it turns out ui-calendar was the culprit. Skipping it and using Fullcalendar directly from Angular made everything run much much faster.

I guess this also could be why Chrome has UI lags of up to 4 seconds after dropping an event in my month view containing 150-200 events? (Or when I'm inserting a temporary inverse-background event during drag and drop start).

Optimization of event rendering would be very appreciated!

Some points, right off the top of my head (which has a Fullcalendar month view context and has started entering a vacation in one more day phase ;))

  1. If not already in place, could we add a quick render path which only rerenders the two affected days if the event is not spanning multiple days?
  2. Does fullcalendar currently "render" the +61 more etc. events hidden from a day in the month view or could it possibly skip them? (Just adding the dragged event to the affected day if it matches the sort criterias and removing the last one + updating the "More"-counter)
  3. Could using CSS Flexbox rendering instead of tables speed up things like https://github.com/intljusticemission/react-big-calendar states. (I hear people needing support for old IE crying now)
@marcoancona

This comment has been minimized.

Copy link

@marcoancona marcoancona commented Apr 19, 2017

It would be useful at least to pass eventAfterRender information whether or not something has changed in the visualisation. I have a relatively intense processing on this callback and all means to avoid executing it for all events every time would be useful.

@evanjmg

This comment has been minimized.

Copy link

@evanjmg evanjmg commented Oct 26, 2017

@arshaw any update on this? Are there any performance benefits by updating a single event with updateEvent vs rerendering the entire event system with renderEvents?

@arshaw

This comment has been minimized.

Copy link
Member

@arshaw arshaw commented Oct 30, 2017

The best approach would be to break down each view into more self-sufficient subcomponents. For example, have each month's week render events independently. I started to down this route, and essentially started creating a new UI framework, which felt wrong. I plan to use a virtual DOM system like React (or Preact) to achieve this, or something like it.

@ohmmho

This comment has been minimized.

Copy link

@ohmmho ohmmho commented Mar 26, 2018

Hi @arshaw, Is there any update on this issue?

We really would appreciate a way to just rerender the updated event, or even the events in the same row. We've got lots of events on a timeline view (130 more or less), each event related to a resource, resizing or dropping events on this context is really wasteful.

We understand that's not an easy fix, but do you have any possible workaround meanwhile?

Thanks for all the work done :)

@ohmmho

This comment has been minimized.

Copy link

@ohmmho ohmmho commented Apr 30, 2018

@fazr thanks! yes, please :) it would be really helpful!

@laurabelli

This comment has been minimized.

Copy link

@laurabelli laurabelli commented Jun 1, 2018

@fazr Can you please share your solution? I'm working fullcalendar , but the rerendering is very slow!

@xanderyst

This comment has been minimized.

Copy link

@xanderyst xanderyst commented May 22, 2019

Any updates to this?

@nakhhuan

This comment has been minimized.

Copy link

@nakhhuan nakhhuan commented Jul 11, 2019

Any update on this @arshaw ? I'm using premium version 4.x but too slow.
Do you have any workaround meanwhile? Thanks.

@ryanjkelly

This comment has been minimized.

Copy link

@ryanjkelly ryanjkelly commented Jul 16, 2019

I don't have a CodePen to show this, but I just tested out using FullCalendar's (v4.1.0) Vue component, thinking that maybe Vue would handle the DOM for FullCalendar and possibly make event rerendering faster, but it didn't.

I tested out 50 resources with 30 events in each (1500 events in total), then I changed the background color of a single event, and it took about 1-2 seconds to re-render.

@azhard4int

This comment has been minimized.

Copy link

@azhard4int azhard4int commented Sep 20, 2019

@ryanjkelly I am on the same boat like, were you able to improve the event rendering performance?

@ryanjkelly

This comment has been minimized.

Copy link

@ryanjkelly ryanjkelly commented Sep 20, 2019

No, but I did just test 4.3.1 with the exact same configuration (50 resources x 30 events each = 1500), and it seems to be a little faster than it was at 4.1.0. I am measuring around 1.1-1.2 seconds to update a single event now. I also tested changing all 1500 events at the same time, and it takes the same amount of time.

fc-debug-page

@arshaw arshaw added this to the v5 milestone Feb 5, 2020
@arshaw

This comment has been minimized.

Copy link
Member

@arshaw arshaw commented Feb 5, 2020

If you're curious to know, this will be included in v5 (currently in-development)
blog post: https://fullcalendar.io/blog/2020/02/changes-in-the-upcoming-v5

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.