Граф коммитов

21 Коммитов

Автор SHA1 Сообщение Дата
Andrew Osmond 98da085964 Bug 1516011 - Part 2. Deny recycling for frames used in blob recordings. r=tnikkel
Given the crash resolved in part 1, it is possible for the blob
rasterizer in the compositor process to still be using surfaces after
the animation has advanced to the next frame. With recycling this can be
problematic as the recycled surface will be reused for a future frame.
In an ideal world, the blob recording would use the animation's image
key instead, but the rasterizer doesn't have easy access to the mapping
table. As such, for any frames used in a blob recording, we now
explicitly mark them as non-recyclable and we will be forced to allocate
a new frame instead.

Differential Revision: https://phabricator.services.mozilla.com/D16192
2019-01-14 13:21:57 -05:00
Sylvestre Ledru ad75e912fb Bug 1512961 - Reformat recent changes to the Google coding style r=Ehsan
# ignore-this-changeset

Differential Revision: https://phabricator.services.mozilla.com/D14060

--HG--
extra : moz-landing-system : lando
2018-12-10 19:23:16 +00:00
Andrew Osmond 44950c504e Bug 1510601 - Part 2. Improve recycling of frames when an animation is reset. r=tnikkel
When an animation is reset, we can actually avoid the reallocations by
keeping the frames in the mRecycle and mDiscard queues. There is no real
need to do this. We just need to make sure the recycle rect calculation
is done appropriately, particularly when we haven't reached the end yet
and thus don't know the first frame refresh area yet.

Differential Revision: https://phabricator.services.mozilla.com/D13465
2018-12-05 12:04:20 -05:00
Andrew Osmond cea6adbea8 Bug 1510601 - Part 1. Move size increments into AnimationFrameBuffer::InsertInternal. r=tnikkel
The size was originally incremented in AnimationFrameBuffer::Insert
however if an animation was reset before we finished decoding, it would
count some frames twice in the counter. Now we increment it inside
InsertInternal, where AnimationFrameDiscardingQueue can make a more
informed decision on whether the frame is a duplicate or not.

Additionally we now fail explicitly when we insert more frames on
subsequent decodes than the original decoders. This will help avoid
getting out of sync with FrameAnimator.

Differential Revision: https://phabricator.services.mozilla.com/D13464
2018-12-05 12:04:20 -05:00
Andrew Osmond 3e702d9e23 Bug 1501923 - Fix crash where we reset an animation just before crossing the discard threshold. r=tnikkel
If an animated frame buffer was reset just before the necessary frame to
cross the discard threshold, followed by said frame being inserted by
the decoder, it would insert a null pointer into the display queue for
the first frame. This is because it assumed that we have always advanced
past the first frame -- which was true, but the reset placed us back at
the beginning.

This would initially manifest to the user as the animation stopping,
since it could not advance past the first frame. Once a memory report
was requested, it would crash because we assume every frame in the
display queue is valid.

This patch removes the assumption about what frame we have advanced to.

Differential Revision: https://phabricator.services.mozilla.com/D13407
2018-12-05 12:04:20 -05:00
Sylvestre Ledru 265e672179 Bug 1511181 - Reformat everything to the Google coding style r=ehsan a=clang-format
# ignore-this-changeset

--HG--
extra : amend_source : 4d301d3b0b8711c4692392aa76088ba7fd7d1022
2018-11-30 11:46:48 +01:00
Andrew Osmond a24f72635e Bug 1509408 - Fix animated image distortion regressions caused by frame recycling. r=tnikkel
When bug 1508393 landed, it not only enabled producing of full frames
on the decoder threads, it also enabled recycling of old animated image
frame buffers it would have otherwise discarded. It reuses the contents
of the buffer where possible given we know what pixels changed between
the old frame and the frame we want to produce. However where this
calculation was done was incorrect. We originally calculated it when we
advanced the frame, but at that point there is no guarantee that we have
all of the necessary information; we may have fallen behind on decoding.
As such, we move the calculation to where we actually perform the
recycling. At this point we are guaranteed to have all the necessary
frames between the recycling and display queues.

Differential Revision: https://phabricator.services.mozilla.com/D12903
2018-11-28 06:57:39 -05:00
Andrew Osmond 833f74105e Bug 1504699 - Part 7. Update animated image recycling queue to work well with WebRender. r=tnikkel
WebRender takes longer than OMTP to release its hold on the current
frame. This is because it is in a separate process and holds onto the
surface in between rendering frames, rather than getting a reference for
each repaint. This patch makes us less aggressive about taking the most
recent surface placed in the recycling queue out to avoid blocking on
waiting for the surface to be released.

Differential Revision: https://phabricator.services.mozilla.com/D10903
2018-11-21 06:47:06 -05:00
Andrew Osmond d78eab076c Bug 1501212 - Fix faulty assert when requesting a frame from a previously discarded animated image. r=tnikkel
We should only assert that the caller is requesting the first frame or
we have advanced to or beyond the expected initial frame, when we
successfully return a frame. This is because FrameAnimator will request
on refresh ticks for the current frame again, until it observes it. If
decoding is still behind, then we likely still have frames to
auto-advance, and we will trip the assert.

