maemo.org Bugzilla – Bug 6279
Modest is very slow at loading images
Last modified: 2010-09-06 16:10:13 UTC
You need to
before you can comment on or make changes to this bug.
EXACT STEPS LEADING TO PROBLEM:
Open an email that contains several images. Click the show images button.
Images are downloaded and shown promptly.
System slows to a crawl and images are very gradually rendered. It can take
several minutes to show all the images and modest consumes ~90% CPU in this
EXTRA SOFTWARE INSTALLED:
The worst seem to be marketing emails that contain maybe ten images, each about
half screen size taking several minutes. Others like ebay updates which
contain a dozen thumbnails can be rendered in under a minute. The whole system
is slow during this time. Even after backing out to the mailbox list the
system is still slow and top shows modest is still eating cpu. Eventually it
gets back to normal.
Thanks for reporting this.
So are the images in the HTML email attached, or are they downloaded from the
If possible, can you attach one email here (please remove any confidential
information from the source first)?
I just send myself an HTML email with 15 images to download from the web and
they were downloaded and displayed in less than 3 seconds in Modest in internal
2.2009.48-1. This was even faster than on my desktop computer's Evolution 2.28.
I can confirm super slow image loading for HTML emails on my N900
1.2009.42-11.002. Often not all the images will load until I load images a
second time or exit the email and reopen it.
I think in my case it may be partially related to a large IMAP inbox which
seems to also cause performance issues. If I leave the email client sit for
several minutes the image loading performance is somewhat better (still not
fast enough that I don't cringe). If I go into an IMAP folder that only has a
few emails in it, the image loading is an acceptable speed (still not
particularly quick), although it still doesn't load all images often.
Created an attachment (id=1641) [details]
An example of a marketing email that's been having this problem.
Attached an example marketing email from ebuyer that displays this problem in
modest. With this email I experienced exactly the same problem as Alex - even
having to exit and re-enter several times to get the email loaded. Once the
images are loaded, accessing this email makes the cpu spike (possibly modest
confirming that all images are present)
*** This bug has been confirmed by popular vote. ***
I'm working on this.
The problem is in the way we retrieve the images. We launch one thread per
image, and every time we get an update on one of the threads, we launch in idle
a refresh of the view.
So, in the case of the example email in comment #3, we get slow load of many
images, and this means that every image will hit "fetch a bit more" many times.
This means a huge number of redraws.
I'm adding a timeout handler to:
* Set together the redraws. We shouldn't queue a new redraw if previous one
didn't happen yet.
* Avoid redrawing too much times (I'm setting a timeout of 300 ms).
Committed fix to modest:
* modest-3-2 branch: 5b17870e74f6777f42baee83ef352e60ecb4ad05
* master branch (community): 14b3ea62acef8c2e642008b61fe1a56ed33cf498
So it'll be available once we release a modest 3.2 series to device.
Still valid in 2.2009.51-1
*** Bug 7756 has been marked as a duplicate of this bug. ***
Setting explicit PR1.2 milestone (so it's clearer in which public release the
fix will be available to users).
Sorry for the bugmail noise (you can filter on this message).
This is still broken for me in PR1.2 (reflashed to upgrade). Modest is still
super slow to load images or won't even load all the images in an HTML email.
The success rate of loading an entire HTML message seems improved, but waiting
2 minutes for it to load and display all the images isn't really adequate to
consider this bug fixed IMO.
I can confirm that this is still an issue on PR1.2. Clicking the "show images"
icon in modest for a message with 10+ images results in the system coming to a
stroll. The images load extremely slowly, some images don't load at all, and
scrolling through the message becomes choppy or even impossible. During image
load, modest uses over 90% CPU.
It seems to me that not only the redraw is the culpritt. Running a separate
thread per image to load is likely not scalable e.g. when there are 40-50
images to load (which is a realistic use case). The threads are competing for
the same resources. Wouldn't it be more scalable to limit the number of
threads? E.g. 10 threads max, load 10 first images, then 10 next, etc.
Since this is not fixed, is there a way to reopen this bug?
For comparison reasons, I opened the same image-heavy message in the Nokia
Messaging client on my E71. Here, the images are loaded within a second. Can
the the design for the image load functionality in the Nokia Messaging client
be ported to modest?
> I can confirm that this is still an issue on PR1.2.
Feel free to file a new bug report with exact steps and outcome.
> Can the design for the image load functionality be ported to modest?
There won't be any big architectural changes that late in a development cycle.
New ticket filed as bug 11245