Intent to unship: HTTP Refresh header support when the content is handled as a download

[Matt Woodrow]

Hi,

In Bug 1589270 I 
intend to remove support for handling the HTTP Refresh header while 
handling the content as a download.


This has been broken in our code with e10s enabled, since the initial 
e10s conversion.


Neither Chrome nor Safari support this, and the only specified handling 
of the Refresh header is part of initializing the document object [1], 
which isn't run for downloads.


- Matt

[1] 
https://html.spec.whatwg.org/multipage/browsing-the-web.html#initialise-the-document-object



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: What to do about scroll anchoring?

[Matt Woodrow]

On 29/09/19 1:54 PM, Cameron McCormack wrote:

How useful is scroll anchoring outside of the two cases mentioned in 
https://drafts.csswg.org/css-scroll-anchoring/#intro i.e. images loading and ad 
iframes being inserted?  Would it be feasible to make scroll anchoring a much 
less general mechanism, and to scope it down to handling these specific cases?


The virtual-scroller[1]/rendersubtree[2] demo that the Chromium team 
demoed at TPAC was also relying on scroll anchoring.


When you use the scrollbar to jump to a given spot, the custom scroller 
element then makes surrounding elements visible. Making them visible 
changes them from using their content-size [3] placeholder size to the 
real size, and we don't want the viewport to move in the process.


- Matt


[1] https://github.com/WICG/virtual-scroller

[2] https://github.com/whatwg/html/pull/4862

[3] https://github.com/w3c/csswg-drafts/issues/4229
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Dogfooding WebRender

[Matt Woodrow]

Hi All,

WebRender is now enabled for most Nightly users on Windows 10 with an 
NVIDIA desktop GPU. If you're already using it (check about:support!) or 
want to (set gfx.webrender.all=true), we'd love to have your feedback.


We're particularly interested in finding testcases where it doesn't 
perform well. If you set 'gfx.webrender.debug.slow-frame-indicator' to 
true, then you'll get a small red rectangle in the top left corner that 
moves whenever WebRender is slow to present a frame.


If anyone finds a page where this happens consistently, please file a 
bug in Core :: Graphics : WebRender, and we'll take a look. Please 
attach about:support as this contains extra details on the slow frames 
(feel free to censor listed URLs as needed) as well as your graphics 
card information.


Note that we're currently targeting Windows 10 users with NVIDIA desktop 
GPUs, so we'll be prioritizing bugs on that configuration.


Thanks!

 - Matt
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Retained Display Lists

[matt . woodrow]

On Thursday, October 26, 2017 at 5:13:15 PM UTC+13, mwoo...@mozilla.com wrote:
> On Monday, October 9, 2017 at 1:22:55 PM UTC+13, Matt Woodrow wrote:
> 
> > 
> > We're planning on landing the code for retaining display lists in 58, 
> > behind the pref layout.display.list.retain.
> > 
> 
> This has now landed in Nightly, and looks to be working really well.
> 
> We'd really appreciate some early feedback, so feel free to set 
> layout.display-list.retain=true and give it a try!
> 
> Please file bugs blocking 1352499 if you find any issues.
> 
> Thanks!
> 
>  - Matt

And now it's enabled by default for mozilla-central, and should go out in 
tonight's Nightly.

As above, please file bugs blocking 1352499 if you find any issues.

Thanks!

- Matt
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: Retained Display Lists

[Matt Woodrow]

Hello all,


We're planning on landing the code for retaining display lists in 58, 
behind the pref layout.display.list.retain.



This is a rather large reworking of how we paint, and was designed to 
address telemetry results [1] showing that display list building was 
consuming considerable amounts of our total paint time (around 40% on 
average). The new code retains the display list, and attempts to merge 
in partial updates rather than rebuilding the list from scratch each 
paint (as we currently do). We're tracking this in bug 1352499, which 
includes a link to all the planning and telemetry details.



Miko Mynttinen has been working on gathering some performance data [2], 
which is showing some really big wins, including a 77% reduction in 
display list building time on YouTube when we manage to do a partial 
update. These are just preliminary results, and we have a lot of 
remaining plans to build off this architecture and get further wins. We 
also have a few talos regressions due to the increased bookkeeping 
required for this, though we're working on minimizing these as much as 
possible. This is due to most Talos tests measuring first paint 
performance, and this change optimizes the second (and later) paints, 
which we believe to be more useful for perceived performance.



We're planning to land into mozilla-central in the next week or two, and 
then enable it by default for Nightly within a week or two of that. I'll 
send a follow-up email once we do land so that anyone interested can 
flip the pref and give us early feedback. Our current plan is to ride 
the trains for 58, possibly with a partial rollout for beta, and we'll 
make a decision on that closer to the merge date.



