First Last Prev Next    No search results available
Bug 7027 - (int-129525) Changing to next week is very slow
(int-129525)
: Changing to next week is very slow
Status: VERIFIED FIXED
Product: Calendar
General
: 5.0/(1.2009.42-11)
: N900 Maemo
: Low normal (vote)
: 5.0/(2.2009.51-1)
Assigned To: unassigned
: calendar-general-bugs
:
: performance
:
:
  Show dependency tree
 
Reported: 2009-12-16 11:32 UTC by Felix Rohrbach
Modified: 2010-02-22 12:32 UTC (History)
4 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)


Note

You need to log in before you can comment on or make changes to this bug.

Description Felix Rohrbach (reporter) 2009-12-16 11:32:38 UTC 
SOFTWARE VERSION:
(Settings > General > About product)
1.2009.42-11

EXACT STEPS LEADING TO PROBLEM: 
(Explain in detail what you do (e.g. tap on OK) and what you see (e.g. message
Connection Failed appears))

I want to see how my week looks like, three weeks from now.

1. Open Calendar in week view
2. Move forward by wiping my finger from right to left
3. Repeat until the desired week shows up

EXPECTED OUTCOME:
The device moves to the desired week and shows the events taking place there.
(wipe->wipe->wipe->events load)

ACTUAL OUTCOME:
The device loads events after each wipe. This means, that there is a waiting
time when it's loading each week. Specially the birthday calendar seems to take
long. (wipe->events load->wipe->events load->wipe->events load)

REPRODUCIBILITY:
(always, less than 1/10, 5/10, 9/10)
always

EXTRA SOFTWARE INSTALLED:
account-plugin-haze(0.3), Bounce(1.0.0), Droid Fonts(1.01-dfsg0maemo3),
eCoach(1.56), Facebook Installer(1.0-4+0m5), Facebook Widget and Photo
Uploader(0.4.7), Flashlight(0.1-0), Foreca Installer(1.0+0m5), ForecWeather
widget(0.9.4), Hermes(0.2.3), MaStory(2.0-2), Pixelpipe Upload and
Share(1.1.00.1+0m1), Simple Brightness Applet(1.1-1maemo0)

OTHER COMMENTS:
In the monthly view, this seems to be solved. There you can wipe over the
screen several times and it moves fast to the desired month. Although, there as
well it would be nice if the name of the month in the title bar changes with
each wipe.

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.15)
Gecko/2009101601 Firefox/3.0.15 (.NET CLR 3.5.30729)
Comment 1 Andre Klapper maemo.org 2009-12-16 22:18:13 UTC 
This has been fixed in package
calendar-ui 0.5-9.10+0m5
which is part of the internal build version
2.2009.42-7
(Note: The first number is the branch, 2009 is the year, and the number after
is the week.)

Any future public update released with a later branch number and the year/week
later than this internal build version will include the fix.
Note that 1.2009.42-11 does not yet contain this fix.
Please verify that this new version fixes the bug by marking this bug report as
VERIFIED after the public update has been released and if you have some time.

To answer popular followup questions:
 * Nokia does not announce release dates of public updates in advance.
 * There is currently no access to these internal, non-public build 
   versions. A Brainstorm proposal exists at
http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/
Comment 2 Daniel Martin Yerga 2009-12-23 17:47:39 UTC 
Verified in non-public PR1.1 version (2.2009.51-1).
Comment 3 Andre Klapper maemo.org 2010-01-14 12:29:56 UTC 
The problem reported here should be fixed in the update released today for
public: The Maemo5 update version 2.2009.51-1 (also called "PR1.1" sometimes).
Please leave a comment if the problem is not fixed for you in this update
version.
Comment 4 Fredrik Wendt 2010-01-14 19:31:06 UTC 
I'm sorry to say that this is far from fixed. My smart birthday calendar shows
I have 287 entries and changing from one week to another might be marginally
faster. I can't tell since it's still really awfully slow. Turning birthday
calendar off (ticking the checkbox under settings) shows acceptable
delays/responsiveness.

(PS: I don't agree with the original description: there is a short time (0.5
sec?) in which you can swipe swipe swipe to fast forward three months, but
swiping after 1 sec won't do anything until all activities have been loaded,
after which is progress to the next/previous month. However, the response time
for changing month is acceptable since it doesn't wait for birthday events,
which is good!)
Comment 5 Fredrik Wendt 2010-01-19 02:01:33 UTC 
(In reply to comment #4)
> after which i[t] progresses to the next/previous month. However, the response time
> for changing month is acceptable since it doesn't wait for birthday events,
> which is good!)

The week view, after the 0.5 secs delay, won't change week until all birthday
events have loaded. The month view is never stuck waiting for events to load.
Looks like month view uses an async call after the initial delay (0.5 secs),
while the week view uses a synchronous call after the initial delay.
Comment 6 Andre Klapper maemo.org 2010-02-09 19:27:54 UTC 
(In reply to comment #4)
> I'm sorry to say that this is far from fixed. My smart birthday calendar shows
> I have 287 entries and changing from one week to another might be marginally
> faster. I can't tell since it's still really awfully slow. Turning birthday
> calendar off (ticking the checkbox under settings) shows acceptable
> delays/responsiveness.

According to developers this is a completely different issue, plus it is
required to know how many birthdays and events (separately recurrent and
non-recurrent) you have in calendar.
Please feel free to file a separate bug report.
First Last Prev Next    No search results available