To be clear, by "scrolling" we mean the scrollbar in the calendar view,
not moving from week to week. I don't know that we have an automated
test for moving from week to week (or day to day). If this is indeed
very slow, we should (I'll go figure that out).
If I understand correctly, the calendar Heikki has been using is the one
found at tools/QATestScripts/DataFiles/Generated3000.ics. This is the
calendar that the scripts have been measuring.
My reasoning for wanting to close this:
+ We're very close to the target (picked somewhat arbitrarily by me,
with less confidence than with the other targets)
+ When I test it out myself, it meets my subjective test of acceptable
(not quite ideal though)
+ When I test it out on family members, they say they find it acceptable
+ Mitch has not had problems with scrolling when dogfooding with his
calendar.
As Alec pointed out in the bug, scrolling performance is currently
proportional to items on the screen, not the overall size of the
calendar (unlike other use cases).
Cheers,
Katie
Andi Vajda wrote:
Scrolling the 3000 event calendar Heikki has been using is still *very*
slow because of bug 4477. I'd make that one a blocker of this bug.
Andi..
On Wed, 2 Nov 2005, Katie Capps Parlante wrote:
Most excellent.
I agree, we've hit "acceptable" for scrolling -- we should close this
bug and move on to higer priority bugs.
Cheers,
Katie
Alec Flett wrote:
Heikki Toivonen wrote:
Scrolling the 3000 event
calendar is under acceptable limits on Windows and Linux, and really
close to the limit on Mac (might go under with alecf's latest changes -
we'll see).
It did - we dropped another 10%! It says "0.10s" on the performance
page, though its outlined in orange - I assume that means its really
something like 0.104s? Or maybe, since python's floating point math
can be pretty nuts, its more like 0.10392893598724s. Can we just
round, rather than truncate when doing our coloring? :)
I'm reaching a point with the calendar where I'm going to need to do
some serious rearchitecture to get any more performance gains - I
mean I can eek out 1-3% here and there, but anything significant (8%
or higher, I'd say) is going to require changes that are too risky
for 0.6.
Alec
------------------------------------------------------------------------
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
