Bitmaps must reload at the destination display's resolution when moved

What it is

A window is dragged from a 1× screen onto a 2× screen. If the toolbar icons are still the bitmaps decoded at launch, the system can only stretch those pixels, and edges go soft. DPI-aware bitmap reload means fetching the raster assets that match the destination scale after the move, not stretching the old raster once. Vectors and text can re-rasterize in place; icons, photos, and ornaments already baked into pixels will carry the source screen’s resolution unless this step runs. The entry assumes the app already knows each screen’s scale. It is only the asset pipeline swapping pixels at the moment of the move.

Why it happens

A bitmap’s information is fixed at decode. A 16×16 icon prepared for 1× has to cover 32×32 physical pixels on a 2× screen; the in-between values are interpolation, and high-frequency detail does not come back. The reverse—dropping a 2× asset onto a 1× screen and shrinking—aliases, looks soft, and wastes decode and memory. Text and vector paths generate pixels under the current transform on every draw, so they “automatically” sharpen across screens; bitmaps have no such free path. Window movement is a runtime event; resource tables are often built once for the launch screen. Failing to swap when scaleFactor changes writes the source screen’s resolution into the window’s whole life. Multiple rungs (1× / 2× / 3×) exist to match common discrete scales; in-between scales still pick the nearest rung and scale from there—the point is not to start from the wrong rung.

Where it stops holding

A purely vector UI has almost no bitmap to reload; the claim is not observable. A window that never leaves one screen only needs the right rung at launch. Photographs and video frames are content at a given resolution; “reload the matching asset” is meaningless—decode or post-scale to the destination’s physical pixel size so the image is not sized for the source screen and then stretched again. Remote desktop and screencast that already paint a bitmap on the source cannot be saved by a sharper destination; that is the transport, not the app’s resource table.

Applying it

• Keep scale-rung rasters for icons, toolbars, cursors, and ornaments, and select by the new scale when the window enters a screen, rather than decoding once at launch.
• Do not bake vector chrome into a bitmap and then stretch it; when a bitmap is required, drop the old texture and decode a new one after the move.
• Do not decode large images every frame while the window is dragged; swap after it settles on the destination or when that screen owns most of the area, so the drag does not stall.
• Verify: move a window with toolbar icons wholly from a 100% screen to a 200% screen, screenshot, and inspect icon edges pixel by pixel. Source-rung stretch looks blocky; a successful reload aligns edges to the destination pixel grid. Drag back and confirm the oversized rung is not still in use, aliasing on the 1× screen.

Related

• Within the group: K2.08.1 Apps must read each display's scale, not a system-wide value · K2.08.3 Apps that ignore per-display scale go blurry or misaligned on high-DPI screens · K2.08.4 Font size and spacing conversions accumulate error under mixed resolutions
• Adjacent: K2.02 Multiple Displays · K1.02 Screen Size and Density Differences
• Search terms: DPI-aware bitmap · scale-on-move · backing store