Track repaint causes
- Dominant language
- Rust
- Stars
- 30.6k
- Forks
- 2.1k
- Avg merge
- 1d 9h
- Merged PRs (30d)
- 72
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` 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()`](https://doc.rust-lang.org/nightly/core/panic/struct.Location.html#method.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` with the explanation for why there was a repaint. These strings are stored per viewport for two frames.
Contributor guide
Assessment
This issue has not been assessed yet.