403922 - Multiweek scroll / next / previous is too slow with multiple calendars

Status: RESOLVED WORKSFORME

(Calendar :: Calendar Frontend, defect)

Description

[Trevor Morgan]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9
Build Identifier: 0.7 build 2007102304

Scrolling the multiweek view with the mouse wheel or previous / next buttons is very slow (approx 1s to show any response) with more than one calendar open.

It would be a good idea to draw the grid, header and day-numbers first (fixed parts), followed by the already-in-view events (presumably already in memory), and finally the events in the newly exposed weeks. Is this possible.
Allow scrolling to take priority over drawing events, to give good user feedback.

There is a similar lack of response when enabling or disabling a calendar.


Reproducible: Always

Steps to Reproduce:
1. Enable a few calendars 
2. Scroll the view a bit
3. See how long it takes.
Actual Results:  
Window scrolls very slowly and misses wheel clicks

Expected Results:  
Response to scrolling is immediate, even if it takes a few moments for the new events to appear.

Comment 1

[Trevor Morgan]

This may be a duplicate of Bug 392418, or might just be similar.

Comment 2

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

The lack of response is bug 392418 or similar. We cannot influence the way things are drawn, this is done by XUL. The static elements should be staying anyway, we just remove the event boxes and redraw them.

I was dead sure there was a bug to re-use the event boxes when relayouting the view, which will get rid of the flashing.

What we should look into is UI responsiveness, but that might be hard, since js1.x only has two threads, the UI thread and the main thread, without there being an easy way to move processing from the window into the main thread. js2 will relieve this situation.

Comment 3

[Trevor Morgan]

In version 0.7 scrolling was slow even with no events to draw.

Following the release of 0.8, I have re-tested this bug.
The responsiveness is very much improved and is now clearly dependant on the number of visible entries, rather than the number of calendars.

Now the back-end has improved the sluggishness of the front-end is apparent.

Comment 4

[Trevor Morgan]

Version 1.0b1 Update.
Scrolling is now much improved and is now usable.
The only niggle left is that the existing events remain in place for a moment while the grid changes behind them.  Particularly noticeable with events that repeat every day.

Comment 5

[Martin Schröder [:mschroeder]]

(In reply to Trevor Morgan from comment #4)
> Version 1.0b1 Update.
> Scrolling is now much improved and is now usable.
> The only niggle left is that the existing events remain in place for a
> moment while the grid changes behind them.  Particularly noticeable with
> events that repeat every day.

Trevor, is this still visible using Lightning 1.1 (compatible with Thunderbird 9)?

Comment 6

[Trevor Morgan]

Version 1.8 update

Scrolling appears to have slowed down again.  Perhaps it is something to do with the indecipherable icons that have appeared.

Would it be possible to make the multi-week view a proper scrolling window / pane, with event boxes added to / removed from the invisible area?  That way scrolling is handled by the UI control and updating the content can be done more leisurely.  I would suggest loading a screenful before and after the visible area.

Comment 8

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Archaeopteryx suggests better caching in bug 466741. While this bug might be slightly different, the root problem is the same: fix performance when displaying views.

Comment 9

[Wayne Mery (:wsmwk)]

Richard, can you reproduce this?

Comment 10

[Richard Leger]

(In reply to Wayne Mery (:wsmwk) from comment #9)

Richard, can you reproduce this?

In TB 91.4.0 (64-bit) I acknowledge there are room for improvement in term of performance when displaying Calendar views but the multiweek view does not show shocking performance when clicking next/previous button with my trackpad (don't use a mouse with wheel and don't have one at hand to test) with multiple calendars with or without offline support (a combination of both I have).

It is slow enough for me to see each event being drawn with multiple calendar but in overall does not take more than about 1s, so not a dramatic issue.

The performance to load an entire network caldav calendar with ~4000+ items remain very poor though (several minutes) separate bug was already filed long ago about such issue... especially affecting startup performance as then the offline support takes over, though I would rather work online at all time :-)

Opening and saving calendar items is rather slow as well...

Comment 11

[Wayne Mery (:wsmwk)]

Trevor does this reproduce for you?

Comment 12

[Trevor Morgan]

For many years, I haven't had a problem. A recent update (maybe 115.8.0) slowed redrawing down again. There is a noticeable flicker again but scrolling is not delayed waiting for the redraw like it used to be. I am only using local calendars.
It would be good to see smooth scrolling of the calendar instead of the current jump scroll.

Comment 13

[Wayne Mery (:wsmwk)]

Thanks Trevor. Let's see whether the next version helps resolve that more minor issue