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.