A visual high-DPI check
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
Research direction
Start by reading ROADMAP.md and references/video.md, then check SDL 3.4.18's source for a way to make the dummy or offscreen driver report a display scale. Decide whether a headless fixture pair can prove the High DPI behavior or whether a manual sample is feasible. Record the dated decision in ROADMAP.md; done also requires a milestone and checklist for this issue.
Written by the indexing model from the issue text.
Description
High DPI is guidance today, because no headless test shows a port drawing at the wrong size on a high-DPI display. This would need a way to prove it headless, or a check that a person can run.
What has to be settled before this gets a milestone
- A headless proof. A trap exists only if its naive fixture fails headless in CI. The dummy and offscreen drivers report no display scale, so look in SDL 3.4.18's source for a way to give them one, such as a hint or an environment variable. If one exists, High DPI in
references/video.mdcan become a trap with a fixture pair, like the others. - A check a person runs. If there's no headless way, a small sample that draws a known-size frame and reports pixel size against window size could run on a scaled display by hand. It wouldn't make High DPI a trap, but it would back the guidance with something checkable.
- The other guidance sections. ROADMAP.md lists nine changes as guidance for the same reason. Whatever works here may work for some of them.
Done when
- The settled answers are a dated decision in ROADMAP.md, and this issue gets a milestone with its own checklist.
- Dominant language
- C
- Stars
- 1
- Forks
- 1
- Avg merge
- 3m
- Merged PRs (30d)
- 1
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from hazeliscoding/sdl3-porter
-
trap-cards check: require every part of a trap cardPossibly taken A pull request linked to this issue is open or already merged. Openenhancement good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
hazeliscoding/sdl3-porter#20 ·
-
documentation good first issue
Difficulty 1/5 1-3 hours Newbie friendliness 83/100
hazeliscoding/sdl3-porter#19 ·
-
Test find_traps.py's search of the committed SDL2 codePossibly taken @ian0318git claimed this 1 day ago. Opengood first issue
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
hazeliscoding/sdl3-porter#18 ·
-
bug good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
hazeliscoding/sdl3-porter#17 ·
-
trap-cards check: require a sample and an eval case for every trapPossibly taken A pull request linked to this issue is open or already merged. Openenhancement good first issue
Difficulty 3/5 1-2 days Newbie friendliness 82/100
hazeliscoding/sdl3-porter#21 ·
All issues in hazeliscoding/sdl3-porter
Similar issues
-
TLS: a stale OpenSSL error makes non-blocking reads fail with "Resource temporarily unavailable"Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 1-3 hours Newbie friendliness 82/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
bigtreetech/BIGTREETECH-TouchScreenFirmware#3056 ·
Maintainers usually reply within 1 day
-
Allow pillow 13Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
[pico][astrocade] emu/apply.sh edits src/mame/midway/astrohome.cpp, which current MAME has in bally/Open
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
FujiNetWIFI/fujinet-firmware#2120 ·
Maintainers usually reply within 1 day