Closed Bug 598736 Opened 14 years ago Closed 13 years ago

Use higher-quality image interpolation on mobile

Categories

(Core :: Graphics, defect, P1)

defect

Tracking

()

RESOLVED FIXED
mozilla6
Tracking Status
firefox6 --- fixed
fennec 6+ ---

People

(Reporter: mbrubeck, Assigned: mbrubeck)

References

Details

(Keywords: mobile, perf)

Attachments

(2 files, 3 obsolete files)

When MOZ_GFX_OPTIMIZE_MOBILE=1, we always use nearest-neighbor resampling for images in content.  This makes scaled images look noticeably worse in Fennec than in other mobile or desktop browsers.  This is important for mobile because content is almost always zoomed in or out in Fennec.
tracking-fennec: --- → ?
(In reply to comment #2)
> there's another one though...
> http://mxr.mozilla.org/mozilla-central/source/layout/base/nsLayoutUtils.cpp#2835

This must be enabled for Pixman/X based scaling, otherwise our pinch zoom and content update will be much slower...

we should use GOOD filter only if it is optimized enough... (GL case for example)
Does GOOD filter already works anywhere fast enough?
(In reply to comment #4)
> Does GOOD filter already works anywhere fast enough?

Currently it's approximately 10-30 times slower than NEAREST scaling for pixman-0.19.4 on ARM Cortex-A8:

Test using 2048x2048 image size (for all scaling operations source size ~= destination size):

== unscaled SRC ==
op=1, src_fmt=20028888, dst_fmt=20028888, speed=83.52 MPix/s
op=1, src_fmt=20028888, dst_fmt=10020565, speed=120.83 MPix/s
op=1, src_fmt=10020565, dst_fmt=10020565, speed=183.47 MPix/s

== nearest SRC ==
op=1, src_fmt=20028888, dst_fmt=20028888, speed=53.44 MPix/s
op=1, src_fmt=20028888, dst_fmt=10020565, speed=42.33 MPix/s
op=1, src_fmt=10020565, dst_fmt=10020565, speed=81.60 MPix/s

== bilinear SRC ==
op=1, src_fmt=20028888, dst_fmt=20028888, speed=4.53 MPix/s
op=1, src_fmt=20028888, dst_fmt=10020565, speed=4.39 MPix/s
op=1, src_fmt=10020565, dst_fmt=10020565, speed=2.25 MPix/s


Even with full NEON optimizations added, I expect that BILINEAR is still going to be about 2-4x slower than NEAREST. But indeed, NEON optimizations for bilinear scaling would be very nice to have.
That was measured on 720MHz OMAP3 device (IGEPv2 board) with gcc 4.5.1. Other ARM devices may have similar results with some variations due to CPU clock frequency, memory speed and compiler version. MPix/s numbers is easy to convert to FPS depending on target screen resolution.
blocking 2.0+ for figuring out what to do here
tracking-fennec: ? → 2.0+
With GL compositing and bug 598874, we'll get this "for free" for content images.  The problem is harder without bug 598874 and with SW compositing.
Depends on: 598874
Assignee: nobody → doug.turner
Would SIMD optimizations (SSE2, ARM NEON) for bilinear scaling in pixman be still somewhat useful after GL compositing solution is rolled out?
We won't block on this, but hopefully will get for free
tracking-fennec: 2.0+ → 2.0-
Assignee: doug.turner → nobody
tracking-fennec: 2.0- → 2.0+
Priority: -- → P1
This is one of the worse polish issues we have in Fennec and GL will not make it for Fennec 4. So we'd like a plan to fix this for Fennec 4, even partially (on some devices), without a GL hail mary.
Are SIMD optimizations something we can look at for Fennec 4?
(In reply to comment #12)
> Are SIMD optimizations something we can look at for Fennec 4?

I'd skip SIMD and look at NEON
I believe the issue is downscaling, which has always looked bad due to an unimplemented "good" algorithm.  That is, there's nothing to "make fast", afaik; have you tried not forcing nearest-neighbour and seeing if it actually gives you the quality you want?

Also, for this to really be performant, the downscaled images should be cached... and I just had a somewhat evil thought: in bug 622184, I already added a mechanism by which a decode can be forced if a frame is requested with different flags than the previous frame.  This mechanism could be extended to include a scale factor, triggering a re-decode whenever the image is zoomed, followed by a single high quality scale.  At draw time, the current frame's scale should be set on the gfxPattern, leading to the scale on the context cancelling it out and turning this into a fast 1:1 blit to the page..
(In reply to comment #14)
> I believe the issue is downscaling, which has always looked bad due to an
> unimplemented "good" algorithm.

Downscaling is a different issue. I think this bug is about having nearest scaling enforced for mobile builds, which looks worse than bilinear. For upscaling too.

> That is, there's nothing to "make fast", afaik; have you tried not forcing nearest-neighbour and seeing if it actually gives you the quality you want?

Yes, bilinear scaling looks a lot better than nearest for the images and it's really hard not to notice.

> Also, for this to really be performant, the downscaled images should be
> cached...

Caching is not a magic pill. And it can easily make performance *worse*. Because between the moment when you enter URL, and the moment when you actually see the result on the screen, scaling operation has to be done anyway when there is a scaled image to display. Of course, caching of a downscaled image is reasonable if we have it ready as a by-product of rendering and there is enough RAM. Caching upscaled images is a bit questionable as they need more RAM and memory bandwidth.

Another case for fast scaling done in realtime is pinch zoom, but this probably has to keep using nearest scaling for software rendering.

I don't quite understand the rationale of your comment. Are you against getting SIMD optimizations for bilinear scaling? And what happens if the caching strategy fails? The previous bet was on GL compositing.
I think fast bilinear scaling on the CPU is going to be part of any plan here.  Filed bug 628324 for adding NEON a fast-path.
(In reply to comment #15)
> (In reply to comment #14)
> > I believe the issue is downscaling, which has always looked bad due to an
> > unimplemented "good" algorithm.
> 
> Downscaling is a different issue. I think this bug is about having nearest
> scaling enforced for mobile builds, which looks worse than bilinear. For
> upscaling too.

Yeah, but see below about common case..

> Caching is not a magic pill. And it can easily make performance *worse*.
> Because between the moment when you enter URL, and the moment when you actually
> see the result on the screen, scaling operation has to be done anyway when
> there is a scaled image to display. Of course, caching of a downscaled image is
> reasonable if we have it ready as a by-product of rendering and there is enough
> RAM.

Right, that was my thinking.  You can also free up memory by throwing away the 1:1 image.

> Caching upscaled images is a bit questionable as they need more RAM and
> memory bandwidth.

Yep, agree again; I was only thinking of downscaled here, since I assumed that was the fennec common case, no?  If the user zooms in past 1:1 then yeah, current bilinear upscaling will help, but I think zoomed in beyond 1:1 is the rare case..


> Another case for fast scaling done in realtime is pinch zoom, but this probably
> has to keep using nearest scaling for software rendering.
> 
> I don't quite understand the rationale of your comment. Are you against getting
> SIMD optimizations for bilinear scaling? And what happens if the caching
> strategy fails? The previous bet was on GL compositing.

Not at all; was just saying that having a faster version of what we already have won't necessarily improve the quality; e.g. I don't think it'll improve downscaling quality at all.  I think the right thing is to have fast scaling (up/down) *and* caching *and* higher quality downscaling :-)
(In reply to comment #17)
> Yep, agree again; I was only thinking of downscaled here, since I assumed that
> was the fennec common case, no?

Mobile-optimized sites (like m.engadget.com) are typically upscaled to 150% on the high-resolution devices that we are targeting, so that is a very common case too.  (And even on sites designed for large screens, Fennec users typically need to zoom in before actually reading or interacting with the page.)
Yep, even though the resolution is lower on mobile devices, still DPI is typically higher there compared to desktop systems. So zoom in feature is used quite often.
Can someone pick this bug up and own it?
Anyone got a patch for this bug in the works?
Assignee: nobody → blassey.bugs
Not blocking on this -- nice to have, would take, but we need to fix our other blockers first
tracking-fennec: 2.0+ → 2.0next+
My understanding is that solving this bug just requires changing the way how the use of nearest scaling instead of bilinear is configured. If I understand this correctly, right now it is decided at compile time. But shouldn't it actually be a runtime configuration option? So that the users can select whether they prefer better performance or better image quality.
I wonder if there is any connection at all to Bug 620808
I think a fix for this could be really simple.

We could use bilinear filtering only in the content process, and nearest neighbor in the parent process. This gives us responsive scrolling and high-quality images, probably at a checkerboarding penalty. This might be good enough though.
Re: Comment 22 and Comment 25: do we have an estimate what "really simple" means? Is this a quick fix? We absolutely have to fix other blockers first. However, comparing us vs. stock makes us look really bad on most web pages that use images or logos.
tracking-fennec: 2.0next+ → ?
Thomas, why did you put this in the nom queue? It is not blocking our release. If a patch comes along and is safe we can talk about taking it then.
tracking-fennec: ? → 2.0next+
The updated pixman might have NEON fast-paths for the operators we care about.  We should check after the new-cairo dep on bug 562746 is fixed; we might get this for free too.
Should note that the version of pixman I'm looking at importing *doesn't* have Siarhei's patch listed in bug 628324 comment 10, we may not get what we need.
(In reply to comment #30)
> Should note that the version of pixman I'm looking at importing *doesn't* have
> Siarhei's patch listed in bug 628324 comment 10, we may not get what we need.

Right. But also even that patch only adds a common optimized bilinear scaling framework and implements just one basic scaling operation (16bpp support is still missing). I have more patches available here which should significantly improve bilinear scaling support and cover more practical cases such as html5 games. I will send this patchset after a bit more testing and cleanup. Too bad it may be a bit late for the upcoming release of fennec.

Nevertheless almost *any* update of pixman should improve performance on ARM because there are some NEON optimizations added earlier.
adding some examples of what i see.
- Android Stock browser - http://www.flickr.com/photos/32283582@N00/5535596671/in/photostream/ (likely webkit-css; webkit-border-image)

- fennec nightly - http://www.flickr.com/photos/32283582@N00/5535596613/in/photostream/
Would just a simple search&replace NEAREST to BILINEAR under MOZ_GFX_OPTIMIZE_MOBILE ifdefs be sufficient to resolve this issue? Like suggested in comment 1 and comment 2?
Attached patch patch (obsolete) — Splinter Review
This works for me, and scrolling is still fast on my T-Mobile G2, even on complex sites with lots of images (like planet.mozilla.org).
Attachment #523633 - Flags: review?(jmuizelaar)
I suspect you just want to remove the code in gfxDrawable.cpp.
I think we only want to do this for images, not for all scaling?
It would also be nice to be able to pull images out in to their own layers and use the GPU for scaling
Comment on attachment 523633 [details] [diff] [review]
patch

We should test on non-NEON devices (e.g. Tegra) before making this change.

(In reply to comment #38)
> It would also be nice to be able to pull images out in to their own layers and
> use the GPU for scaling

This is bug 598874.
Attachment #523633 - Flags: review?(jmuizelaar)
Attached patch patch v2 (obsolete) — Splinter Review
There does not seem to be any noticeable checkerboarding regression from this patch, even on an Atrix (Tegra processor, no NEON support).
Assignee: blassey.bugs → mbrubeck
Attachment #523633 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #523716 - Flags: review?(jmuizelaar)
(In reply to comment #40)
> There does not seem to be any noticeable checkerboarding regression from this
> patch, even on an Atrix (Tegra processor, no NEON support).

The most visible impact of slow (bilinear) scaling can be observed after pinch zoom. By checking how long it takes to re-render content with a new scale factor and change the picture on screen from jagged to smooth. A convenient web page for testing is http://images.google.com (just search for something first and then try zooming it).

Tegra2 is a relatively fast dualcore processor. I'm glad that it can still cope even without NEON and Mozilla does not have a strong need for better armv6 optimizations yet. And maybe they placed their bet on providing good GPU drivers so that nobody would have any need to resort to software rendering :)
(In reply to comment #40)
> Created attachment 523716 [details] [diff] [review]
> patch v2

Patch works fine for me with ordinary web pages full of images and fennec looks *much* better. But there is a some slowdown for html5 video playback. Unfortunately seems like all the fancy scaling operations mentioned in bug 641196 now need bilinear counterparts. The solution probably has to be one of the following:
1. fix bug 641196 and make video pipeline behave in a sane way
2. bite the bullet and provide additional NEON fast paths in pixman for these operations too, some of these can be also useful for html5 games which use bilinear scaling regardless of MOZ_GFX_OPTIMIZE_MOBILE define
3. somehow enforce nearest scaling for video, but use bilinear scaling for images
4. fix bug 634557 and do scaling early after decoding combined with YUV->RGB conversion, but without fixing video pipeline it will also cause some additional overhead in the video upscaling case because more data will need to be passed from 'plugin-container' to 'fennec' process.
3. Would be straightforward. You's just give the browser css something like

video { 
    image-rendering: -moz-crisp-edges;
}
Thanks. Which of the css files would be best to add this change for Fennec?
On firefox I think it would be browser.css. Does Fennec have that?
(In reply to comment #44)
> Thanks. Which of the css files would be best to add this change for Fennec?

in Fennec you probably want content.css - which is the CSS used for web content.
(In reply to comment #46)
> in Fennec you probably want content.css - which is the CSS used for web
> content.

Thanks, adding the chunk suggested by Robert to 'mobile/chrome/content/content.css' really helps. Should it be a part of this fix?

That said, I'm getting a bit spoiled and now would like to eventually also get bilinear scaling for video and pinch zoom in addition to static images. Hopefully with some more performance tuning it may become possible. But it's probably better to track these as a separate bug.
(In reply to comment #47)
> That said, I'm getting a bit spoiled and now would like to eventually also get
> bilinear scaling for video and pinch zoom in addition to static images.
> Hopefully with some more performance tuning it may become possible. But it's
> probably better to track these as a separate bug.

We should get these when we enable OpenGL on mobile (bug 607684).
(In reply to comment #47)
> (In reply to comment #46)
> > in Fennec you probably want content.css - which is the CSS used for web
> > content.
> 
> Thanks, adding the chunk suggested by Robert to
> 'mobile/chrome/content/content.css' really helps. Should it be a part of this
> fix?

You can add a patch for mobile-broswer to this bug and we can land them together.
(In reply to comment #48)
> (In reply to comment #47)
> > That said, I'm getting a bit spoiled and now would like to eventually also get
> > bilinear scaling for video and pinch zoom in addition to static images.
> > Hopefully with some more performance tuning it may become possible. But it's
> > probably better to track these as a separate bug.
> 
> We should get these when we enable OpenGL on mobile (bug 607684).

Is OpenGL going to be enabled soon? And will it work properly on all the supported devices?

I think an update for pixman NEON optimizations to address some of the newly discovered performance hotspots is quite doable in a timeframe of one or two weeks. Also I would prefer to ensure at least high quality playback of 360p webm videos from youtube without dropping frames on Nokia N900 (600MHz ARM Cortex-A8) because this annoyed me the most.
(In reply to comment #51)

> Is OpenGL going to be enabled soon? And will it work properly on all the
> supported devices?

NEON optimizations are welcome. Not every device will likely have OpenGL supported and we don't have a firm timeline for OpenGL yet, iirc.
Comment on attachment 523911 [details] [diff] [review]
mobile-nearest-scaling-for-video.diff

Looks OK
Attachment #523911 - Flags: review+
Jeff - Do you have time for this review? I'd like to get it on the next aurora push.
Has anyone done tests to make sure the performance impact of this is acceptable?
performance is acceptable on an atrix IMO, which is the only device without neon support
and if we get more feedback about poor performance from aurora users, we can easily back it out.
(In reply to comment #55)
> Has anyone done tests to make sure the performance impact of this is
> acceptable?

We've done only eyeball testing so far.  We should also do Tp testing with Zipity, or on a project branch with mobile Talos coverage.  (I don't think we have mobile Talos on Try Server.)

There will definitely be some performance regression, so we need to define what is an "acceptable" trade-off of image quality for speed.  (Or as I like to say, how much are we willing to make the web look crappy in order to run faster?)
Attachment #523716 - Flags: review?(jmuizelaar) → review+
Attached patch patch for checkin (obsolete) — Splinter Review
Attachment #523716 - Attachment is obsolete: true
Attachment #524657 - Flags: review+
Landed: http://hg.mozilla.org/mozilla-central/rev/67f4aa2eebcd
http://hg.mozilla.org/mozilla-central/rev/a34ae0a805e0
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.2
this patch causes a pretty huge regression in terms of repainting after the fuzzy zoom.  During a zoom, after you lift your fingers, there is around a 4 second delay before the repaint on the Tab.  For the Nexus S, it is a bit over 1s.  When I revert these changes, I see about 1-2 seconds for the Tab, and something under a second for the S.

reopening.  i think we should back this out.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
First, can the use of bilinear scaling actually become a runtime configurable option (basically getting back to comment 23)?

Second question. Which web page are you using for testing? The delay you are observing there seems to be higher than normal.
(In reply to comment #63)
> When I revert these changes, I see about 1-2 seconds for the Tab, and
> something under a second for the S.

I mean, isn't 1-2 seconds time already very bad even without higher quality scaling? Something must be wrong.
(In reply to comment #64)
> First, can the use of bilinear scaling actually become a runtime configurable
> option (basically getting back to comment 23)?
> 

You can put disable it for images in content.css just like you did with video. Or as a user you can edit userContent.css to enable/disable it for whatever tags you want.
(In reply to comment #66)
> You can put disable it for images in content.css just like you did with video.
> Or as a user you can edit userContent.css to enable/disable it for whatever
> tags you want.

I seriously don't want to do that as a *user* of Fennec :) I would prefer a simple checkbox.
backed out until we can figure this out:

http://hg.mozilla.org/mozilla-central/rev/9a7c40dbd288
Depends on: 649041
Whiteboard: [fennec-6]
Would it make some sense to treat this bug as a meta-bug and add a set of practical problems to solve as dependencies here (such as having bug 648951 as a dependency but not a duplicate)?
Assignee: mbrubeck → nobody
Status: REOPENED → NEW
Keywords: mobile, perf
tracking-fennec: 2.0next+ → 6+
Whiteboard: [fennec-6]
Depends on: 656782
tracking-fennec: 6+ → 7+
I just wonder if this bug may need to be somehow split to track GPU scaling and NEON scaling separately? Either of these can be probably sufficient.

But in order for NEON scaling to fly, some easy way for the users to enable higher quality scaling is needed. So that they can discover and report the use cases where performance is still not sufficient. Otherwise there will be no way to have good quality images when browsing (pixelated scaled images are very ugly, image galleries are quite painful to use right now), no bugreports in bugzilla and hence no progress.

Even now pixman 0.22.0 has more NEON optimizations for bilinear scaling than the built-in mozilla's copy. But they are likely not providing a complete coverage yet. Which optimizations exactly are still missing? This is yet to be figured out. But I guess http://ie.microsoft.com/testdrive/performance/fishietank/ would be a good start (there needs to be a bug for tracking improving its performance in Fennec).
I actually merged upstream pixman into mozilla-central yesterday, so it might be worth trying this out again.
(In reply to comment #72)
> I actually merged upstream pixman into mozilla-central yesterday, so it
> might be worth trying this out again.

OK, thanks. That's great.
Most of the regression caused by this patch is now fixed by the latest pixman changes (see bug 648951 comment 12).

We can't aim for zero regression:  Nearest-neighbor scaling will always be somewhat faster (and uglier) than bilinear.  But at the current level of performance I think the trade-off is well worth it.  Can we re-land this patch now?  If not, what criteria would people like to see for landing?

Are there specific metrics we need as additional input here, and if so, how will those metrics be used to make a decision?  What are the key test cases, and how slow would they need to be for us to stick with low-quality scaling?
The patches probably need to be modified to have bilinear scaling enabled only if NEON is available. Otherwise the performance will be really bad on Tegra2 devices, as indirectly tested by bug 648951
matt, you going to modify the patch like Siarhei mentioned.  Also, this hurt perf last time you landed.  (specifically on the Galaxy Tab).  Do you have new data that suggests that this isn't a probably any longer?
(In reply to comment #76)
> matt, you going to modify the patch like Siarhei mentioned.  Also, this hurt
> perf last time you landed.  (specifically on the Galaxy Tab).  Do you have
> new data that suggests that this isn't a probably any longer?

matt, stopwatch times on the galaxy tab _with_ the patches would be enough for me. we can make a decision based on those numbers.
> stopwatch times on the galaxy tab _with_ the patches would be enough for me. we can make a decision based on those numbers.

stopwatch times are available in bug 648951 comment 12

oprofile data is available in bug 648951 comment 6
Attached patch patch v2Splinter Review
Updated to use bilinear/good scaling on devices that support NEON, while sticking with nearest/fast for all other devices (when MOZ_GFX_OPTIMIZE_MOBILE is enabled).

In addition to the tests on Galaxy tab referenced above, tested on Motorola Xoom (Tegra 2, no NEON support).  With the old patch from this bug, the Xoom used bilinear scaling and the test case from bug 648951 takes >1s.  With this new patch, the Xoom continues to use nearest-neighbor scaling and zooming latency is <0.5s (same as trunk without any patches).
Assignee: nobody → mbrubeck
Attachment #524657 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #534857 - Flags: review?(jmuizelaar)
Comment on attachment 534857 [details] [diff] [review]
patch v2

Does mozilla::supports_neon() work on non-arm platforms?
> > stopwatch times on the galaxy tab _with_ the patches would be enough for me. we can make a decision based on those numbers.
> 
> stopwatch times are available in bug 648951 comment 12
> 
> oprofile data is available in bug 648951 comment 6

based on those numbers, a=mfinkle to land for additional testing, once you get r+ on the new patch.
(In reply to comment #80)
> Does mozilla::supports_neon() work on non-arm platforms?

yes, that was discussed in bug 656797 comment 4
Attachment #534857 - Flags: review?(jmuizelaar) → review+
(In reply to comment #80)
> Does mozilla::supports_neon() work on non-arm platforms?

Yes.  On platforms without MOZILLA_MAY_SUPPORT_NEON, it is defined as:

  inline bool supports_neon() { return false; }
http://hg.mozilla.org/projects/cedar/rev/a45a4abce7ce
Whiteboard: [fixed-in-cedar]
Target Milestone: mozilla5 → ---
http://hg.mozilla.org/mozilla-central/rev/a45a4abce7ce
Status: ASSIGNED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-cedar]
Target Milestone: --- → mozilla7
Note that although this bug is resolved, the current solution (software scaling with NEON optimizations) works only on devices with NEON support.

Devices without NEON (any device with a Tegra processor, including the Atrix, Xoom, Iconia A500, Vega, Optimus 2X, Optimus Pad, G Tablet, etc.) are still using nearest neighbor scaling.  Bug 650988 looks like the most likely plan to fix this.

(I'm curious what WebKit and Opera do on these devices to get fast, high-quality scaling without NEON.  Are they using the GPU, or just better software scaling?)
(In reply to comment #86)
> I'm curious what WebKit and Opera do on these devices to get fast,
> high-quality scaling without NEON.

Tegra2 still supports ARMv6 style SIMD instructions, which can also provide some measurable speedup for bilinear scaling (not implemented in pixman, and I myself have no plans for doing such optimizations at the moment).

Another thing is that bilinear scaling r5g6b5->r5g6b5 is slower than a8r8g8b8->a8r8g8b8 or a8r8g8b8->r5g6b5. That's because interpolation is done with a8r8g8b8, and some extra color format conversions may be involved. So keeping images in a8r8g8b8 format may be faster if they are used as the source images for bilinear scaling (with its own disadvantages: bigger RAM footprint and slower non-scaled blits).
Comment on attachment 523911 [details] [diff] [review]
mobile-nearest-scaling-for-video.diff

Missed this patch earlier; pushed to mozilla-central now for Firefox 7:
http://hg.mozilla.org/mozilla-central/rev/4ed9e3297485

Requesting mozilla-approval-aurora for both patches in this bug.  This is a top user complaint, and it is a competiveness/parity issue (makes Firefox visibly worse than all other Android browsers).  Both patches affect mobile only.
Attachment #523911 - Flags: approval-mozilla-aurora?
Attachment #534857 - Flags: approval-mozilla-aurora?
Attachment #534857 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Attachment #523911 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
tracking-fennec: 7+ → 6+
Depends on: 669851
Depends on: 678223
Depends on: 750172
You need to log in before you can comment on or make changes to this bug.