Differential Revision: https://phabricator.services.mozilla.com/D9507
2018-10-26 07:50:23 -04:00
Andrew Osmond 8066d5c0b3 Bug 1501120 - Fix faulty assert when calculating memory footprint of animation. r=tnikkel
Differential Revision: https://phabricator.services.mozilla.com/D9506
2018-10-26 07:50:21 -04:00
Andrew Osmond 0f2cb305c1 Bug 1465619 - Part 11. Add support for recycling animated image frames. r=tnikkel
This is what we have been working towards in all of the previous parts
in the series. This subclasses AnimationFrameDiscardingQueue to save the
discarded frames for recycling by the decoder, if the frame is marked as
supporting recycling.

Differential Revision: https://phabricator.services.mozilla.com/D7516
2018-10-22 13:40:35 -04:00
Andrew Osmond fa96750373 Bug 1465619 - Part 10. Re-add support for discarding animated image frames. r=tnikkel
AnimatedFrameDiscardingQueue subclasses AnimationFrameBuffer to allow a
cleaner abstraction over the behaviour change when we cross the
threshold of too high a memory footprint for an animated image. The next
patch will build on top of this to provide an abstraction to reuse the
discarded frames.

Differential Revision: https://phabricator.services.mozilla.com/D7515
2018-10-22 13:40:35 -04:00
Andrew Osmond f525b64a4b Bug 1465619 - Part 9. Use redesigned AnimationFrameBuffer interface and retaining buffer. r=tnikkel
This patch makes AnimationSurfaceProvider use the new abstractions
provided by AnimationFrameBuffer and AnimationFrameRetainedBuffer to
provide storage and lifetime management of decoders and the produced
frames. We initially start out with an implementation that will just
keep every frame forever, like our historical behaviour. The next patch
will add support for discarding.

Differential Revision: https://phabricator.services.mozilla.com/D7514
2018-10-22 13:40:35 -04:00
Andrew Osmond 561519762d Bug 1465619 - Part 8. Remove the old AnimationFrameBuffer implementation. r=tnikkel
In the next few patches, AnimationFrameBuffer will be reworked to split
the discarding behaviour from the retaining behaviour. Once implemented
as separate classes, it will allow easier reuse of the discarding code
for recycling.

Differential Revision: https://phabricator.services.mozilla.com/D7513
2018-10-22 13:40:35 -04:00
Emilio Cobos Álvarez fffb25b74f Bug 1465585: Switch from mozilla::Move to std::move. r=froydnj
This was done automatically replacing:

  s/mozilla::Move/std::move/
  s/ Move(/ std::move(/
  s/(Move(/(std::move(/

Removing the 'using mozilla::Move;' lines.

And then with a few manual fixups, see the bug for the split series..

MozReview-Commit-ID: Jxze3adipUh
2018-06-01 10:45:27 +02:00
Andrew Osmond 8c7d13e7f7 Bug 1462355 - Part 5. Avoid converting from DrawableFrameRef to RawAccessFrameRef. r=tnikkel
DrawableSurface only exposes DrawableFrameRef to its users. This is
sufficient for the drawing related code in general, but FrameAnimator
really needs RawAccessFrameRef to the underlying pixel data (which may
be paletted). While one can get a RawAccessFrameRef from a
DrawableFrameRef, it requires yet another lock of the imgFrame's mutex.
We can avoid this extra lock if we just allow the callers to get the
right data type in the first place.
2018-05-29 08:36:12 -04:00
Andrew Osmond 5f0abb12dc Bug 1444537 - Part 3. Fix how redecode errors could cause animated image state inconsistencies. r=tnikkel
We can discard frames from an animated image if the memory footprint
exceeds the threshold. This will cause us to redecode frames on demand
instead. However decoders can fail to produce the same results on
subsequent runs due to differences in memory pressure, etc. If this
happens our state can get inconsistent. In particular, if we keep
failing on the first frame, we end up in an infinite loop on the decoder
thread.

Since we don't have the owning image to signal, as we had to release our
reference to it after the first pass, we can do little but stop decoding.
From the user's perspective, the animation will come to a stop.
2018-04-24 13:51:35 -04:00
Cosmin Sabou 6c47714197 Backed out 2 changesets (bug 1444537) for causing crashes on test_discardFramesAnimatedImage.html. a=backout
Backed out changeset 0d23d74448c8 (bug 1444537)
Backed out changeset 07f5d48b90cb (bug 1444537)
2018-04-15 02:40:30 +03:00
Andrew Osmond 2e06ac3032 Bug 1444537 - Part 3. Fix how redecode errors could cause animated image state inconsistencies. r=tnikkel
We can discard frames from an animated image if the memory footprint
exceeds the threshold. This will cause us to redecode frames on demand
instead. However decoders can fail to produce the same results on
subsequent runs due to differences in memory pressure, etc. If this
happens our state can get inconsistent. In particular, if we keep
failing on the first frame, we end up in an infinite loop on the decoder
thread.

Since we don't have the owning image to signal, as we had to release our
reference to it after the first pass, we can do little but stop decoding.
From the user's perspective, the animation will come to a stop.
2018-04-13 10:58:52 -04:00
Andrew Osmond a21bbb89ce Bug 1444537 - Part 1. Ensure discarding of animated image frames is clear. r=tnikkel
We should only attempt to discard animation image frames after passing
the frame threshold on the very first pass on the animation. Redecodes
are already in the correct state, as it will discard frames as it
advances the animation. This patch makes it clear what it should be
doing when, but there should be no functional change.
2018-03-27 10:56:48 -04:00
Andrew Osmond 984f23cd9c Bug 523950 - Part 7. Add AnimatedFrameBuffer to manage storage and decoding of frames in an animation. r=tnikkel 2018-02-28 13:34:52 -05:00