Ver Greeneyes wrote:Just wanted to mention that Seth Fowler has been has been doing a ton of work on ImageLib lately. He's been cleaning everything up and rewriting all the state management for how to manage image decoding - now all decoded and resized images are stored in a SurfaceCache, so you can have multiple high quality resizes per image.
With that done, he's been working on making each image decode into its own work unit, off the main thread and asynchronous, with the intent of being able to decode on draw. This should save more work during page load, doing only the work that's absolutely necessary for drawing the images that are currently in view (or can be reached by a small bit of scrolling). It should also make the discard logic a lot simpler and more powerful.
I don't know the end goal of all this, or if it's part of a bigger project, but it seems he's making large strides to making Gecko not suck at images (static or animated). ImageLib was recently brought up as one of the most horrible pieces of code in Gecko, but he's certainly making large strides in changing that, so hopefully more people will be able and willing to work on it in the future!
The async plugin loading is pretty awesome, async GIF's would be a lifesaver too. Loading a page with 100+ GIFs just murders firefox
Micro gaming box: AMD A10-7800 APU, 8gb RAM M350 ITX case (size of a book), Windows 10/Ubuntu Tablet/Laptop: Asus Transformer T100, Intel Atom 2GB RAM, Windows 10 x86 Mobile:Xiaomi Redmi Note 3 Pro
Ver Greeneyes wrote: I don't know the end goal of all this, or if it's part of a bigger project, but it seems he's making large strides to making Gecko not suck at images (static or animated). ImageLib was recently brought up as one of the most horrible pieces of code in Gecko, but he's certainly making large strides in changing that, so hopefully more people will be able and willing to work on it in the future!
I don't remember exactly why but I think it was either e10s or Servo.
Ver Greeneyes wrote: so you can have multiple high quality resizes per image.
Um. What does this mean?
Ver Greeneyes wrote:I don't know the end goal of all this, or if it's part of a bigger project, but it seems he's making large strides to making Gecko not suck at images (static or animated). ImageLib was recently brought up as one of the most horrible pieces of code in Gecko, but he's certainly making large strides in changing that, so hopefully more people will be able and willing to work on it in the future!
Yeah... Image handling's not great. I don't remember a time when the throbber wasn't jerky. And it's usually images that cause hiccups in scrolling.
Firefox has had a high quality downscaling algorithm for a while, but previously it could only cache a single downscaled version of an image at a time - so if you had a page showing the same image at different sizes only one of the sizes would get the high quality downscaling. That is, if I understood correctly.
Firefox has had a high quality downscaling algorithm for a while, but previously it could only cache a single downscaled version of an image at a time - so if you had a page showing the same image at different sizes only one of the sizes would get the high quality downscaling. That is, if I understood correctly.
Thanks for the clarification. Is it true between pages? Like different sections of a website. Or images aren't shared between tabs?
avada wrote:Thanks for the clarification. Is it true between pages? Like different sections of a website. Or images aren't shared between tabs?
I'm honestly not really sure what the limitations were. I know the worst ones were eliminated long ago, but I'm not sure where that left us Either way, they're going away now! But I expect these changes to have more of an impact on performance and memory usage on image heavy websites than on their appearance.
Oh, and the multithreading changes just landed on mozilla-central, so perhaps we'll see a difference in tomorrow's Nightly!
Ver Greeneyes wrote: I don't know the end goal of all this, or if it's part of a bigger project, but it seems he's making large strides to making Gecko not suck at images (static or animated). ImageLib was recently brought up as one of the most horrible pieces of code in Gecko, but he's certainly making large strides in changing that, so hopefully more people will be able and willing to work on it in the future!
I don't remember exactly why but I think it was either e10s or Servo.
I think the biggest reason for these imagelib changes was to support downscale-during-decode, which is crucial for memory starved B2G devices.
mayankleoboy1 wrote:^ IIUC, that bug only removed a preference that disabled multithreaded image decoding in some cases. We've had MT image decoding for a long time now.
Well, there are a lot more changes under the hood, but I agree we might not see any changes in behavior yet. Unfortunately the next batch of landings got backed out for test failures. There's a lot of bugs involved here, so it's hard to keep them all straight
Did anything happen in the past few weeks on central? Evertyhing seems slower lots of short to not-so-short hangs and altogether slowness. It didn't use to be this bad. Also high memory usage.
avada wrote:Did anything happen in the past few weeks on central? Evertyhing seems slower lots of short to not-so-short hangs and altogether slowness. It didn't use to be this bad. Also high memory usage.
I'm having exactly the same problem... I was using e10s off, but after this problems started, I enabled it, because it hangs less, but still, very bad compared to 1 week ago. I was guessing it was a problem with my profile, but if somebody else is seeing it too, maybe it isn't.
Yeah, I'm seeing a lot of hangs too, running with e10s disabled. Refreshing even relatively simple pages seems to hang for seconds at a time with the spinner stuck in a 3 O'clock position (as it were). I think this might be fallout from the imagelib changes - perhaps some lock contention that's causing long waits. The spinner might be bug 1119938, but I'm wondering if it's symptomatic of a more widespread problem.
For me, opening the filter preferences from Adblock Plus and loading the filter list from EasyList (happens automatically) always hangs. On Firefox 35 it loads instantly.
avada wrote:Did anything happen in the past few weeks on central? Evertyhing seems slower lots of short to not-so-short hangs and altogether slowness. It didn't use to be this bad. Also high memory usage.
I'm having exactly the same problem... I was using e10s off, but after this problems started, I enabled it, because it hangs less, but still, very bad compared to 1 week ago. I was guessing it was a problem with my profile, but if somebody else is seeing it too, maybe it isn't.
I also have e10s off, didn't enable it on my main profile because of the addons. I tried to update just now and then something with places got broke. On my main profile no history or bookmarks showed up. First tried Tinderbox PGO as I usually do, then plain nightly. (both Win64) If I downgraded to a few day old build it started working again. But since the performance issues still suck I decided to move back to stable for now... (It feels super fast after this abrupt change.)
(Too bad they don't automatically uplift HTML5/MSE improvements)
mozillaZine is an independent Mozilla community and advocacy site. We're not affiliated or endorsed by the Mozilla Corporation but we love them just the same.
Either way, they're going away now! But I expect these changes to have more of an impact on performance and memory usage on image heavy websites than on their appearance.