Closed Bug 1755346 Opened 2 years ago Closed 2 years ago

[wpt-sync] Sync PR 32837 - [aspect-ratio] Use continued fraction algorithm for LayoutUnit conversion

Categories

(Core :: Layout, task, P4)

task

Tracking

()

RESOLVED FIXED
99 Branch
Tracking Status
firefox99 --- fixed

People

(Reporter: mozilla.org, Unassigned)

References

()

Details

(Whiteboard: [wptsync downstream])

Sync web-platform-tests PR 32837 into mozilla-central (this bug is closed when the sync is complete).

PR: https://github.com/web-platform-tests/wpt/pull/32837
Details from upstream follow.

Ian Kilpatrick <ikilpatrick@chromium.org> wrote:

[aspect-ratio] Use continued fraction algorithm for LayoutUnit conversion

Previously we'd directly convert the float aspect-ratio to LayoutUnit.
This wasn't correct as we'd potentially lose a lot of precision in the
process.

Instead of this use the continued fraction algorithm to find a precise
representation.

This mitigates the current problem, but likely isn't the best end
scenario. We likely want to represent aspect-ratios as either a
LayoutUnit ratio, or float ratio, depending on the source.

(Specifically the LayoutUnit ratio is far better for the replaced
element case, except for aspect-ratio only SVGs, a float ratio may be
better for aspect-ratio only elements).

Bug: 1296175
Change-Id: I1a1f62fdfdb27785eb076ccaa2d5a4e81566fd46

Reviewed-on: https://chromium-review.googlesource.com/3459264
WPT-Export-Revision: 6f0b9070d3588014037e933846eae4d86bd4cc99

Component: web-platform-tests → Layout
Product: Testing → Core
Pushed by wptsync@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/fac7edf8a2a0
[wpt PR 32837] - [aspect-ratio] Use continued fraction algorithm for LayoutUnit conversion, a=testonly
Test result changes from PR not available.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 99 Branch
You need to log in before you can comment on or make changes to this bug.