I’m looking to improve rendering performance by looking at input events, determining the specific change, and only re-rendering for the specific area that the change applies to. For example, if I move a slider slightly, the re-render would only be for the knob of the slider and the region of the slider background which pertains to the [old value, new value] range.
I’m pretty confident that this will not be easy (though I do see the current logic is already sort of implemented in terms of invalidated render regions). I’m looking to give it a try anyway for some widgets which are causing performance issues when responding to events. I’d rather modify existing widgets than make my own new, optimized widgets, so I can make use of their existing features.
This probably won’t go anywhere since this sort of update is tough when the code isn’t already set up in this way, but might be useful for future similar discussions/requests.
I’ve got a few questions:
- Is there already some widget that has this sort of behavior? (can probably ignore the rest of the questions if so)
- I’m unfamiliar with the codebase - broadly speaking, what systems (if any) would need changes to allow: (1) diffing widget state, (2) permitting an object to refresh without invalidating its whole bounds (header/source file names would be helpful)
- Is it at all feasible to try to implement this on a per-widget basis, or is there some global assumption about rendering that would be invalidated by this, requiring a larger refactor?
- If (3) is feasible, how difficult would you expect this change to be if made on a per-widget basis, from 1 (< 10 LoC change) to 10 (refactor the whole event/render systems)
- Aside from the obvious (ie, “just optimize the widget/usage in general”), what might I have missed?