How M3E Canvas Changes Shape Across Screens
M3E Canvas treats a phone sketch and a wide-screen sketch as related design states, not merely as two unrelated artboards. This chapter follows what happens when a frame changes size: which geometry is recalculated, how a navigation bar can become a rail, and how the design's theme remains shared across the result. The practical understanding is simple but consequential: responsive intent lives in the relationships that survive a resize, while positions and component forms may need to be recomputed.
A frame change is a lifecycle, not a scale factor
A scale factor makes a useful image smaller or larger. It does not make a phone layout into a desktop layout. A wide screen may have room for a persistent navigation rail; a phone may use a navigation bar along the bottom. The body may gain horizontal space, lose a reserved slot, or need to move a component that no longer fits. M3E Canvas handles this as a change in the frame's state, with a series of consequences for the screens and groups associated with it.
The editor offers a phone frame with a 412×892 reference and a desktop frame with a 1280×800 reference. These are not promises about every real device. They are concrete design regimes that let the author explore a compact portrait composition and a wide composition in one document. The implementation also uses an 840dp threshold for the expanded window class, so the relationship between the two presets is not based on an arbitrary visual stretch. It is tied to a component decision: at a wide enough width, navigation may be represented by a rail rather than a bar.
When a frame changes size, the editor first updates the frame itself. Other screens whose left edges were beyond the old right edge are shifted by the width difference so they do not overlap the changed frame. This is a canvas concern, not a product-layout rule: it keeps neighboring artboards legible while one artboard grows or shrinks. The groups belonging to the changed frame are then identified by their frame membership, which is based on their geometric bounds and center.
The next decision is how much of each part's size expresses a relationship to the old frame. Edge-to-edge bars follow the new width. A part that used the old screen width or old content width can take the corresponding new width. A half-width element can remain a half-width element in the new regime. A card or image keeps its shape while being constrained not to exceed the new content area. A box or rail that was as tall as the old screen can follow the new height. A camera or map area can preserve its aspect relationship when its width changes.
This is not a general responsive constraint solver. It is a set of recognizable carry rules. A full-width top bar should continue to span its new screen; a card should not become a desktop-wide banner just because the frame grew; a deliberately narrow button should not automatically fill the screen. The editor uses stored sizes and known component roles to distinguish a relationship to the frame from a size the author chose independently. That distinction is what prevents resizing from erasing every local decision.
Navigation is the most revealing case. A standalone bottom navigation bar on a compact frame can become a navigation rail when the frame enters the expanded regime.