GNOME Bugzilla – Bug 300567
Scrolling Calendar Causes 100% CPU Usage
Last modified: 2009-09-22 03:45:28 UTC
Please describe the problem: Scrolling the Calendar in Month view is incredibly slow. CPU usage goes up to 100% by either clicking the scroll buttons or dragging the scrollbar around. CPU usage stays at 100% if I drag the scrollbar around without stopping. The scrollbar jumps about trying to keep up with the cursor. I'm currently running the software on a 1.6Ghz processor system w/ 384MB of RAM. Steps to reproduce: Described above Actual results: Described above Expected results: The months enter into view with causing high CPU usage. Minimal delay before the data of the month scroll to is displayed. Does this happen every time? yes Other information: no
hi kevin, thanks for reporting. there have been a lot of memory fixes in 2.3.x. is there a chance for you to test this with evolution 2.4.x? thanks in advance... adding perf keyword.
I've tried using evolution 2.4.1 and the same performance issue is there. It seems that evolution is trying to display information for each iteration of the scrollbar as you move it via dragging or using a mouse scroll wheel. For myself, it would be nice for the dragging the scrollbar if evolution waits until the mouse button release signal is emitted then proceed to getting the information for that position. btw, thanks for an excelent app. Kev
ok, updating version number. thanks. :-)
Created attachment 88152 [details] [review] proposed patch for evolution; in calendar/gui/gnome-cal.c: update_view_times - added new parameter, even_current_view, when TRUE, all views are updated, otherwise all except current view update_adjustment - added test on changes for current view, if no change for current view is done then only other views are updated based on scrollbar position
Seems like a nice optimization, but I would like chen to comment on this.
This is a very minor optimization. It does not fix all the major issues specified in the bug. Mchra, it would be nice if we can make a fix based on comment #2.
Chen you feel that this minor optimization is worth rejecting? Might be if this is good, this can be in with more to follow. I leave it to you :-)
Chen, ping, time moved quite much since the patch, but anyway.
The patch may not be relevant now as all views now use a single model.
(In reply to comment #9) > The patch may not be relevant now as all views now use a single model. I believe that at least this part still applies, even I didn't test it: >> update_adjustment - added test on changes for current view, if >> no change for current view is done then only other views are updated >> based on scrollbar position If I recall correctly, then for example movement of a scroll bar in the month view may call updating view even the times are same as before.
Created attachment 138129 [details] [review] proposed evo patch ][ (partial) for evolution; I looked on most time/CPU consuming parts while drawing events and this is a result of my optimizations. It's for both day and month view. You can see the difference very easily with tooltips while moving mouse above the event. It behaves more quickly now. This is just a partial patch, because it doesn't solve the issue with scrollbar. I'm not sure how to do with that. It's impossible to guess what time is user on when moving a scrollbar, and not updating the view with items might seem strange to other users. I agree it's very slow when moving around full month of events (I have such month, mostly 4 events per day).
*** Bug 269323 has been marked as a duplicate of this bug. ***
milan, plz explain a bit more on the optimizations done at patch comment #11
Those most visible slowdowns I noticed are with drawing pixmaps. The other problem is that evo draws whole screen, regardless only partial rectangle is requested. Thus this patch does: - update only requested region to draw - cache categories icons to not always load them from file - do not ask gconf each paint request for values stored there - reordering of function calls to not do something when the destination area is out of the drawing region - some simplification of code had been done as well
The patch seems to work fine. Please commit the patch. Certain parts of the patch does not apply to trunk, i have ported them. Will upload the updated patch which applies properly. please test it and commit.
Created attachment 139502 [details] [review] patch that applies to master
Created commit f093350 in evo master (2.27.6+) I merged the original patch myself, and they differ slightly with that yours, thus I rather used mine :)
fine :)
shall we close the bug ?
I'd say it is safe to close as I've seen much better performance with the Calendar scrolling and CPU usage as of late.
Thanks Kevin