In the newest firefox version its working fine.

Hello,

Could you please provide us with more information (any errors in the Console, example animation of where it is happening)? Also, please make sure that the bug is not fixed in the latest update on other channels, such as canary or beta.

– brxxn :)

The bug exists on every Computer using The Chrome Browser in The newest
Version. On every Channel (Beta, stable oder canary). All Animations are
Not working fine. All! I think chrome is the problem, not the website. On
Microsoft Edge and Firefox everything works fine as it ever did.

brxxnchr… via monorail <monorail+v2.1791611639@chromium.org> schrieb am
Do., 24. Nov. 2016, 03:04:

vmiura says he will create a repro case for this.

I reproduced a lot of jank with the following "Flip" transition animation.  This animation looks quite a lot smoother on Firefox & Safari.  There is also some layer clipping going on with Chrome.

Slides animation: https://docs.google.com/presentation/d/11ixCCgj3JdO9FkQfnisVpIlA0JdAyXekeTCcEE10b_Y/view

Chrome: https://drive.google.com/file/d/0B3AHeFWLg1GyMUhpTGhmSW5DS2s/view
Firefox: https://drive.google.com/file/d/0B3AHeFWLg1GyQzU1VmRBQkwzV2M/view

This is a trace of the first "Flip" animation.

There's very large amount of time per frame in the following, which is unusual for the ~29 layers.

  GraphicsLayerUpdater::update > 34ms
  LayerTreeHostImpl::DrawLayers > 60ms
  CompositorFrame Send IPCs total > 60ms

Deleted: trace_slides.json.gz 1.3 MB

trace_slides.json.gz 1.3 MB Download

Deleted: trace_slides_with_debug.json.gz 25.5 MB

trace_slides_with_debug.json.gz 25.5 MB Download

TL;DR unaccelerated raster to bitmap for box-reflect is slow, and subsequently IPC of the SkFilter with embedded bitmap is uber slow.

This is from Instruments profile on OS X running the animation repeatedly.

* Renderer Mainthread [Box-reflect filter rendered to SkBitmap takes a long time]

Weight         Self Weight  Symbol Name
2.69 s  15.5%  0 s          blink::PaintLayerCompositor::updateIfNeeded()
2.65 s  15.3%  0 s           blink::GraphicsLayerUpdater::update(blink::PaintLayer&, ...)
2.65 s  15.3%  1.00 ms        blink::GraphicsLayerUpdater::updateRecursive(blink::PaintLayer&, ...)
2.64 s  15.2%  1.00 ms         blink::CompositedLayerMapping::updateGraphicsLayerGeometry(blink::PaintLayer const*, blink::PaintLayer const*, WTF::Vector<blink::PaintLayer*, 0ul, WTF::PartitionAllocator>&)
2.59 s  15.0%  0 s              blink::PaintLayer::createCompositorFilterOperationsForFilter(blink::ComputedStyle const&)
2.54 s  14.6%  0 s               blink::FilterEffectBuilder::buildFilterOperations(blink::FilterOperations const&) const
2.53 s  14.6%  2.00 ms            blink::SkiaImageFilterBuilder::buildBoxReflectFilter(blink::BoxReflection const&, sk_sp<SkImageFilter>)
1.25 s   7.2%  1.00 ms             SkImage::MakeFromBitmap(SkBitmap const&)
1.25 s   7.2%  0 s                  SkMakeImageFromRasterBitmap(SkBitmap const&, SkCopyPixelsMode)
1.25 s   7.2%  0 s                   SkImage::MakeRasterCopy(SkPixmap const&)


* Renderer Compositor Thread [serializing a large Bitmap image as part of cc::FilterOperation]

