Uh oh!
There was an error while loading. Please reload this page.
JS port: device pixel ratio for breakpoints, and a millimetre that means the same thing at every ratio - #5634
Merged
Conversation
An application that lays out against a width breakpoint has no way to write one any more. getDisplayWidth() reports device pixels -- 7.0.267 made this port report them too, so the framework could draw at native resolution -- and a threshold written in CSS pixels therefore moves with the display: a 390pt phone at ratio 3 reports 1170, so "is this narrower than 600" answers no on a phone. The BuildCloud console lost its phone layout exactly that way, and could no longer be made to appear in a browser's responsive mode. Nothing already reachable answers it. getDeviceDensity() sorts the ratio into buckets, so dividing by anything derived from it steps rather than scales, and convertToPixels() inherits that. The ratio itself is what the question needs and the browser knows it exactly, so hand it over beside the other browser.window.* properties and let the application divide. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
convertToPixels() sorted the display into one of nine Android-shaped density buckets and read a nominal dpi out of the bucket, which only lands on Codename One's 160dpi-per-CSS-pixel baseline at ratios 1 and 2. Everywhere else a millimetre stopped being a millimetre: ratio 1 MEDIUM 160dpi -> 160 effective ok ratio 1.5 MEDIUM 160dpi -> 107 effective 33% too small ratio 2 VERY_HIGH 320dpi -> 160 effective ok ratio 2.5 HD 540dpi -> 216 effective 35% too large ratio 3 HD 540dpi -> 180 effective 12.5% too large Ratio 1.5 is ordinary -- plenty of Android hardware, and Windows at 150% scaling. Ratio 3 is every recent iPhone. Measured on the BuildCloud console at 390pt, the same screen rendered 13.9-25.8 CSS pixels of text at ratios 1 and 2 and 15.6-29.1 at ratio 3, so the whole interface stepped up an eighth on a 3x display and nothing on the page could be laid out to fit both. A browser does not have to guess at any of this. It reports the ratio exactly, so the baseline scaled by the ratio is the answer, and the same screen now measures 13.9-25.8 at ratios 1, 1.5, 2, 2.5 and 3 alike. Verified in Chromium and in Firefox. getDeviceDensity() keeps its buckets deliberately. That one picks which resolution of an image to load, a real choice between a handful of assets that wants to be quantised; this is a continuous conversion and does not. An explicit ?density= override is honoured exactly as given -- someone forcing a density is asking for that density, not for a correction to it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
Contributor
Cloudflare Preview
|
Contributor
✅ Continuous Quality ReportTest & Coverage
Static Analysis
Generated automatically by the PR CI workflow. |
CollaboratorAuthor
Compared 181 screenshots: 181 matched. |
Contributor
✅ ByteCodeTranslator Quality ReportTest & Coverage
Benchmark Results
Static Analysis
Generated automatically by the PR CI workflow. |
Uh oh!
There was an error while loading. Please reload this page.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two consequences of #5552's native-resolution change that were left behind, both
found while chasing a broken responsive layout in the BuildCloud console.
Independent of #5629 — different files, different failure, no ordering between them.
1. Application code cannot write a width breakpoint any more
getDisplayWidth()reports device pixels, and since 7.0.267 this port reportsthem too rather than CSS pixels. A threshold written in CSS pixels therefore
moves with the display: a 390pt phone at ratio 3 reports 1170, so "is this
narrower than 600" answers no on a phone. The console lost its phone layout
exactly that way, and could no longer be made to appear in a browser's
responsive mode — which keeps a desktop User-Agent, so a UA check does not save
you, and applies a pixel ratio.
Nothing already reachable answers the question.
getDeviceDensity()buckets theratio, so anything derived from it steps rather than scales. The ratio itself is
what is needed and the browser knows it exactly, so this exposes it beside the
other
browser.window.*properties.2. A millimetre was not the same size at every ratio
convertToPixels()read a nominal dpi out of one of nine Android-shaped densitybuckets. That only lands on Codename One's 160dpi-per-CSS-pixel baseline at
ratios 1 and 2:
Ratio 1.5 is ordinary — plenty of Android hardware, and Windows at 150% scaling.
Ratio 3 is every recent iPhone.
Measured on the console at 390pt, text rendered 13.9–25.8 CSS px at ratios 1
and 2 and 15.6–29.1 at ratio 3. After the change the same screen measures
13.9–25.8 at ratios 1, 1.5, 2, 2.5 and 3 alike. Verified in both Chromium and
Firefox.
getDeviceDensity()keeps its buckets deliberately: that one picks whichresolution of an image to load, a real choice between a handful of assets that
wants to be quantised. This is a continuous conversion and does not. An explicit
?density=override is still honoured exactly as given.Blast radius — please read before merging
The second commit changes rendering for every JavaScript-port app at any ratio
other than 1 or 2. At 3x everything gets 12.5% smaller; at 1.5x a third
larger. That is the correction, but it is not a quiet one, and it will move
screenshot goldens for any app not captured at ratio 1.
The first commit adds a property and changes no behaviour.
Known gap, not addressed here
refreshDevicePixelRatio()is wired to the resize event, on the reasoning thatresize is when the ratio can change. A ratio can change without one — a
browser's responsive mode switching device profile is the case that prompted
this. A
matchMedia('(resolution: Ndppx)')listener would catch it. Left alonebecause it is a separate change with its own risk.