[combwizard]

The ring opens faster, the first time after start as well as every time after, and hover, fans and taps are smoother. What it draws is unchanged, with one exception listed under "Behaviour changes".

What changed

The ring keeps more between opens (ring.py)

• The static layer (guide rings, spokes, tag band, title, hint) was drawn again on every open and after a tap. It is now kept in a bounded cache, keyed on everything it is drawn from.
• The dashed lines of a fan are kept the same way.
• A slot that keeps its size is no longer resized on every frame.
• The frame is premultiplied in one pass when it is handed to Windows.
• An icon's signature is worked out once per image, not on every open.

The app draws ahead (radiald.py)

• About a second after the menus load or change, the app draws what the next open will look up: the rings the hotkeys open, their fans, the rings one level down, and the click-hint layers. It does one picture per timer tick on the main thread.
• It gives way while a ring is open, a hotkey is held or a pick is on its way to ZBrush, and it waits for the thumbnail prefetch and the first recent lists.
• A change of menus, profile, look or display scale drops the plan and starts a new one, debounced.
• It fills at most three quarters of each cache, and its timer is gone when the plan is done.
• It plans for ZBrush's monitor, remembered while another program is in front.

Bug fixes found on the way

• The auto slots of a submenu that opens as a ring could change order when it was opened: the menu was filled twice, and the second fill read the filled auto slots as pinned brushes. A menu the expander has filled is now passed through unchanged (expand.py, config.Menu.filled). This was on main before this branch.

Behaviour changes

• A tag's items that open as a ring of their own (no room for the fan by a screen edge) now have the tag's colour, as they do in the fan. Before, the second fill gave each the colour of its own first tag.
• The static layer cache holds up to 32 MiB. Memory after warm-up is higher than a freshly started app used to be, and close to what it reached after ordinary use.
• One line in radiald.log when a warm-up has drawn something.

Measured

Medians from one development PC, off screen with the real renderer, 16-slot ring at 150% scaling. Before is main.

Measure	Before	After
First open after start	378 ms	8 ms
Open again	98 ms	7 ms
Hover frame	11.3 ms	3.8 ms
Fan-open tick	38 ms	9 ms
Tick after a tap	103 ms	15 ms

Not measured: anything with live ZBrush, the real hook or a pen.

Checks

• A reference set of 1195 pictures (previews, animation frames, composed frames, fans, three looks, both themes, slider-style edits) is byte-identical to main, also when every picture came from the warm-up. Bytes pushed to the window differ by at most 1 per channel, from the one-pass premultiply.
• tools/ring_shots.py output is the same before and after; no docs picture is retaken.
• Tests: 2860 pass. New: tests/test_ring_warm.py, tests/test_auto_order.py, tests/test_tag_ring_colours.py, and the cache tests at the end of tests/test_ring.py.
• Each phase had a separate cold review. The review of the warm-up found three defects (the auto slot reshuffle, a pick landing in a different auto slot, and planning at the wrong scale with monitors at different scaling); all three are fixed in later commits here and were confirmed by the reviewer.
• No docs page changes: none describes open speed, start-up or memory. The code commits used ZORBIT_NO_DOCS=1.

Worth a look on a real ZBrush before merging

• First press of the hotkey after ZBrush starts, and after a save from Studio.
• A submenu with auto slots that opens as a ring: its slots stay put.
• A tag fan by a screen edge.
• radiald.log has a ring warm-up line after start.