maemo.org Bugzilla – Bug 6279
Modest is very slow at loading images
Last modified: 2010-09-06 16:10:13 UTC
You need to log in before you can comment on or make changes to this bug.
SOFTWARE VERSION: 1.2009.42-11 EXACT STEPS LEADING TO PROBLEM: Open an email that contains several images. Click the show images button. EXPECTED OUTCOME: Images are downloaded and shown promptly. ACTUAL OUTCOME: 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 time. REPRODUCIBILITY: always EXTRA SOFTWARE INSTALLED: n/a OTHER COMMENTS: 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 web? 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