1458387 - https://www.oculus.com/go/ page has janky scrolling due to imagelib

Status: RESOLVED WORKSFORME

(Core :: Graphics: WebRender, enhancement, P2)

Description

[Jeff Muizelaar [:jrmuizel]]

Near the "Immerse yourself in over 1,000 VR games, social apps, 360° experiences, and more." section things get really slow. It looks like something bad is happening with imagelib.

https://perfht.ml/2I9L2pu

Comment 1

[Andrew Osmond [:aosmond] (he/him)]

I expect bug 1337111 will help with this. You can see it spends a lot of time advancing the animation (e.g. doing the frame blending) and uploading the composited frame via an ImageClient. The bug will move the blending off the main thread, making RasterImage::RequestFrame very cheap, and it will also decode the frames into shared surfaces, avoiding the image client overhead.

Comment 2

[Andrew Osmond [:aosmond] (he/him)]

Also interesting is the ScopedMap (de)allocation showing up in the trace for the imgFrame DrawableSurface. I have a patch to remove this extra malloc somewhere, I'll get that landed in a new bug.

Comment 3

[Jeff Muizelaar [:jrmuizel]]

The time that we spend doing the blend is an unreasonable 18ms. I suspect there's something more serious going wrong here. It would be good to see what the dimensions of the image that's being blended is.

Comment 4

[Andrew Osmond [:aosmond] (he/him)]

The picture in question is composed of several stills and at least one animated image. The flag itself is an animated PNG, and is 2000x1000 -- it might contain the lights as well, it wasn't easy to tell just looking at the page. Past experience tells me I should expect that to be expensive, although I haven't checked for a bug. Since each frame will consume 7.62MB, so it will certainly be triggering the discard after displayed code to minimize memory usage at the cost of CPU. Perhaps I need to consider the total animation time as well, to allow a higher footprint for short (human time) animations...

Comment 5

[Andrew Osmond [:aosmond] (he/him)]

Animated images in question:

https://scontent-yyz1-1.xx.fbcdn.net/v/t39.2365-6/29918803_356351821525660_4255740788454981632_n.png?_nc_cat=0&oh=257a48ee87cf933310a17481ab174e91&oe=5B5C62C0

https://scontent-yyz1-1.xx.fbcdn.net/v/t39.2365-6/30179736_210889692838846_6941318271673040896_n.png?_nc_cat=0&oh=34fc79f0cdf8a11023508de853253022&oe=5B8F655D

Comment 6

[Jeff Muizelaar [:jrmuizel]]

Andrew, where did we end up with this one?

Comment 7

[Andrew Osmond [:aosmond] (he/him)]

I got much better decoder performance with bug 1337111 and bug 1465619. I need those to land (in order) before I can then get async image pipeline which in theory should get us the rest of the way. I keep getting interrupted on the last piece but it isn't important if the previous bugs don't land.

Comment 8

[Jeff Muizelaar [:jrmuizel]]

I had a look at this on Windows and it was Ok, but not great. https://perfht.ml/2Ju5P3C

The bulk of the time is sending the image across to WebRender. It looks like we create a new Shmems on every frame. Can this be avoided?

I'm lowering the priority for now because it's not as bad on Windows.

Comment 9

[Maire Reavy [:mreavy]]

Jeff -- Is this still a P2?

Comment 10

[Andrew Osmond [:aosmond] (he/him)]

Update: This is finally coming together with bug 1504699. That's the last piece to solve the animated image perf issues on this page.

Comment 11

[Andrew Osmond [:aosmond] (he/him)]

The page has changed, but the now integrated changes fixed all the image related problems.