We do have significant testing for this via reftests, though it has been 
identified that we have a relative lack of testing for dynamic changes. 
Jonathan Watt is working on a fuzzer addition to the reftest harness 
that will generate random mutations which will increase our confidence 
in correctness and stability here.




Thanks to everyone who has helped work on this, including: Miko 
Mynttinen, Timothy Nikkel, Markus Stange, Ethan Lin and Jonathan Watt.




- Matt



[1] 
https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0_date=2017-10-05=r!dl%252Cflb!dl!flb_channel_version=beta%252F57=CONTENT_LARGE_PAINT_PHASE_WEIGHT_channel_version=null=Windows_NT=*=Firefox=1_keys=submissions_date=2017-09-25=0=1_submission_date=0 



[2]http://miko.lol/shared/mozilla/retained-dl-measurements-2017-10-05.pdf

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: force flattening of transform-style:preserve-3d when opacity is applied

[Matt Woodrow]

Summary:

The editors draft of the 3d transforms spec [1] has been updated to say 
that we need to flatten preserve-3d when the element also has an opacity 
of < 1, whereas the previous spec [2] made no mention of opacity.


The current behaviour (in Gecko, WebKit and blink) is to drop the 
'group' nature of opacity, and propagate the opacity effect down on to 
the leaves of the preserve-3d tree. This is non-intuitive, not specified 
at all, and has slightly differently rendering in all browsers (based on 
the specifics of what compositable layers get created I believe - see 
layout/reftests/opacity-preserve3d-N.html reftests).


The blink team intend to change their behaviour to match the new spec, 
even though it might break webcompat in some cases. The initial 
www-style discussion [3] and their intent to implement thread [4] covers 
their motivations for wanting to do this.


Given that the existing behaviour appears to be used incredibly rarely 
[5] and that it moves us to well specified behaviour that is easy to 
conform to, then I think we should do the same.



Bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=1283827


Link to standard:

Editors draft: 
https://drafts.csswg.org/css-transforms/#grouping-property-values 



Current spec: https://www.w3.org/TR/css-transforms-1/ 
 







Platform coverage:

All platforms

Estimated or target release:

Firefox 52.

Preference behind which this will be implemented:

None.

- Matt

[1] https://drafts.csswg.org/css-transforms/#grouping-property-values 
[2] https://www.w3.org/TR/css-transforms-1/#transform-style-property [3] 
https://lists.w3.org/Archives/Public/www-style/2016May/0239.html [4] 
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/eBIp90_il1o 
 
[5] 
https://www.chromestatus.com/metrics/feature/popularity#OpacityWithPreserve3DQuirk




___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: DOMMatrix

[Matt Woodrow]

On 6/06/14 12:05 am, Benoit Jacob wrote:


The situation isn't symmetric: radians are inherently simpler to implement
(thus slightly faster), basically because only in radians is it true that
sin(x) ~= x for small x.

I also doubt that degrees are simpler to understand, and if anything you
might just want to provide a simple name for the constant 2*pi:

var turn = Math.PI * 2;

Now, what is easier to understand:

rotate(turn / 5)

or

rotate(72)

?




I don't think this is a fair comparison, you used a fraction of a 
constant for one and a raw number for the other.


Which is easier to understand:

var turn = 360;

rotate(turn / 5)

or

rotate(1.25663706143592)

?


I realize that radians make more sense mathematically, but for people 
who haven't studied it I think degrees are the more 'natural' way of 
thinking about angles/rotations. This is reflected in the number of 
authors currently using degrees instead of radians for CSS transforms.


- Matt
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: OMTC on Windows

[Matt Woodrow]

Thanks Avi!

I can reproduce a regression like this (~100% slower on 
iconFade-close-DPIcurrent.all) with my machine forced to use the intel 
GPU, but not with the Nvidia one.


This suggests it's very much a driver/hardware specific problem, rather 
than a general regression with OMTC, which matches Bas' original 
observations.


Doing some profiling using my intel GPU suggests that my specific 
regression has to do with uploading and drawing shadows. I'm seeing ~45% 
of the OMTC profile [1] in nsDisplayBoxShadowOuter::Paint vs ~8% in the 
non-OMTC profile [2]. It's hard to tell exactly where the slowdown is 
because samples within the driver are breaking our unwinding code, but I 
suspect it's probably the upload to the GPU not handling the 
threads/contention well. I suspect a simple box-shadow cache would work 
wonders here.


I don't know how will this will translate to the TBPL results though, 
does anyone know what GPU's and drivers we are running there?


- Matt


On 30/05/14 2:14 pm, avi...@gmail.com wrote:

So, wrt TART, I now took the time to carefully examine tab animation visually 
on one system.

