Hi John, I'm still working on features for Preview, so I don't have time to focus on calendar performance right now. Andi said he thinks perhaps you have time to work on that. If you have time, that would be great. I think there's lots of room for improvement in rendering the calendar, I'm happy to work on this eventually, but I'm happier if it gets done sooner!
The tricky thing about calendar work is that there have been dozens of UI bugs associated with the calendar, and it's seems tricky to write functional tests for lozenge visibility to make sure there aren't regressions. Here's an incomplete list of things that I try to test when I make changes in the calendar: - Turn All-Day status on and off to move lozenges from the all-day to the timed canvas - Drag items from the All Day canvas to the Timed Canvas and back - Refresh lozenge colors when changing the selected collection - Refresh de-selected and newly selected lozenges when changing selection - Most recently selected lozenge stays on top of stacks of lozenges - Changes to a recurring event are reflected in the UI right away (this is partially broken right now, changed events snap back to their old values until the recurrence dialog is answered) - Moving or resizing one event causes other events stacked with it to resize - A new swatch is added immediately when an item is added to a different collection - Adding recurrence to an event adds lozenges immediately - All of the above are reflected in the mini-calendar synchronously - Changing weeks when editing an item ends the editing of the item With all that said, here are optimizations I've thought about: - Improve use of collection notification hints. Right now when the calendar receives an "add" hint we don't recalculate all the lozenges that need to be rendered, we just create a new lozenge. But we redraw the whole calendar, instead of just the current day. At the very least we could redraw only the days affected by the new event. Note that, because of stacking, it's tricky to redraw at granularities less than a day. Even a granularity of one day doesn't work perfectly, because events may start in one day and end in another, so in a full calendar, a change to one day's event may cause a cascade in lozenge margins that effect the next day. - As things are currently set up hints actually work poorly when creating a new item. I believe this is the source of the fact that we redraw twice when a new event is created, the first time is a redraw prompted by the UI view in response to the double click (to draw the new lozenge), the second is a response to the hint from the repository that an item has been added to the collection. We could cut rendering time in half if we could avoid one of those redraws. - Changes in one calendar canvas cause a redraw in both calendar canvases. The tricky thing about fixing this is that an item can move from one canvas to the other, so sometimes a change to an event does require a refresh in both canvases. - Make fewer queries to the repository of what items relate to the current week range. With a big calendar, those calls are expensive, and we make them 4-5 times per rendering of the various calendar regions (mini-calendar/all-day/timed canvas). This would probably involve caching the relevant items, but of course invalidating the cache then becomes crucial. I'm sure there are other areas for optimization, those are just things that leap to mind immediately. Sincerely, Jeffrey _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
