Track repaint causes · emilk/egui#3931

(1 comment) (2 reactions) (1 assignee)Rust (29,051 stars) (2,037 forks)batch import

good first issue

Description

Sometimes an egui application is repainting spuriously, and it can be hard to figure out why.

In particular: did someone call request_repaint, and if so, whom and why? There should be an API for that (ctx.why_did_we_repaint() -> Option<String> or something).

There are a few potential solutions: A) capture the callstack of each call to request_repaint B) capture the file:line of the function that called request_repaint using Location::caller() C) require a debug-string when calling request_repaint

A) will create a lot of noise (and a dependency on backtrace), so it is not very appealing. B) is pretty good, but seeing egui/src/context.rs:507 is not very informative C) is nice, but requires a breaking change, and clashing strings can make it hard to debug (e.g. several calls to request_repaint("animation").

I think a combination of B and C makes sense.

To avoid breaking changes we can deprecate request_repaint and create a new request_refresh or request_update or something that takes a impl Into<String> with the explanation for why there was a repaint. These strings are stored per viewport for two frames.

Contributor guide

Tech stack: rust
Domain: performanceobservability
Issue type: feature
Difficulty: 3
Estimated time: 1-2 days
Activity status: active
Clarity: clear
Prerequisites: Rustegui framework basics
Newbie friendliness: 35
Research direction: The issue proposes tracking reasons for repaints in egui. Three solutions are discussed: backtrace capture, Location::caller(), and requiring a debug string. The suggested approach is a combination of B and C, deprecating request repaint and introducing a new method. Key files to investigate: src/context.rs where repaint logic resides. The assignee may have further details. Focus on implementing the new API and storing explanation strings per viewport for two frames.