d2f1265ca977cab4b65a81aff3902ee7f02d5a06: Bug 1500717 - Parallelize the toolbox loading the inspector's iframe and initializing the inspector. r=pbro
Gabriel Luong <gabriel.luong@gmail.com> - Mon, 22 Oct 2018 12:20:58 -0400 - rev 490718
Push 247 by fmarier@mozilla.com at Sat, 27 Oct 2018 01:06:44 +0000
Bug 1500717 - Parallelize the toolbox loading the inspector's iframe and initializing the inspector. r=pbro
f0f7573deea111d97bc96aa6b33e2518ee89da3a: Bug 1500709 - fix big-endian RGBBitShift in Swizzle. r=me
Lee Salzman <lsalzman@mozilla.com> - Mon, 22 Oct 2018 14:49:08 -0400 - rev 490717
Push 247 by fmarier@mozilla.com at Sat, 27 Oct 2018 01:06:44 +0000
Bug 1500709 - fix big-endian RGBBitShift in Swizzle. r=me CLOSED TREE
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
8c1121739072bf560b00acd482745de2c952b33a: merge mozilla-central to mozilla-inbound
Sebastian Hengst <archaeopteryx@coole-files.de> - Mon, 22 Oct 2018 20:37:38 +0300 - rev 490702
Push 247 by fmarier@mozilla.com at Sat, 27 Oct 2018 01:06:44 +0000
merge mozilla-central to mozilla-inbound
2872e7a3606d6108874930a1eb4062c74bad0e9e: merge mozilla-inbound to mozilla-central. a=merge
Sebastian Hengst <archaeopteryx@coole-files.de> - Mon, 22 Oct 2018 20:26:16 +0300 - rev 490701
Push 247 by fmarier@mozilla.com at Sat, 27 Oct 2018 01:06:44 +0000
merge mozilla-inbound to mozilla-central. a=merge
2bb5c6697edc7545fb94828defb65173fca2ade5: Bug 1500689 - Only update the frame button checked state if it is visible. r=mtigley
Gabriel Luong <gabriel.luong@gmail.com> - Mon, 22 Oct 2018 13:29:04 -0400 - rev 490700
Push 247 by fmarier@mozilla.com at Sat, 27 Oct 2018 01:06:44 +0000
Bug 1500689 - Only update the frame button checked state if it is visible. r=mtigley
af3fd0a2c2e61c263a1d252824dfdeb18162cf14: merge autoland to mozilla-central. a=merge
Sebastian Hengst <archaeopteryx@coole-files.de> - Mon, 22 Oct 2018 20:24:54 +0300 - rev 490699
Push 247 by fmarier@mozilla.com at Sat, 27 Oct 2018 01:06:44 +0000
merge autoland to mozilla-central. a=merge
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 tip