mirror of
https://github.com/storytold/vectorcraft.git
synced 2026-10-14 19:26:56 -04:00
bflatasticandClaude Opus 5.5
f46527e0bd
Over the canvas the window hid the system cursor and painted the tool's cursor glyph into its own frame. That glyph reached the screen only after the frame was rendered, queued (two frames by default) and composited, so on Windows it visibly trailed the real pointer, on any GPU: the "sluggish mouse" of the report. Frame times were not the cause (0.4 ms empty, 1.5 ms median on a 20 000-path document, and no repaints while idle). - cursors: the glyphs are collected as shapes, tessellated by egui and rasterized into straight-alpha RGBA bitmaps (anti-aliased, hotspot on a pixel corner), cached per cursor and display scale so the same Arc is handed over every frame and egui-winit keeps its OS cursor. - canvas: on Windows and Linux the tool cursor goes to the OS through ctx.set_cursor_image; the system moves it itself. macOS (bitmaps sized in points) and the web (no bitmap cursors in eframe) keep painting it. - app: the wgpu surface queues one frame instead of two (LOW_LATENCY): the GPU only composites the CPU-rendered canvas, so everything drawn in the window follows the pointer a frame sooner. Co-Authored-By: Claude Opus 5.5 <[email protected]>