Taha-Mahmoodi fc644b9a9e Fix #3198: the status bar's fps is the rate the window draws at, not an average of idle bursts ...

The readout was a moving average of 1/dt over any two consecutive frames.
An idle window wakes now and then (a timer, a control request, a repaint
after input) and each wake-up draws two frames about 4 ms apart, the second
one not waiting for vsync because the swapchain has a free image. Every
wake-up pushed the average up by 0.1 x 240 and the idle gap pulled it down
by only 0.1 x 2, so at rest it climbed past the display's refresh rate
(105 fps on a 30 Hz monitor that was drawing 4 frames a second). As soon as
the pointer moved and frames became vsync-paced, it fell back to the real
rate, which looked like a slowdown.

- frame_rate: frames counted over the last second of continuous drawing.
  A gap more than 100 ms longer than the previous frame's own work means
  the window was idle and starts a new count. The readout changes only
  after half a second of drawing, so a wake-up's frames keep the last
  rate. Slow frames still read slow, because their gap is their own work.
- chrome: "– fps" until the window has drawn continuously, instead of 0.

Measured on an Apple M4 driving a 30 Hz 4K display: drawing continuously
reads 30; at rest with a wake-up every 0.5 s it stays 30 (before: 45 -> 105).

2026-10-21 15:42:35 +07:00

..

src

Fix #3198: the status bar's fps is the rate the window draws at, not an average of idle bursts

2026-10-21 15:42:35 +07:00

build.rs

Build: generated sources are rewritten only when they change

2026-10-11 07:13:32 +07:00

Cargo.toml

Save for Web: browser previews go only to a folder the current user owns

2026-10-21 15:42:35 +07:00