GNOME Bugzilla – Bug 713956
Reduce lag when viewing an image with large or many embedded images
Last modified: 2019-03-17 04:39:24 UTC
---- Reported by jim@yorba.org 2013-09-20 16:00:00 -0700 ---- Original Redmine bug id: 7527 Original URL: http://redmine.yorba.org/issues/7527 Searchable id: yorba-bug-7527 Original author: Jim Nelson Original description: If an email has a lot of embedded images, or even one large embedded image, there's an appreciable pause between clicking on the conversation and seeing the message. What's happening is this: * RFC822.Message loads the (most likely Base-64 encoded) image into memory * Passes it as buffer to ConversationViewer's inline image handler, which decodes it, performs the re-orientation, then re-compresses to PNG and Base-64 encodes that as a data: URI * The data: URI is stuffed into an IMG tag, which is inserted into the document HTML * When WebKit encounters this HTML, it has to Base-64 decode the data: URI, decompress the image, and display it on the screen It feels like there's too many buffer manipulations in the above steps. Image performance could probably be improved by reducing the number of them. One idea is to keep the image from RFC822.Message in memory and stuff a fake URL into the IMG tag. Then, if possible, trap the request from WebKit and return the image buffer directly to WebKit. The other is to use a CSS transformation property to perform the re- orientation itself. This is doable if we used gexiv2 to get the image orientation field, which would avoid decoding the image in the first place. Related issues: related to geary - 7073: Embedded JPEG doesn't respect Orientation field (Fixed) --- Bug imported by chaz@yorba.org 2013-11-21 20:24 UTC --- This bug was previously known as _bug_ 7527 at http://redmine.yorba.org/show_bug.cgi?id=7527 Unknown version " in product geary. Setting version to "!unspecified". Unknown milestone "unknown in product geary. Setting to default milestone for this product, "---". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one. Resolution set on an open status. Dropping resolution
This will be partly resolved by the WK2 branch landing. All four steps in description above have been removed, and replaced with the WebProcess simply being passed an InputStream feeding it the attachment's bytes from disk via a memory-mapped file, courtesy Geary.Memory.FileBuffer. I assume that means we're sending the data via IPC to the WebProcess, and hence also that the WebProcess is caching it, both of which are suboptimal. Also, since we're still saving attachments in the DB (Bug 714061), that's probably also slowing the load down somewhat. However this may be the best compromise for the moment, since we may want the flexibility when addressing issues such as Bug 714094, rather than e.g. re-writing the cid: URLs as file: URLs pointing directly to the attachments. In any case, loading a message with 8 inline images totalling ~30MB on my 2015-era mobile i7 processor seems acceptably non-laggy. Perhaps one thing to follow up on is whether WK can take advantage of being given a GFileInputStream and just pass the file handle over to the WebProcess, rather than all the bytes. If so, we might want to provide an alternative Buffer implementation to Geary.Memory.FileBuffer that avoids using a GMemoryInputStream and a memory-mapped file, and just returns a GFileInputStream. But again, I wonder if it's worth it?
Closing this since it's an artifact of the current implementation which won't change until say Bug 714061 gets fixed, so it's best handled when that is.