Upstream commit: https://webrtc.googlesource.com/src/+/f9ddf7fed6617c21f8be6f32737953751fb5701b
Replace test frame capturer wanted_fps_ by target_capture_fps_.
wanted_fps_ seems redundant with target_capture_fps_.
The problem with wanted_fps_ is that it lowers the capture fps but does not decimate frames so that a 30 fps stream played at 5 fps is played slowly instead of played at the normal speed with dropped frames.
Change-Id: I1440953f9909ad1d4a102a0671fe933d95498a1f
Bug: b/355120692
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/357780
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#42670}
Upstream commit: https://webrtc.googlesource.com/src/+/7fe62f25d14aef7dc17c4ba7742f8065c22fc968
Reland "Fix 'Image will be cropped if WindowCapturerWinGdi used'"
This is a reland of commit 844225a76a98aa3be5aca09c19ab72a5e7b6c38a
Original change's description:
> Fix 'Image will be cropped if WindowCapturerWinGdi used'
>
> Bug: webrtc:15719
> Change-Id: I7daf8ee5b90fbe9f1246f1d99211ffa0d8a19f73
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/330780
> Reviewed-by: Alexander Cooper <alcooper@chromium.org>
> Commit-Queue: Alexander Cooper <alcooper@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#41503}
Bug: webrtc:15719
Change-Id: Idbb2f4dcc8811d3b2b763a49adc7a57535b3d1b2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/334380
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42666}
Allows Wasm DebuggerFrame to be suspended/resumed.
Disables ASAN for StackPointerInfo for better testing.
Depends on D214001
Differential Revision: https://phabricator.services.mozilla.com/D218246
Instead of dropping the frame's memory chunk when a frame is replaced, place the chunks into a global pool. This mostly helps when running stress tests like motionmark's html suite that cause intense allocation spikes (around 90 chunks per frame).
We should revisit whether this is needed if the cost of deallocating large regions of memory in mozjemalloc improves in the future.
Differential Revision: https://phabricator.services.mozilla.com/D223924
Rewrite `BigInt.asIntN(cst, BigInt(IntPtr-or-Int64))` to perform the sign-extension
in inline assembly using either `MSignExtendIntPtr` or `MSignExtendInt64`. (Or use
shift instructions when native sign extension isn't possible.)
See bug 1685708 for why optimising `BigInt.asIntN` is useful.
Differential Revision: https://phabricator.services.mozilla.com/D223337
This instruction is similar to `MSignExtendInt32`, but instead of just
extending its input to 32-bit, it allows extending to pointer size.
Used in part 9.
Differential Revision: https://phabricator.services.mozilla.com/D223336
Clean-ups to align with `MSignExtendIntPtr` from part 8:
- `MSignExtendInt{32,64}` don't have a type policy, so assert the input has
the correct type.
- `MSignExtendInt{32,64}::congruentTo()` doesn't need to recheck the argument
type after `congruentIfOperandsEqual()`.
- `LSignExtendInt32` doesn't need to store `MSignExtendInt32::Mode`, but can
instead query its mir instruction.
Differential Revision: https://phabricator.services.mozilla.com/D223335
When D219643 added the `MInt64ToBigInt::elementType` field, `Scalar::Type` was still
used in `CodeGenerator::visitInt64ToBigInt`. But today all callers only care about
the signed or unsigned state, so it's easier to encode this directly as a `bool`.
Differential Revision: https://phabricator.services.mozilla.com/D223333
Using IntPtr sized operations allow easier integration with BigInt-as-IntPtr optimisations.
Also add existing Int32ToBigInt optimisations to IntPtrToBigInt:
- Use inline allocations in CacheIR.
- Handle constants in `MTruncateBigIntToInt64::foldsTo`.
- Handle `MIntPtrToBigInt` in `MToInt64::foldsTo`.
Change `LIRGenerator::visitInt32ToIntPtr` to ensure we don't see unexpected uses of
`MInt32ToIntPtr`, now that this instruction is also used outside of index operations.
Differential Revision: https://phabricator.services.mozilla.com/D223331
The sequence `setCC` + `movzbl` can cause a register stall due to the partial
register write performed by `setCC`. If possible emit a `xorl` before the
comparison to zero the output register. If the output register is aliased by
an input register, we can't zero it and instead keep `movzbl`. To also prevent
a possible register stall in this scenario, we could emit `movl(d, 0)` directly
before the `setCC`, but that'd lead to code size increases, becauce `movl` with
an immediate requires five bytes to materialise the immediate, whereas `movzbl`
with two register inputs only requires three bytes. (`xorl` with two register
inputs only requires two bytes, so it's even smaller than `movzbl`.)
Differential Revision: https://phabricator.services.mozilla.com/D223150
Because of the possibility of different rendering modes, it's not guaranteed that
canvas2d.measureText will return exactly the same text metrics as HTML uses.
So instead of relying on canvas to measure substrings of the URLbar content,
measure by putting the text in a <span> and querying its offsetWidth.
Differential Revision: https://phabricator.services.mozilla.com/D223617
This brought in a breaking change: `Suggestion.icon` is now the `bytes`
type. To accomidate that, added UniFFI support for bytes and updated
the SuggestBackendRust code since that field is now a Uint8Array on the
JS side.
Differential Revision: https://phabricator.services.mozilla.com/D223774