TL;DR:
- I think OMTC introduces a clearly visible regression with tab animation 
compared to without OMTC.
- I _think_ it regresses more with tab close than with tab open animation.
- The actual throughput regression is probably bigger than indicated by TART 
numbers.


The reason for the negative bias is that the TART results are an average of 10 
different animations, but only one of those is close to pure graphics perf 
numbers, and when you look only on this test, the regression is bigger than 
50-100% (more like 100-400%).

The details:

System: Windows 8.1 x64, i7-4500u, using Intel's iGPU (HD4400), and with 
official Firefox nightly 32bit (2014-05-29).

First, visually: both with and without ASAP mode, to my eyes, tab animation 
with OMTC is less smooth, and seems to have lower frame rate than without OMTC.

As for what TART measures, of all the TART subtests, there are 3 which are most 
suitable for testing pure graphics performance - they test the css fade-in and 
fade-out (that's the close/open animation) of a tab without actually opening or 
closing a browser tab, so whatever performance it has, the limit comes only 
from the animation itself and it doesn't include other overheads.

These tests are the ones which have fade in their name, and only one of them 
is enabled by default in talos - the other two are available only when running TART 
locally and then manually selecting animations to run.

I'll focus on a single number which is the average frame interval of the entire animation 
(these are the .all numbers), for the fade animation at default DPI (which is 
1 on my system - so the most common).

What TART measures locally on my system:

OMTC without ASAP mode (as out of the box config as it gets):
iconFade-close-DPIcurrent.allAverage (5): 18.91 stddev: 0.86
iconFade-open-DPIcurrent.all Average (5): 17.61 stddev: 0.78

OMTC with ASAP:
iconFade-close-DPIcurrent.allAverage (5): 18.47 stddev: 0.46
iconFade-open-DPIcurrent.all Average (5): 10.08 stddev: 0.46

While this is an average of only 5 runs, stddev shows it's reasonably 
consistent, and the results are also consistent when I tried more.

We can already tell that close animation just doesn't get below ~18.5ms/frame 
on this system, ASAP doesn't affect it at all. We can also see that the open 
animation is around 60fps without ASAP (17.6 can happen with our inaccurate 
interval timers) and with ASAP it goes down to about 10ms/frame.

Without OMTC and without ASAP:
iconFade-close-DPIcurrent.allAverage (5): 16.54 stddev: 0.16
iconFade-open-DPIcurrent.all Average (5): 16.52 stddev: 0.12

Without OMTC and with ASAP:
iconFade-close-DPIcurrent.allAverage (5): 5.53 stddev: 0.07
iconFade-open-DPIcurrent.all Average (5): 6.37 stddev: 0.08

The results are _much_ more stable (stddev), and quite lower (in ASAP) and closer to 16.7 
in normal mode.

While I obviously can't visually notice differences when the frame rate is 
higher than my screen's 60hz, from what I've seen so far, both visually and at 
the numbers, I think TART is not less reliable than before, it doesn't look to 
me as if ASAP introduces very bad bias (I couldn't deduct any), and OMTC does 
seem regress tab animations meaningfully.

- avih
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: OMTC on Windows

[Matt Woodrow]

On 30/05/14 5:22 pm, Matt Woodrow wrote:


Doing some profiling using my intel GPU suggests that my specific 
regression has to do with uploading and drawing shadows. I'm seeing 
~45% of the OMTC profile [1] in nsDisplayBoxShadowOuter::Paint vs ~8% 
in the non-OMTC profile [2]. It's hard to tell exactly where the 
slowdown is because samples within the driver are breaking our 
unwinding code, but I suspect it's probably the upload to the GPU not 
handling the threads/contention well. I suspect a simple box-shadow 
cache would work wonders here.




Oops,

[1] 
http://people.mozilla.org/~bgirard/cleopatra/#report=87718d90b7d4d4cea6714a2c6de3458151e467b3
[2] 
http://people.mozilla.org/~bgirard/cleopatra/#report=506e206b173801970896fb3a3dc7fb2974755dcd

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Subpixel AA text rendering on OSX

[Matt Woodrow]

Hi,

Currently in gecko we have code to determine if text being drawn into a 
transparent surface has opaque content underneath it. In the case where 
it doesn't we ask moz2d/cairo [1] to disable subpixel AA text rendering 
for this surface since it can have poor results depending on what the 
eventual background color is.


However, this setting was only ever respected for the GDI font rendering 
backend with cairo, and the other backends ignored it (unless they do 
something internally?). Moz2D matched this until recently, until bug 
941095 made the CoreGraphics backend start respecting the value as well.


The two extreme examples of where this might matter are as follows:

- A transparent surface with a very nearly opaque background color (the 
OSX content menus uses rgba(255,255,255,0.95) iirc). In this case it's 
probably ok to use subpixel AA since we're so close to opaque. The OSX 
context menu's used to get subpixel AA text in this case since the value 
was ignored, but no longer do (on nightly) since we respect the value.


- A fully transparent surface containing only text. It should be fairly 
easy to get this to happen by 3d transforming a text element. I 
suspect we don't want subpixel AA here, since we have no idea what the 
final background color might be (and it could change every frame if the 
transform is animated). CG was previously still giving us subpixel AA in 
this case, but won't be any more.


I doubt we want to ship the text quality regression for OSX context 
menus, so we need to find a solution to this. Preferably something that 
is consistent across backends :)


Possible ideas:

- Revert the change to the Moz2D CG backend. This takes us back to 
matching our previous behaviour, but not ideal to have Moz2D API 
functions that are ignored on some backends.


- Keep the change, and instead #ifdef XP_OSX the callers inside gecko. 
This keeps Moz2D cleaner, at the expense of gecko.


- Come up with some definition of 'close enough to opaque to get away 
with subpixel AA' and have gecko compute this instead of looking for 
completely opaque background. I have no idea what that definition would 
be exactly.


- Others?

Does anyone have any suggestions for this, or knowledge about why only 
GDI bothered with this previously?


Thanks!

- Matt


[1] 
http://mxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxASurface.h#136 
or http://mxr.mozilla.org/mozilla-central/source/gfx/2d/2D.h#957

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: partial GL buffer swap

[Matt Woodrow]

We actually have code that does the computation of the dirty area
already, see
http://mxr.mozilla.org/mozilla-central/ident?i=LayerPropertiestree=mozilla-central.

The idea is that we take a snapshot of the layer tree before we update
it, and then do a comparison after we've finished updating it.

We're currently only using this for main-thread BasicLayers, but we're
almost certainly going to need to extend it to work on the compositor
side too for OMTC BasicLayers.

It shouldn't be too much work, we just need to make ThebesLayers shadow
their invalid region, and update some of the LayerProperties comparison
code to understand the **LayerComposite way of doing things.

Once we have that, adding compositor specific implementations of
restricting composition to that area should be easy!

- Matt

On 1/09/13 4:50 AM, Andreas Gal wrote:

 Soon we will be using GL (and its Windows equivalent) on most
 platforms to implement a hardware accelerated compositor. We draw into
 a back buffer and with up to 60hz we perform a buffer swap to display
 the back buffer and make the front buffer the new back buffer (double
 buffering). As a result, we have to recomposite the entire window with
 up to 60hz, even if we are only animating a single pixel.

 On desktop, this is merely bad for battery life. On mobile, this can
 genuinely hit hardware limits and we won't hit 60 fps because we waste
 a lot of time recompositing pixels that don't change, sucking up
 memory bandwidth.

 Most platforms support some way to only update a partial rect of the
 frame buffer (AGL_SWAP_RECT on Mac, eglPostSubBufferNVfor Linux,
 setUpdateRect for Gonk/JB).

 I would like to add a protocol to layers to indicate that the layer
 has changed since the last composition (or not). I propose the
 following API:

 void ClearDamage(); // called by the compositor after the buffer swap
 void NotifyDamage(Rect); // called for every update to the layer, in
 window coordinate space (is that a good choice?)

 I am using Damage here to avoid overloading Invalidate. Bike shedding
 welcome. I would put these directly on Layer. When a color layer
 changes, we damage the whole layer. Thebes layers receive damage as
 the underlying buffer is updated.

 The compositor accumulates damage rects during composition and then
 does a buffer swap of that rect only, if supported by the driver.

 Damage rects could also be used to shrink the scissor rect when
 drawing the layer. I am not sure yet whether its easily doable to take
 advantage of this, but we can try as a follow-up patch.

 Feedback very welcome.

 Thanks,

 Andreas

 PS: Does anyone know how this works on Windows?
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: The current state of Talos benchmarks

[Matt Woodrow]

I've just filed bug 786978 for this.

- Matt

- Original Message -
From: Ehsan Akhgari ehsan.akhg...@gmail.com
To: rob...@ocallahan.org
Cc: dev-platform@lists.mozilla.org
Sent: Thursday, August 30, 2012 1:02:43 PM
Subject: Re: The current state of Talos benchmarks

On 12-08-29 8:41 PM, Robert O'Callahan wrote:
 Some of the 16-17 regressions are known and due to DLBI patches (bug
 539356). Since we don't have full DLBI on trunk yet, those changes should
 just be preffed off on Aurora for 17. We should do that and see how that
 affects the numbers. Matt Woodrow will take care of that :-).

That's good to hear.  Is there a bug on file for that?

Ehsan

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform