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 501597
Push 1905 by ffxbld-merge at Mon, 21 Jan 2019 12:33:13 +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 501596
Push 1905 by ffxbld-merge at Mon, 21 Jan 2019 12:33:13 +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 501595
Push 1905 by ffxbld-merge at Mon, 21 Jan 2019 12:33:13 +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 501594
Push 1905 by ffxbld-merge at Mon, 21 Jan 2019 12:33:13 +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 501593
Push 1905 by ffxbld-merge at Mon, 21 Jan 2019 12:33:13 +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 501592
Push 1905 by ffxbld-merge at Mon, 21 Jan 2019 12:33:13 +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 501591
Push 1905 by ffxbld-merge at Mon, 21 Jan 2019 12:33:13 +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 501590
Push 1905 by ffxbld-merge at Mon, 21 Jan 2019 12:33:13 +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 501589
Push 1905 by ffxbld-merge at Mon, 21 Jan 2019 12:33:13 +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 501588
Push 1905 by ffxbld-merge at Mon, 21 Jan 2019 12:33:13 +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 501587
Push 1905 by ffxbld-merge at Mon, 21 Jan 2019 12:33:13 +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 501586
Push 1905 by ffxbld-merge at Mon, 21 Jan 2019 12:33:13 +0000
merge mozilla-central to mozilla-inbound
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 501585
Push 1905 by ffxbld-merge at Mon, 21 Jan 2019 12:33:13 +0000
Bug 1500689 - Only update the frame button checked state if it is visible. r=mtigley
97b682ea485d8f5d2f483051dcc53c59883344d1: Backed out 2 changesets (bug 1500717, bug 1500701) for browser-chrome failures at browser/test-oop-extensions/browser_ext_devtools_inspectedWindow.js on a CLOSED TREE
Coroiu Cristina <ccoroiu@mozilla.com> - Mon, 22 Oct 2018 20:19:52 +0300 - rev 501584
Push 1905 by ffxbld-merge at Mon, 21 Jan 2019 12:33:13 +0000
Backed out 2 changesets (bug 1500717, bug 1500701) for browser-chrome failures at browser/test-oop-extensions/browser_ext_devtools_inspectedWindow.js on a CLOSED TREE Backed out changeset 4fbd733460be (bug 1500701) Backed out changeset 6cd064e0fbd9 (bug 1500717)
214a7b40bd26f08c24e70183fe1acc2656f26ef9: Bug 1500978 - Some follow-up changes/tests for bug 1493900. r=sunfish
Jan de Mooij <jdemooij@mozilla.com> - Mon, 22 Oct 2018 18:16:54 +0200 - rev 501583
Push 1905 by ffxbld-merge at Mon, 21 Jan 2019 12:33:13 +0000
Bug 1500978 - Some follow-up changes/tests for bug 1493900. r=sunfish
15811bce212a0bbe0603ff31f3f95934050afe95: Bug 1419091: Delete platformHTMLBindings.xml. r=masayuki
Dave Townsend <dtownsend@oxymoronical.com> - Mon, 08 Oct 2018 11:10:25 -0700 - rev 501582
Push 1905 by ffxbld-merge at Mon, 21 Jan 2019 12:33:13 +0000
Bug 1419091: Delete platformHTMLBindings.xml. r=masayuki Removes the now unused platformHTMLBindings.xml. Differential Revision: https://phabricator.services.mozilla.com/D8932
2224ee809328bf70ded5648d0a2896d507def220: Bug 1419091: Make TextInputListener handle non-native events for input and textarea too. r=masayuki
Dave Townsend <dtownsend@oxymoronical.com> - Mon, 15 Oct 2018 12:19:30 -0700 - rev 501581
Push 1905 by ffxbld-merge at Mon, 21 Jan 2019 12:33:13 +0000
Bug 1419091: Make TextInputListener handle non-native events for input and textarea too. r=masayuki platformHTMLBindings attaches event handlers directly to the <input> and <textarea> elements. This matches that by making TextInputListener look up and call the <input> and <textarea> event handlers from the static C array. There is a slight difference in that the event handlers are added to the system bubbling phase as opposed to the regular bubbling phase but in tests this does not seem to cause problems. Differential Revision: https://phabricator.services.mozilla.com/D8931
ac56492b6ed6f03cd61389db83a73e0fdf970089: Bug 1419091: Switch to a compiled C++ table for html key bindings for browser and editor. r=masayuki
Dave Townsend <dtownsend@oxymoronical.com> - Mon, 08 Oct 2018 11:09:31 -0700 - rev 501580
Push 1905 by ffxbld-merge at Mon, 21 Jan 2019 12:33:13 +0000
Bug 1419091: Switch to a compiled C++ table for html key bindings for browser and editor. r=masayuki Rather than loading an XBL binding for <browser> and <editor> elements this generates the handlers from static C arrays. Differential Revision: https://phabricator.services.mozilla.com/D6181
72ccc94449163738199ec04886f2f5513bce5122: Bug 1419091: Define keybindings in a static C++ table. r=masayuki
Dave Townsend <dtownsend@oxymoronical.com> - Mon, 08 Oct 2018 11:08:52 -0700 - rev 501579
Push 1905 by ffxbld-merge at Mon, 21 Jan 2019 12:33:13 +0000
Bug 1419091: Define keybindings in a static C++ table. r=masayuki Copies the keybindings from platformHTMLBindings.xml into an array of C structs that can be easily used to instantiate an nsXBLPrototypeHandler (done in later patches). These were mechanically generated. Differential Revision: https://phabricator.services.mozilla.com/D8930
58d5a882493d491780115ebfe6c561866fc07dda: Bug 1419091: Add keybinding tests. r=masayuki
Dave Townsend <dtownsend@oxymoronical.com> - Mon, 08 Oct 2018 11:07:00 -0700 - rev 501578
Push 1905 by ffxbld-merge at Mon, 21 Jan 2019 12:33:13 +0000
Bug 1419091: Add keybinding tests. r=masayuki Differential Revision: https://phabricator.services.mozilla.com/D3030
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 tip