This ensures we don't scale the underlying size of the layer beyond what
is close to the current display size. When box shadows get much larger
than this, they start taking so much time to render that successive
frames grow in scale too fast for any inter-frame reuse to be possible.
With this, we avoid that and no longer get crushed by re-rendering
gigantic box shadows every single frame.
See BZ 1383825
A second template parameter 'F' was previously added to SizeTyped, but
was not correspondingly added to the argument passed for the 'Sub'
parameter of BaseSize.
There's considerable cost associated with creating HWA draw targets
which would negate and regress the performance won by it if used for
too small targets (like small spans of text).
This only uses HWA if >= 8K SurfaceAllocationSize to balance HWA draw
target cost with box blur cost.
Only blur one quadrant of a box-shadow and mirror it to the other quadrants.
This applies only if the corners are symmetrical (square corners or equal
corner radii) otherwise we'll fall back to the old method.
This errs on the side of caution for what are installer packages, but
people getting conned into thinking this is safe is a bit too common.
They are akin in danger to .exe files in that respect as it installs
software, and should be treated similarly, so, warn about the potential
danger.
This is a low-priority init function that should not be called with
immediate dispatch to the current thread, for performance reasons.
Additionally, do not call RegisterDragDrop for hidden windows.
I figured I should include the reftest for the sake of completeness, though I have already verified the feature working from the site mentioned in the forum thread that prompted me to look into this in the first place.
Ref: BZ 1331528
Mozilla forgot to force use of VPXDecoder on Windows in their initial implementation, this is pretty much what they did for Android as well. Straight port of the Firefox 67 fix.
Ref: BZ 1528652
Mozilla found a bug in their initial implementation, causing paused WebM videos with alpha to become totally transparent if hardware acceleration is disabled. Straight port of the Firefox 54 fix.
Ref: BZ 1332952
Another requirement to have transparency in videos. Straight port of Firefox 53 implementation, save for some oddities relating to needing to put uint8_t instead of uint8 in yuv_convert to get this to compile.
Ref: BZ 1321076, 1329104
Required to have an alpha channel (which in the strange world of graphics seems to refer to transparency, and not experimental code) in WebM videos. Straight port of Firefox 53 implementation, adapted slightly for a couple of patches previously taken without this.
Ref: BZ 1320829
We previously didn't do this because we relied on our anonymous wrapper
to perform transforms. However, that resulted in only the children
transforming, and the frame's cliprect wouldn't be updated,
giving the impression of the z-ordering being wrong.
Also adds reftests from the relevant BZ bug found later.
Resolves#2355
This implements the changes from the "has consensus" PR in TC39
The second pair of `DefaultNumberOption()` calls was inlined, because
only the fallback case is relevant anyway.
Steps 12.d and 12.e from the spec PR were combined into a single
`if`-block. That way it also matches step 12.f more closely.
Also changed the single `if` steps into an `if-else if` chain, because
the steps are mutually exclusive.
Implements the changes to `SetNumberFormatDigitOptions` and
`FormatNumberToString`, except for the support of the new
"compact-rounding" mode.
This also includes a few minor fixes for edge cases (like -0 vs. 0)
This is the abstract operation that converts an option value to a number
value, checking whether it is in the allowed range, and filling in a
fallback value if necessary.
Bug 148624 - only show tooltip when document has focus
Partial Bug 1857513 - Use window activeness rather than document.hasFocus() to display chrome-only tooltips
