Wasm build fixes - #2
Open
lynt-smitka wants to merge 4 commits into
Open
Conversation
The MICROPY_DYNAMIC_COMPILER emit_native_table lists every arch's method table so -march can pick one at runtime. mpy-cross links this table but cannot provide the WASM native emitter: it needs the port-runtime symbol mp_wasm_compile_native, which only exists in the wasm port, not the host tool. So building mpy-cross fails with: undefined reference to `emit_native_wasm_method_table' Gate the table entry on MICROPY_EMIT_WASM (NULL when absent). The slot stays index-aligned to MP_NATIVE_ARCH_WASM32, and mpy-cross never selects wasm32 for freezing, so the NULL is unreachable there.
… API
The display-resource generator targeted an old bitmap_font API and broke the
wasm browser build:
- BitmapStub only had _load_row(); current bitmap_font writes glyph pixels
via bitmap[y*width + x] = bit -> "BitmapStub does not support item
assignment".
- glyphs are accessed as dicts (g["shift"], g["bounds"], g["bitmap"]) but
fontio.Glyph is an object -> "'Glyph' object is not subscriptable".
Give BitmapStub __setitem__ (flat index -> byte-packed bit) plus a byte-packed
.rows property (kept _load_row for the older API), and read glyph attributes
(g.shift_y, g.width/height/dx/dy, g.bitmap).
The wasm port's tools/gen_display_resources.py imports both (huffman for the translation compression, adafruit_bitmap_font to rasterize the built-in font), but neither was listed, so a fresh venv fails the browser build with ModuleNotFoundError.
…mebuffer Display only set canvas.style.width/height (CSS), not canvas.width/height (the backing-store resolution). An embedder whose <canvas> lacks width/height attributes gets the 300x150 default, so putImageData() of the fbWidth×fbHeight framebuffer is clipped/misplaced (the built-in IDE happens to hardcode the attributes). Set canvas.width/height to the framebuffer dimensions so any embedder renders correctly; CSS still scales it for display.
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 free
to 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.
Four small fixes found while building the
browser-boardwasm port from afresh checkout.
py/compile: guard the WASM native-emitter table slot for mpy-cross. The
dynamic-compiler table referenced
emit_native_wasm_method_table, whichmpy-cross cannot provide (it needs the port-runtime
mp_wasm_compile_native),so mpy-cross failed to link. Gated on
MICROPY_EMIT_WASM(NULL when absent;index stays aligned to
MP_NATIVE_ARCH_WASM32).tools/gen_display_resources: support the current
adafruit_bitmap_fontAPI. The generator assumed the old dict-glyph +
_load_rowAPI; the currentlib returns
fontio.Glyphobjects and writes glyph pixels viabitmap[i] = bit, which broke the browser build.BitmapStubnow supportsboth; glyph access uses attributes.
requirements-dev: add
huffman+adafruit-circuitpython-bitmap-font(imported by gen_display_resources but not listed, so a fresh venv fails).
wasm/js/display: set the canvas backing-store resolution (
canvas.width/canvas.height) from the framebuffer, not just CSS. Otherwise an embedderwhose
<canvas>lacks width/height attributes gets the 300×150 default andputImageData()is clipped.