searching for reviewer(tnikkel)
2ce8f6d1a64ef8ee845c595bc441234af72422fe: Bug 1465619 - Part 14. Add gtests for AnimationFrameRecyclingQueue. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Wed, 06 Jun 2018 10:31:53 -0400 - rev 490716
Push
247 by fmarier@mozilla.com at Sat, 27 Oct 2018 01:06:44 +0000
Bug 1465619 - Part 14. Add gtests for AnimationFrameRecyclingQueue. r=tnikkel
Differential Revision:
https://phabricator.services.mozilla.com/D7519
6bf7e20ce8fcd856eb8b11853ec94fb0172a9597: Bug 1465619 - Part 13. Add gtests for AnimationFrameDiscardingQueue. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Tue, 05 Jun 2018 15:29:09 -0400 - rev 490715
Push
247 by fmarier@mozilla.com at Sat, 27 Oct 2018 01:06:44 +0000
Bug 1465619 - Part 13. Add gtests for AnimationFrameDiscardingQueue. r=tnikkel
Differential Revision:
https://phabricator.services.mozilla.com/D7518
0bacfc8c286f858c822d309fcb49104d83191793: Bug 1465619 - Part 12. Add gtests for AnimationFrameRetainedBuffer. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Mon, 04 Jun 2018 11:08:16 -0400 - rev 490714
Push
247 by fmarier@mozilla.com at Sat, 27 Oct 2018 01:06:44 +0000
Bug 1465619 - Part 12. Add gtests for AnimationFrameRetainedBuffer. r=tnikkel
Differential Revision:
https://phabricator.services.mozilla.com/D7517
9c8e6aaa017625dd61942d3100316798c8c2ef61: Bug 1465619 - Part 11. Add support for recycling animated image frames. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Mon, 04 Jun 2018 08:33:16 -0400 - rev 490713
Push
247 by fmarier@mozilla.com at Sat, 27 Oct 2018 01:06:44 +0000
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
453d21db2a306f4800e8be4d77f6d61000cb9a0c: Bug 1465619 - Part 10. Re-add support for discarding animated image frames. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Mon, 04 Jun 2018 08:29:50 -0400 - rev 490712
Push
247 by fmarier@mozilla.com at Sat, 27 Oct 2018 01:06:44 +0000
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
bd9168e1e48ce09404664e250fdc151d301b98db: Bug 1465619 - Part 9. Use redesigned AnimationFrameBuffer interface and retaining buffer. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Mon, 04 Jun 2018 08:23:00 -0400 - rev 490711
Push
247 by fmarier@mozilla.com at Sat, 27 Oct 2018 01:06:44 +0000
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
ef6369b9a1f929ea65bfbb1adb63ceb42a6bba3f: Bug 1465619 - Part 8. Remove the old AnimationFrameBuffer implementation. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Mon, 04 Jun 2018 08:08:33 -0400 - rev 490710
Push
247 by fmarier@mozilla.com at Sat, 27 Oct 2018 01:06:44 +0000
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
6ef29bb729309b6c5fefa615a72cdcb897c7c473: Bug 1465619 - Part 7. Add support for recycling to image::Decoder. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Sun, 03 Jun 2018 19:42:24 -0400 - rev 490709
Push
247 by fmarier@mozilla.com at Sat, 27 Oct 2018 01:06:44 +0000
Bug 1465619 - Part 7. Add support for recycling to image::Decoder. r=tnikkel
The owner for the decoder may implement IDecoderFrameRecycler to allow
the decoder to request a recycled frame instead of allocating a new one.
If none are available, it will fallback to allocating a new frame.
Not only may the IDecoderFrameRecycler not have any frames available for
recycling, the recycled frame itself may still be in use by other
entities outside of imagelib. Additionally it may still be required by
BlendAnimationFilter to restore the previous frame's data. It may even
be the same frame as to restore. In the worst case, we will simply
choose to allocate an entirely new frame, just like before.
When we allocate a new frame, that means the old frame we tried to
recycle will be taken out of circulation and not reused again,
regardless of why it failed.
Differential Revision:
https://phabricator.services.mozilla.com/D7512
7a2954981481f2f9f7bae58709dd50f67dab7cba: Bug 1465619 - Part 6. Add support for recycling to imgFrame. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Sun, 03 Jun 2018 19:42:09 -0400 - rev 490708
Push
247 by fmarier@mozilla.com at Sat, 27 Oct 2018 01:06:44 +0000
Bug 1465619 - Part 6. Add support for recycling to imgFrame. r=tnikkel
Beyond the necessary reinitialization methods, we need to protect
ourselves from recycling a frame that some other entity in the browser
is still using. Generally speaking the animated surface will only be
used in imgFrame::Draw since we don't layerize animated images, which
will be safe. However with OMTP or blob recordings, we could retain a
reference to the surface outside the current stack context. Additional
if something calls RasterImage::GetImageContainer(AtSize) or
RasterImage::GetFrame(AtSize), it may also have a reference to the
surface for an indetermine period of time.
As such, if an imgFrame is a candidate for recycling, it will wrap
imgFrame::mLockedSurface in a RecyclingSourceSurface. Its job is to
track how many consumers there are still of the surface, so that after
we advance the animation, the decoder will know if there are still
outstanding consumers.
If the surface is still in use, it will block for a finite period of
time (the refresh interval) before giving up on reclaiming the surface,
and will allocate a new surface. The old surface can then remain in
circulation for as long as necessary without further blocking the
animation progression, since we stop recycling that surface/imgFrame.
Differential Revision:
https://phabricator.services.mozilla.com/D7511
ddaa812c31e4589b269dc622c6f6a1bd049f81ec: Bug 1465619 - Part 5. Move actual drawing in imgFrame::Draw outside the monitor. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Sun, 03 Jun 2018 19:37:17 -0400 - rev 490707
Push
247 by fmarier@mozilla.com at Sat, 27 Oct 2018 01:06:44 +0000
Bug 1465619 - Part 5. Move actual drawing in imgFrame::Draw outside the monitor. r=tnikkel
Since imgFrame::Draw will limit the drawing to only look at pixels that
we have written to and posted an invalidation for, there is no need to
hold the monitor while doing so. By taking the most expensive operation
outside the lock, we will minimize our chances of hitting contention
with the decoder thread.
A later part in this series will require that a surface be freed outside
the lock because it may end up reacquiring it. In addition to the
contention win, this change should facilitate that.
Differential Revision:
https://phabricator.services.mozilla.com/D7510
edeea0a49a3322a3af796fba2f582ed0f1f6bd5f: Bug 1465619 - Part 4. Move the first frame refresh area calculation to frame commit. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Sun, 03 Jun 2018 19:21:48 -0400 - rev 490706
Push
247 by fmarier@mozilla.com at Sat, 27 Oct 2018 01:06:44 +0000
Bug 1465619 - Part 4. Move the first frame refresh area calculation to frame commit. r=tnikkel
If we discard a frame during decoding, e.g. due to an error, then we
don't want to take that frame into account for the first frame refresh
area. We should also be handling partial frames here (the dirty rect
needs to encompass the rows that did not get written with actual pixel
data). The only place that can have the necessary information is at the
end rather than at the beginning.
Differential Revision:
https://phabricator.services.mozilla.com/D7509
fc76b59e51b4f9faf21f40f2f518a94ce87ea100: Bug 1465619 - Part 3. Improve the clear rect calculations to take into account recycling in BlendAnimationFilter. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Thu, 31 May 2018 11:43:15 -0400 - rev 490705
Push
247 by fmarier@mozilla.com at Sat, 27 Oct 2018 01:06:44 +0000
Bug 1465619 - Part 3. Improve the clear rect calculations to take into account recycling in BlendAnimationFilter. r=tnikkel
The clear rect and the recycle rect can overlap, and depending on the
size of the clear rect, it could be a significant amount of data that
needs to be copied from the restore frame. This patch minimizes the
copying for a row which contains both the recycle rect and the clear
rect.
Differential Revision:
https://phabricator.services.mozilla.com/D7508
847e8234669346a34af39546b1e64c93f8a8e882: Bug 1465619 - Part 2. Add basic support for recycling a frame buffer to BlendAnimationFilter. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Sun, 03 Jun 2018 19:06:24 -0400 - rev 490704
Push
247 by fmarier@mozilla.com at Sat, 27 Oct 2018 01:06:44 +0000
Bug 1465619 - Part 2. Add basic support for recycling a frame buffer to BlendAnimationFilter. r=tnikkel
Given an invalidation rect, called the recycle rect, which represents
the area which may have changed between the current frame and the frame
we are recycling, we can not only reuse the buffer itself to avoid an
allocation and free, we can also avoid copying pixel data from the
restore frame which is already set.
Differential Revision:
https://phabricator.services.mozilla.com/D7507
b2a31a31fba6da90949b485e1728ef2dee40450e: Bug 1465619 - Part 1. Use imgFrame directly instead of RawAccessFrameRef in FrameAnimator. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Sun, 03 Jun 2018 18:49:23 -0400 - rev 490703
Push
247 by fmarier@mozilla.com at Sat, 27 Oct 2018 01:06:44 +0000
Bug 1465619 - Part 1. Use imgFrame directly instead of RawAccessFrameRef in FrameAnimator. r=tnikkel
When blending full frames off the main thread, FrameAnimator no longer
requires access to the raw data of the frame to advance the animation.
Now we only request a RawAccessFrameRef for the current/next frames when
we have discovered that we need to do blending on the main thread.
In addition to avoiding the mutex overhead of RawAccessFrameRef, this
will also facilitate potentially optimizing the surfaces for the
DrawTarget for individual animated image frames.
Differential Revision:
https://phabricator.services.mozilla.com/D7506
81cff62bc428d4fc54c81d0445b69ad554b31cda: Bug 1466707 - Ensure that animated images always honour the animated image mode. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Fri, 12 Oct 2018 14:25:49 -0400 - rev 489765
Push
247 by fmarier@mozilla.com at Sat, 27 Oct 2018 01:06:44 +0000
Bug 1466707 - Ensure that animated images always honour the animated image mode. r=tnikkel
Animated images inside of SVGs and used in XUL frames did not get the
configured animation image mode from the pres context.
Differential Revision:
https://phabricator.services.mozilla.com/D8586
2f9c84f3d1945ea745249d907634280cf0636cca: Bug 1492930 - Part 6. Integrate extra shared surface memory reporting with imagelib. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Tue, 25 Sep 2018 09:13:52 -0400 - rev 486441
Push
246 by fmarier@mozilla.com at Sat, 13 Oct 2018 00:15:40 +0000
Bug 1492930 - Part 6. Integrate extra shared surface memory reporting with imagelib. r=tnikkel
87d4667da724957285cdc384b35cf0f554ca82b8: Bug 1492930 - Part 4. Add ImageMemoryReporter to support extra shared surfaces reporting. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Tue, 25 Sep 2018 09:13:51 -0400 - rev 486439
Push
246 by fmarier@mozilla.com at Sat, 13 Oct 2018 00:15:40 +0000
Bug 1492930 - Part 4. Add ImageMemoryReporter to support extra shared surfaces reporting. r=tnikkel
By delegating responsibility for shared surfaces reporting to imagelib,
we can cross reference the GPU shared surfaces cache with the local
surface cache in a content process (or the main process). This will
allow us to identify entries that are in the GPU cache but not in the
content/main process cache, and aid in debugging memory leaks. This
functionality is pref'd off by default behind image.mem.debug-reporting.
Additionally, we want to report every entry that was mapped into the
compositor process, in the compositor process memory report. This will
give us a sense of how much of our resident memory is consumed by mapped
images in absence of the more detailed cross referencing above.
62ee015d33a6e36bdb0812687057d7623b382193: Bug 1492930 - Part 3. Expose all frames to image memory reporting. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Tue, 25 Sep 2018 09:13:51 -0400 - rev 486438
Push
246 by fmarier@mozilla.com at Sat, 13 Oct 2018 00:15:40 +0000
Bug 1492930 - Part 3. Expose all frames to image memory reporting. r=tnikkel
At present, surface providers roll up all of their individual surfaces
into a single reporting unit. Specifically this means animated image
frames are all reported as a block. This patch removes that
consolidation and reports every frame as its own SurfaceMemoryReport.
This is important because each frame may have its own external image ID,
and we want to cross reference that with what we expect from the GPU
shared surfaces cache.
9d1ff0d0af47c062842fdb82e2b1cc5453b3d7ca: Bug 1492930 - Part 6. Integrate extra shared surface memory reporting with imagelib. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Tue, 25 Sep 2018 06:18:07 -0400 - rev 486425
Push
246 by fmarier@mozilla.com at Sat, 13 Oct 2018 00:15:40 +0000
Bug 1492930 - Part 6. Integrate extra shared surface memory reporting with imagelib. r=tnikkel
2959314ecf7caaf5def4a05e280c732c5365027b: Bug 1492930 - Part 4. Add ImageMemoryReporter to support extra shared surfaces reporting. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Tue, 25 Sep 2018 06:18:06 -0400 - rev 486423
Push
246 by fmarier@mozilla.com at Sat, 13 Oct 2018 00:15:40 +0000
Bug 1492930 - Part 4. Add ImageMemoryReporter to support extra shared surfaces reporting. r=tnikkel
By delegating responsibility for shared surfaces reporting to imagelib,
we can cross reference the GPU shared surfaces cache with the local
surface cache in a content process (or the main process). This will
allow us to identify entries that are in the GPU cache but not in the
content/main process cache, and aid in debugging memory leaks. This
functionality is pref'd off by default behind image.mem.debug-reporting.
Additionally, we want to report every entry that was mapped into the
compositor process, in the compositor process memory report. This will
give us a sense of how much of our resident memory is consumed by mapped
images in absence of the more detailed cross referencing above.
587e01daa080af33c43fe71edf307e02c5a97eb2: Bug 1492930 - Part 3. Expose all frames to image memory reporting. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Tue, 25 Sep 2018 06:18:06 -0400 - rev 486422
Push
246 by fmarier@mozilla.com at Sat, 13 Oct 2018 00:15:40 +0000
Bug 1492930 - Part 3. Expose all frames to image memory reporting. r=tnikkel
At present, surface providers roll up all of their individual surfaces
into a single reporting unit. Specifically this means animated image
frames are all reported as a block. This patch removes that
consolidation and reports every frame as its own SurfaceMemoryReport.
This is important because each frame may have its own external image ID,
and we want to cross reference that with what we expect from the GPU
shared surfaces cache.
1e53e6af422382ae1ddfee87a7081810b51d8ac5: Bug 1456558 - Part 3. Implement factor of 2 scaling support for SVGs in VectorImage. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Thu, 20 Sep 2018 20:22:06 -0400 - rev 485877
Push
241 by fmarier@mozilla.com at Mon, 24 Sep 2018 21:48:02 +0000
Bug 1456558 - Part 3. Implement factor of 2 scaling support for SVGs in VectorImage. r=tnikkel
If FLAG_HIGH_QUALITY_SCALING is used, we should use
SurfaceCache::LookupBestMatch just like how it is done in RasterImage.
This may provide an alternative size at which we should rasterize the
SVG instead of the requested size. Since SurfaceCache imposes a maximum
size for which it will permit rasterized SVGs, we should also bypass the
cache entirely if we are well above that and simply draw directly to the
draw target in such cases.
With WebRender, it is somewhat more complicated. We will now return
NOT_SUPPORTED if the size is too big, and this should trigger fallback
to blob images. This should only produce drawing commands for the
relevant region and save us the high cost of rasterized a very large
surface on the main thread, which at the same time, looking as crisp as
a user would expect.
9884e2d81cbe037ed71687c47dd84674f8474408: Bug 1456558 - Part 2. Implement factor of 2 scaling support for SVGs in the surface cache. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Thu, 20 Sep 2018 20:22:03 -0400 - rev 485876
Push
241 by fmarier@mozilla.com at Mon, 24 Sep 2018 21:48:02 +0000
Bug 1456558 - Part 2. Implement factor of 2 scaling support for SVGs in the surface cache. r=tnikkel
There is one main difference between raster images and vector images
with respect to factor of 2 scaling. Vector images may be scaled
infinitely and so we need to extend factor of 2 scaling to permit
growing instead of just shrinking. Also, we don't want to scale
infinitely, so we should configure a maximum size limit. This size limit
will apply even outside of factor of 2 scaling, and so the caller
(VectorImage) will need to be careful to take this into account.
55c2dd9bdb3436b185a80ef675d222ff56b3e4a6: Bug 1456558 - Part 1. Move the allowed raster size calculation from imgFrame to SurfaceCache. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Thu, 20 Sep 2018 20:22:00 -0400 - rev 485875
Push
241 by fmarier@mozilla.com at Mon, 24 Sep 2018 21:48:02 +0000
Bug 1456558 - Part 1. Move the allowed raster size calculation from imgFrame to SurfaceCache. r=tnikkel
70d8f11cf6e8278b8e1509a69bd02adc0168e606: Bug 1456558 - Part 3. Implement factor of 2 scaling support for SVGs in VectorImage. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Thu, 20 Sep 2018 18:15:34 -0400 - rev 485870
Push
241 by fmarier@mozilla.com at Mon, 24 Sep 2018 21:48:02 +0000
Bug 1456558 - Part 3. Implement factor of 2 scaling support for SVGs in VectorImage. r=tnikkel
If FLAG_HIGH_QUALITY_SCALING is used, we should use
SurfaceCache::LookupBestMatch just like how it is done in RasterImage.
This may provide an alternative size at which we should rasterize the
SVG instead of the requested size. Since SurfaceCache imposes a maximum
size for which it will permit rasterized SVGs, we should also bypass the
cache entirely if we are well above that and simply draw directly to the
draw target in such cases.
With WebRender, it is somewhat more complicated. We will now return
NOT_SUPPORTED if the size is too big, and this should trigger fallback
to blob images. This should only produce drawing commands for the
relevant region and save us the high cost of rasterized a very large
surface on the main thread, which at the same time, looking as crisp as
a user would expect.
af9fc3daf97ca1ef1fe09587553deae1fa9c279c: Bug 1456558 - Part 2. Implement factor of 2 scaling support for SVGs in the surface cache. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Thu, 20 Sep 2018 18:15:32 -0400 - rev 485869
Push
241 by fmarier@mozilla.com at Mon, 24 Sep 2018 21:48:02 +0000
Bug 1456558 - Part 2. Implement factor of 2 scaling support for SVGs in the surface cache. r=tnikkel
There is one main difference between raster images and vector images
with respect to factor of 2 scaling. Vector images may be scaled
infinitely and so we need to extend factor of 2 scaling to permit
growing instead of just shrinking. Also, we don't want to scale
infinitely, so we should configure a maximum size limit. This size limit
will apply even outside of factor of 2 scaling, and so the caller
(VectorImage) will need to be careful to take this into account.
f209a9d848f42a377c15bf6a0b0d0255a4ebd580: Bug 1456558 - Part 1. Move the allowed raster size calculation from imgFrame to SurfaceCache. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Thu, 20 Sep 2018 18:15:29 -0400 - rev 485868
Push
241 by fmarier@mozilla.com at Mon, 24 Sep 2018 21:48:02 +0000
Bug 1456558 - Part 1. Move the allowed raster size calculation from imgFrame to SurfaceCache. r=tnikkel
7c53523cea457a878e81772cde22a3adde0f9d45: Bug 1337111 - Part 6. Use shared surfaces for full animated frames for WebRender. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Mon, 17 Sep 2018 15:06:29 -0400 - rev 485138
Push
241 by fmarier@mozilla.com at Mon, 24 Sep 2018 21:48:02 +0000
Bug 1337111 - Part 6. Use shared surfaces for full animated frames for WebRender. r=tnikkel
f8687fe42df8b59eadd9aca296433161b37d9f43: Bug 1337111 - Part 5. Add pref to force decoding of full frames, disabled by default. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Mon, 17 Sep 2018 15:06:29 -0400 - rev 485137
Push
241 by fmarier@mozilla.com at Mon, 24 Sep 2018 21:48:02 +0000
Bug 1337111 - Part 5. Add pref to force decoding of full frames, disabled by default. r=tnikkel
8cd5c4f23ee8ca0ae719c53ee9b7e9229a2de38d: Bug 1337111 - Part 4. Add gtests for BlendAnimationFilter. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Mon, 17 Sep 2018 15:06:29 -0400 - rev 485136
Push
241 by fmarier@mozilla.com at Mon, 24 Sep 2018 21:48:02 +0000
Bug 1337111 - Part 4. Add gtests for BlendAnimationFilter. r=tnikkel
a826a94ae5dd12bfb01edde50dc9a37e4c1e6e3b: Bug 1337111 - Part 3. Land groundwork for new blended animation gtests. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Mon, 17 Sep 2018 15:06:29 -0400 - rev 485135
Push
241 by fmarier@mozilla.com at Mon, 24 Sep 2018 21:48:02 +0000
Bug 1337111 - Part 3. Land groundwork for new blended animation gtests. r=tnikkel
e72e07baca921e697a6d79aa8488e2a0aecb1364: Bug 1337111 - Part 2. Add an image decoder flag to request complete frames. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Mon, 17 Sep 2018 15:06:28 -0400 - rev 485134
Push
241 by fmarier@mozilla.com at Mon, 24 Sep 2018 21:48:02 +0000
Bug 1337111 - Part 2. Add an image decoder flag to request complete frames. r=tnikkel
DecoderFlags::BLEND_ANIMATION will cause the decoder to inject the
BlendAnimationFilter from the previous patch into the SurfacePipe filter
chain. All frames produced by this decoder will be complete, and
should be equivalent to the result outputted by FrameAnimator.
81865752a2f77ef0bdc3e79d05df71335a5430b7: Bug 1337111 - Part 1. Add BlendAnimationFilter to allow decoders to generate complete frames. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Mon, 17 Sep 2018 15:06:28 -0400 - rev 485133
Push
241 by fmarier@mozilla.com at Mon, 24 Sep 2018 21:48:02 +0000
Bug 1337111 - Part 1. Add BlendAnimationFilter to allow decoders to generate complete frames. r=tnikkel
This new SurfaceFilter can be added to a SurfacePipe to perform the
blending of a previous frame with the current partial frame, for an
animated image. This functionality is currently provided by
FrameAnimator and must be performed each time we want to advance the
displayed frame, all on the main thread. Moving this to SurfacePipe
allows us to do the same operation once per frame decode, and on a
decoder thread.
This should reduce the cost of a refresh tick since advancing animated
images is reduced to merely checking if the frame is available. Also, if
the image is below the discard frames threshold (to save memory), then
we will also save CPU due to only blending once at decode.
ca0caa556dc9c92c57f86ea998aae7a3634bf0fd: Bug 1337111 - Part 6. Use shared surfaces for full animated frames for WebRender. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Mon, 17 Sep 2018 13:21:38 -0400 - rev 485122
Push
241 by fmarier@mozilla.com at Mon, 24 Sep 2018 21:48:02 +0000
Bug 1337111 - Part 6. Use shared surfaces for full animated frames for WebRender. r=tnikkel
d7d7fa868d0dbc09f294ec9e0cb08566dc43828a: Bug 1337111 - Part 5. Add pref to force decoding of full frames, disabled by default. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Mon, 17 Sep 2018 13:21:38 -0400 - rev 485121
Push
241 by fmarier@mozilla.com at Mon, 24 Sep 2018 21:48:02 +0000
Bug 1337111 - Part 5. Add pref to force decoding of full frames, disabled by default. r=tnikkel
93e956e89a2119553a19c04c2147fbddf5f7253a: Bug 1337111 - Part 4. Add gtests for BlendAnimationFilter. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Mon, 17 Sep 2018 13:21:38 -0400 - rev 485120
Push
241 by fmarier@mozilla.com at Mon, 24 Sep 2018 21:48:02 +0000
Bug 1337111 - Part 4. Add gtests for BlendAnimationFilter. r=tnikkel
f36337c1309b1de5f7205deb5ea42f2a97690314: Bug 1337111 - Part 3. Land groundwork for new blended animation gtests. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Mon, 17 Sep 2018 13:21:38 -0400 - rev 485119
Push
241 by fmarier@mozilla.com at Mon, 24 Sep 2018 21:48:02 +0000
Bug 1337111 - Part 3. Land groundwork for new blended animation gtests. r=tnikkel
1b1e25b0b345cf3774ae7d186dc082430420e056: Bug 1337111 - Part 2. Add an image decoder flag to request complete frames. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Mon, 17 Sep 2018 13:21:38 -0400 - rev 485118
Push
241 by fmarier@mozilla.com at Mon, 24 Sep 2018 21:48:02 +0000
Bug 1337111 - Part 2. Add an image decoder flag to request complete frames. r=tnikkel
DecoderFlags::BLEND_ANIMATION will cause the decoder to inject the
BlendAnimationFilter from the previous patch into the SurfacePipe filter
chain. All frames produced by this decoder will be complete, and
should be equivalent to the result outputted by FrameAnimator.
3785cdebe6a3ff30cdbd5291559ac7bb3d15c4d0: Bug 1337111 - Part 1. Add BlendAnimationFilter to allow decoders to generate complete frames. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Mon, 17 Sep 2018 13:21:37 -0400 - rev 485117
Push
241 by fmarier@mozilla.com at Mon, 24 Sep 2018 21:48:02 +0000
Bug 1337111 - Part 1. Add BlendAnimationFilter to allow decoders to generate complete frames. r=tnikkel
This new SurfaceFilter can be added to a SurfacePipe to perform the
blending of a previous frame with the current partial frame, for an
animated image. This functionality is currently provided by
FrameAnimator and must be performed each time we want to advance the
displayed frame, all on the main thread. Moving this to SurfacePipe
allows us to do the same operation once per frame decode, and on a
decoder thread.
This should reduce the cost of a refresh tick since advancing animated
images is reduced to merely checking if the frame is available. Also, if
the image is below the discard frames threshold (to save memory), then
we will also save CPU due to only blending once at decode.
86b053d526320d97f3457c7796c3e4143f568b66: Bug 1446309 - Part 3. Properly handle ImgDrawResult for WebRender display list generation. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Thu, 13 Sep 2018 19:48:27 -0400 - rev 484577
Push
241 by fmarier@mozilla.com at Mon, 24 Sep 2018 21:48:02 +0000
Bug 1446309 - Part 3. Properly handle ImgDrawResult for WebRender display list generation. r=tnikkel
When generating display lists for WebRender, we were not caching the
draw result via nsDisplayItemGenericImageGeometry::UpdateDrawResult (or
similar) after completing CreateWebRenderCommands. This is important
because reftests use this to force sync decoding for images; it may be a
reason for image-related intermittent failures on *-qr builds.
Additionally, we may have been requesting fallback in cases where fallback
could not do anything more than WebRender could. For example, if we can't
get an image container yet, there is no point in requesting fallback
because it might just be we haven't started decoding yet. We should just
return the actual draw result in such cases.
2ca405997ed545fb13d1a9618f15a1192345e828: Bug 1446309 - Part 2. Make nsDisplayImage fallback to the previous image to avoid flickering. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Thu, 13 Sep 2018 19:48:24 -0400 - rev 484576
Push
241 by fmarier@mozilla.com at Mon, 24 Sep 2018 21:48:02 +0000
Bug 1446309 - Part 2. Make nsDisplayImage fallback to the previous image to avoid flickering. r=tnikkel
When the current image for an nsImageFrame/nsDisplayImage is not yet
ready, we display the previous image, if any available, to avoid
flickering while we wait for decoding to finish. On the WebRender path,
this functionality was lost since we did not have the draw result
information with image containers. With the API updated in part 1, we
can now do this to avoid flickering.
d10ab3f7b4eafdd78d9e266953b8269a088ed7f0: Bug 1446309 - Part 1. Return draw result from imgIContainer::GetImageContainerAtSize. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Thu, 13 Sep 2018 19:48:21 -0400 - rev 484575
Push
241 by fmarier@mozilla.com at Mon, 24 Sep 2018 21:48:02 +0000
Bug 1446309 - Part 1. Return draw result from imgIContainer::GetImageContainerAtSize. r=tnikkel
In addition to the image container, the draw result can also be useful
for callers to know whether or not the surface(s) in the container are
fully decoded or not. This is used in subsequent parts to avoid
flickering in some cases.
a2d89aea7cce9483b9a249ea34aae4ea53f85c3e: Bug 1486662 - Allow scroll without scrollbar for non-textcontrol elements on Android. r=tnikkel
Xidorn Quan <me@upsuper.org> - Fri, 07 Sep 2018 00:35:45 +0000 - rev 483487
Push
239 by fmarier@mozilla.com at Mon, 10 Sep 2018 17:01:34 +0000
Bug 1486662 - Allow scroll without scrollbar for non-textcontrol elements on Android. r=tnikkel
Differential Revision:
https://phabricator.services.mozilla.com/D5115
6fefaf842b05bea156591d27cbd64095617dbf27: Bug 1445570 - Remove EnsureEventualAfterPaint timer. r=tnikkel
Mantaroh Yoshinaga <mantaroh@gmail.com> - Thu, 06 Sep 2018 02:21:39 +0000 - rev 483363
Push
239 by fmarier@mozilla.com at Mon, 10 Sep 2018 17:01:34 +0000
Bug 1445570 - Remove EnsureEventualAfterPaint timer. r=tnikkel
MozReview-Commit-ID: C7WICJ5Q0ES
Differential Revision:
https://phabricator.services.mozilla.com/D5005
851b26405a346d8aff55d96bc26ed9bb12995701: Bug 1471583. Add a new ImgDrawResult variant to distinguish INCOMPLETE and 'fully drew an image which wasn't really complete'. r=tnikkel
Emilio Cobos Álvarez <emilio@crisal.io> - Wed, 29 Aug 2018 00:53:08 -0500 - rev 482018
Push
232 by fmarier@mozilla.com at Wed, 05 Sep 2018 20:45:54 +0000
Bug 1471583. Add a new ImgDrawResult variant to distinguish INCOMPLETE and 'fully drew an image which wasn't really complete'. r=tnikkel
45e3f5d8e29402e8fda2fea772dc5d08d8866fd7: Bug 1446309 - Part 2. Make nsDisplayImage fallback to the previous image to avoid flickering. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Tue, 14 Aug 2018 11:35:40 -0400 - rev 479699
Push
222 by fmarier@mozilla.com at Thu, 16 Aug 2018 00:03:56 +0000
Bug 1446309 - Part 2. Make nsDisplayImage fallback to the previous image to avoid flickering. r=tnikkel
When the current image for an nsImageFrame/nsDisplayImage is not yet
ready, we display the previous image, if any available, to avoid
flickering while we wait for decoding to finish. On the WebRender path,
this functionality was lost since we did not have the draw result
information with image containers. With the API updated in part 1, we
can now do this to avoid flickering.
69a4c2a0aac6e8bfc041a82b634611e1432af36b: Bug 1446309 - Part 1. Return draw result from imgIContainer::GetImageContainerAtSize. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Tue, 14 Aug 2018 11:35:40 -0400 - rev 479698
Push
222 by fmarier@mozilla.com at Thu, 16 Aug 2018 00:03:56 +0000
Bug 1446309 - Part 1. Return draw result from imgIContainer::GetImageContainerAtSize. r=tnikkel
In addition to the image container, the draw result can also be useful
for callers to know whether or not the surface(s) in the container are
fully decoded or not. This is used in subsequent parts to avoid
flickering in some cases.
bc7ac43b0e134768d877b6bd46a127692846b63d: Bug 1416328 - Part 3. Enable img decoding attribute web-platform-tests. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Wed, 08 Aug 2018 07:56:01 -0400 - rev 478825
Push
215 by fmarier@mozilla.com at Fri, 10 Aug 2018 00:07:31 +0000
Bug 1416328 - Part 3. Enable img decoding attribute web-platform-tests. r=tnikkel
630049a9ac3b24ec0a141669937df372373a5d6f: Bug 1416328 - Part 2. Expose decoding attribute for img elements. r=bz,tnikkel
Andrew Osmond <aosmond@mozilla.com> - Wed, 08 Aug 2018 07:56:01 -0400 - rev 478824
Push
215 by fmarier@mozilla.com at Fri, 10 Aug 2018 00:07:31 +0000
Bug 1416328 - Part 2. Expose decoding attribute for img elements. r=bz,tnikkel
This adds support for HTMLImageElement's decoding attribute, as
described by:
https://github.com/whatwg/html/pull/3221
https://whatpr.org/html/3221/images.html#decoding-images
It also exposes the same attribute on SVGImageElement, just as Blink has
chosen to do so.
1f426c672aabc1b58a4aceeaca499309afd9b66f: Bug 1416328 - Part 1. Add configurable synchronous decoding hint to nsImageLoadingContent. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Wed, 08 Aug 2018 07:56:01 -0400 - rev 478823
Push
215 by fmarier@mozilla.com at Fri, 10 Aug 2018 00:07:31 +0000
Bug 1416328 - Part 1. Add configurable synchronous decoding hint to nsImageLoadingContent. r=tnikkel
The next part in this series depends on this to implement the
HTMLImageElement's decoding attribute. This functionality allows the
caller to force an nsImageLoadingContent and its associated nsImageFrame
and nsSVGImageFrame objects to synchronously decode an image at draw
time. It will only synchronously decode if it has completed metadata
decoding (i.e. knows its size) and has received all of the encoded data;
this mirrors the load event criteria for an image.