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
6c8bbe5f25a750a29707105cc1d57871af9e1fae: Bug 1500735 - Update cached-iterable in Fluent to 0.3.0. r=stas
Zibi Braniecki <zbraniecki@mozilla.com> - Mon, 22 Oct 2018 15:05:35 +0000 - rev 490698
Push 247 by fmarier@mozilla.com at Sat, 27 Oct 2018 01:06:44 +0000
Bug 1500735 - Update cached-iterable in Fluent to 0.3.0. r=stas Differential Revision: https://phabricator.services.mozilla.com/D9350
23f77dfb5679f3cd4e34250c9511c8a49041a956: Bug 1493560 - Change test to allow another possibility. r=arai
Jason Orendorff <jorendorff@mozilla.com> - Mon, 22 Oct 2018 15:03:20 +0000 - rev 490697
Push 247 by fmarier@mozilla.com at Sat, 27 Oct 2018 01:06:44 +0000
Bug 1493560 - Change test to allow another possibility. r=arai This also changes the test to print something informative on failure. Differential Revision: https://phabricator.services.mozilla.com/D9046
4bdddb2c5100121222fef51a89da476fed899b42: Bug 1494473 - Using IONFLAGS=bl-ic-stats dump baseline IC statistics on script cleanup r=jandem
Matthew Gaudet <mgaudet@mozilla.com> - Fri, 19 Oct 2018 15:33:27 +0000 - rev 490696
Push 247 by fmarier@mozilla.com at Sat, 27 Oct 2018 01:06:44 +0000
Bug 1494473 - Using IONFLAGS=bl-ic-stats dump baseline IC statistics on script cleanup r=jandem The output for a particular IC chain looks like this: box2d.js:174:250 (sub) 1009 -> 772 -> (fb) 2 Which is read like this: This sub opcode has two ICs attached. The first IC was entered 1009 times, the second 772 and the fallback stub was hit twice. There are some conclusions we can draw from this (and some we cannot) - We can say with confidence the fallback stub was only hit twice, meaning 99.998% of queries to the IC chain hit in the IC rather than the fallback. - We cannot however say necessarily that the first IC failed to provide a value 771 times. Since new ICs are added at the front, it is possible that there was a phase transition that happened, and the first 771 requests were served by the first IC, followed by a transition to a new type and addition of a new IC, and subsequently 1009 queries were served by the newly added IC. - We can conclude with confidence that there have been at least two different ICs involved in computation across the lifetime of the IC chain, and they are almost equally probable. Though we can't do temporal reasoning with entry counters, we can still do some reasoning. Depends on D8859 Differential Revision: https://phabricator.services.mozilla.com/D8860
2ac1bca7094c959bf382ee37779566056f8792a7: Bug 1494473 - Add entered counters to Baseline's CacheIR_Regular and Fallback stubs r=jandem
Matthew Gaudet <mgaudet@mozilla.com> - Thu, 18 Oct 2018 15:56:53 +0000 - rev 490695
Push 247 by fmarier@mozilla.com at Sat, 27 Oct 2018 01:06:44 +0000
Bug 1494473 - Add entered counters to Baseline's CacheIR_Regular and Fallback stubs r=jandem By adding a counter increment to the entry of an IC stub, it is possible to analyze the IC chain for patterns that indicate how the ICs are performing, which can influence the baseline inspector, and allow Ion to weight the choices it makes on IC data. Differential Revision: https://phabricator.services.mozilla.com/D8859
d1e4e5029ffb1e38b6328b8c9d422edfb4603107: Bug 1497476 - Remove nsITransferable.kFlavorHasDataProvider. r=NeilDeakin
Tom Schuster <evilpies@gmail.com> - Tue, 16 Oct 2018 20:35:10 +0000 - rev 490694
Push 247 by fmarier@mozilla.com at Sat, 27 Oct 2018 01:06:44 +0000
Bug 1497476 - Remove nsITransferable.kFlavorHasDataProvider. r=NeilDeakin Depends on D8074 Differential Revision: https://phabricator.services.mozilla.com/D8075
2e5b99d12a6daf88e4fffa8f80efb7b874f18379: Bug 1500206 - In macOS clipboard code fallback to native clipboard for images . r=robwu,mixedpuppy
Tom Schuster <evilpies@gmail.com> - Mon, 22 Oct 2018 14:39:09 +0000 - rev 490693
Push 247 by fmarier@mozilla.com at Sat, 27 Oct 2018 01:06:44 +0000
Bug 1500206 - In macOS clipboard code fallback to native clipboard for images . r=robwu,mixedpuppy Differential Revision: https://phabricator.services.mozilla.com/D9132
76763ce5587582f94bcdebd9efb3ce6f625085ea: Bug 1499384: add debug logging for expandedprincipals r=ckerschb
Frederik Braun <fbraun@mozilla.com> - Mon, 22 Oct 2018 12:49:10 +0000 - rev 490692
Push 247 by fmarier@mozilla.com at Sat, 27 Oct 2018 01:06:44 +0000
Bug 1499384: add debug logging for expandedprincipals r=ckerschb Extending the MOZ_LOGging for content security checks to provide a proper serialization of expanded principals Differential Revision: https://phabricator.services.mozilla.com/D8958
e7d0ae555a8d4cf6068f84648253fafffe9bf498: Backed out changeset e9ce17673999 (bug 1499661) for missing bugzilla component for PHABTEST. CLOSED TREE
Csoregi Natalia <ncsoregi@mozilla.com> - Mon, 22 Oct 2018 17:25:49 +0300 - rev 490691
Push 247 by fmarier@mozilla.com at Sat, 27 Oct 2018 01:06:44 +0000
Backed out changeset e9ce17673999 (bug 1499661) for missing bugzilla component for PHABTEST. CLOSED TREE
9a6f5e359f1d3a281253b5cfa18f4f7502dd4d5e: Bug 1500475 - Fix browser_jsterm_content_defined_helpers.js intermittent; r=Honza.
Nicolas Chevobbe <nchevobbe@mozilla.com> - Mon, 22 Oct 2018 14:23:55 +0000 - rev 490690
Push 247 by fmarier@mozilla.com at Sat, 27 Oct 2018 01:06:44 +0000
Bug 1500475 - Fix browser_jsterm_content_defined_helpers.js intermittent; r=Honza. Differential Revision: https://phabricator.services.mozilla.com/D9360
ffbc071b41bd30784c817593b200f9020c51c421: Bug 1498896 - Apply documentUrlPatterns to original target document when viewTypes is set r=mixedpuppy
Rob Wu <rob@robwu.nl> - Mon, 22 Oct 2018 14:17:29 +0000 - rev 490689
Push 247 by fmarier@mozilla.com at Sat, 27 Oct 2018 01:06:44 +0000
Bug 1498896 - Apply documentUrlPatterns to original target document when viewTypes is set r=mixedpuppy Usually, documentUrlPatterns applies to the URL of the document where the context menu is opened. In some cases, there is no document, such as menus on browser UI (extension action buttons, tools menu, tabs). In these cases, `documentUrlPatterns` matches the (active) tab's URL. This causes ambiguity when `browser.menus.overrideContext` is used to change the context to the "tab" context. Before this patch, `documentUrlPatterns` applied to the tab's URL. After this patch, `documentUrlPatterns` applies to the URL of the document where the menu was opened, *if* `viewTypes` is also set. Using this property is a strong signal from the extension that the menu is meant to be shown in a document rather than browser UI, so extensions can reasonably expect `documentUrlPatterns` to match the original document's URL instead of the URL of the spoofed tab context. There was no existing test coverage for documentUrlPatterns on tab contexts, so this does not only add tests for documentUrlPatterns on overridden contexts (browser_ext_menus_replace_menu_context.js), but also documentUrlPatterns in normal tab contexts (browser_ext_menus.js). Differential Revision: https://phabricator.services.mozilla.com/D9249
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 tip