Weight         Self Weight  Symbol Name
4.19 s  24.2%  2.00 ms      content::RendererCompositorFrameSink::SubmitCompositorFrame(cc::CompositorFrame)
4.18 s  24.2%  0 s           IPC::MessageT<ViewHostMsg_SwapCompositorFrame_Meta, ...)
4.18 s  24.2%  1.00 ms        IPC::ParamTraits<std::__1::tuple<unsigned int const&, cc::CompositorFrame const&...)
4.18 s  24.1%  0 s             IPC::ParamTraits<cc::CompositorFrame>::Write(base::Pickle*, cc::CompositorFrame const&)
2.15 s  12.4%  0 s              IPC::ParamTraits<cc::FilterOperation>::GetSize(base::PickleSizer*, cc::FilterOperation const&)
2.15 s  12.4%  2.00 ms           SkValidatingSerializeFlattenable(SkFlattenable*)
1.59 s   9.1%  0 s                SkBinaryWriteBuffer::writeFlattenable(SkFlattenable const*)
1.59 s   9.1%  0 s                 SkXfermodeImageFilter_Base::flatten(SkWriteBuffer&) const
1.59 s   9.1%  0 s                  SkImageFilter::flatten(SkWriteBuffer&) const

* Renderer IO Thread [busy flushing large IPC]

Weight          Self Weight  Symbol Name
8.48 s  49.0%	0 s          base::RunLoop::Run()
8.48 s  49.0%	0 s           base::MessageLoop::RunHandler()
8.46 s  48.9%	6.00 ms        base::MessagePumpLibevent::Run(base::MessagePump::Delegate*)
5.86 s  33.9%	4.00 ms         base::MessageLoop::DoWork()
5.84 s  33.7%	0 s              base::MessageLoop::DeferOrRunPendingTask(base::PendingTask)
5.84 s  33.7%	0 s               base::MessageLoop::RunTask(base::PendingTask*)
5.84 s  33.7%	0 s                base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*)
5.83 s  33.7%	0 s                 IPC::ChannelMojo::Send(IPC::Message*)
2.52 s  14.5%	26.00 ms        event_base_loop
1.57 s   9.0%	17.00 ms         base::MessagePumpLibevent::OnLibeventNotification(int, short, void*)
1.50 s   8.6%	13.00 ms          non-virtual thunk to mojo::edk::(anonymous namespace)::ChannelPosix::OnFileCanWriteWithoutBlocking(int)
1.47 s   8.4%	108.00 ms          mojo::edk::(anonymous namespace)::ChannelPosix::FlushOutgoingMessagesNoLock()

It's hard to say that the original report is exactly the same problem.  p...9@googlemail.com it would be helpful if you can share an actual example URL.  The one in the original post is not complete.

At a guess, I'd say this is related to jbroman@'s changes for box-reflect. (A bisect would confirm).

It does seem odd that bitmap images are being sent via filter IPC. That's never going to be particularly fast.

box-reflect can have images in it. It's currently unsafe to pass an
SkPictureFilter across IPC, so we intentionally convert it into a bitmap in
such cases. See https://codereview.chromium.org/2379453002/

Note that -webkit-box-reflect is not widely supported and we do not anticipate
standardizing it. I recommend moving away from this property for that reason.

chrishtr: Google Slides is using the -webkit-box-reflect property in Chrome for it's 'Flip' transition and 'Cube' transition effects, and using something else (perspective 3D transform?) in Firefox.  Do we plan to remove this feature from Chrome?

For sites that use this the performance is likely to be poor even when no re-paints are needed, since the bitmap transfer through IPC is not cached in any way.  I wonder if our rendering is also wrong?  See videos in #6.

I would like to remove the -webkit-box-reflect feature, but usage is currently too high
to allow it.

I suggest that Google Presentations change to the Firefox representation.

If the rendering is also wrong, please file a new bug, as this is probably a bug in our
filters implementation which should be fixed regardless of box-reflect.

Slides has been updated to not use -webkit-box-reflect.

FYI, here's a fiddle showing the rendering issue without animation: https://jsfiddle.net/p50c4psa/1/

Looks like adding the reflection messes up the 3D transform. Safari handles this example correctly.

Still broken.