16028 2007-11-17 06:42:44 -0800 [GTK] Track Mozilla's GIF decoder memory reductions 2012-02-18 11:41:24 -0800 1 1 1 Unclassified WebKit Images 528+ (Nightly build) All All RESOLVED INVALID Cairo, Gtk, Performance P2 Minor --- 1 alp webkit-unassigned gustavo mrobinson oldest_to_newest 61464 0 alp 2007-11-17 06:42:44 -0800 The image decoders in the GTK+/Cairo port and others are an old port of Mozilla code. Mozilla has been improving their code and it would be nice to track the changes: https://bugzilla.mozilla.org/show_bug.cgi?id=143046 Bug 143046 (slowGIF) – Need to Keep GIFs at original 8 bit or optimize 69123 1 alp 2008-02-01 15:40:06 -0800 They also have some libjpeg enhancements: https://bugzilla.mozilla.org/show_bug.cgi?id=242145 This one's trickier since we don't bundle libjpeg. Maybe we need to get these fixes pushed into the distributions so we can take advantage of them. Didn't study the changes closely yet. 126387 2 pkasting 2009-06-16 22:22:49 -0700 I could be mistaken, but I don't think the changes on https://bugzilla.mozilla.org/show_bug.cgi?id=143046 are directly applicable to the cross-platform decoders in WebKit. From a brief look, these are mostly changes to Mozilla's surrounding image architecture to allow the decoded frames to remain in 8bpp form instead of expanding to 24bpp. Right now in WebKit the decoded pixels are stored as 32bpp in all circumstances. We might be able to apply a similar idea, but none of the code will really translate. This will be especially tricky given the memory management around the decoded frames. 172249 3 gustavo 2009-12-16 03:17:21 -0800 I would say this is not applicable, given the above? Should we close this bug? 559788 4 mrobinson 2012-02-18 11:41:24 -0800 It seems this should be closed. Feel free reopen it, if it seems necessary.