Skip to content

Conversation

@amartya4256
Copy link
Contributor

This PR contributes to reducing the number of redraws and only draw once all the widgets have performed scaling using their Widget:handleDpiChange handlers.

contributes to
#62 and #128

@github-actions
Copy link
Contributor

github-actions bot commented Sep 1, 2025

Test Results

   546 files  + 7     546 suites  +7   32m 21s ⏱️ - 2m 20s
 4 426 tests +54   4 409 ✅ +52   17 💤 +3  0 ❌ ±0 
16 750 runs  +54  16 623 ✅ +52  127 💤 +3  0 ❌ ±0 

Results for commit ea39b0e. ± Comparison against base commit ae2bb1d.

♻️ This comment has been updated with latest results.

@amartya4256 amartya4256 linked an issue Sep 1, 2025 that may be closed by this pull request
@amartya4256 amartya4256 force-pushed the amartya4256/dpi_performance_improvement/reduce_redraws branch from 75ebdf5 to c48a23f Compare September 2, 2025 13:12
@HeikoKlare
Copy link
Contributor

@amartya4256 that means the redraw that we triggered for every composite so far was just redundant? Can you shortly explain why the redraw does still happen at the end of processing the DPI change handlers?

I tested the change and at a first glance it works fine for me. In particular, it already improves performance and the visual experience when doing the rescaling as everything is just redrawn at once and not every composite/control independently, which looks much better.

@amartya4256
Copy link
Contributor Author

@amartya4256 that means the redraw that we triggered for every composite so far was just redundant? Can you shortly explain why the redraw does still happen at the end of processing the DPI change handlers?

I tested the change and at a first glance it works fine for me. In particular, it already improves performance and the visual experience when doing the rescaling as everything is just redrawn at once and not every composite/control independently, which looks much better.

On a second look, the widgets are implemented in such a way that they implicitly redraw upon being resized or moved. There are multiple reasons. Some call layout which triggers it, some send Resize or Redraw event and the handler does it for them. But in the end, most of the widgets seem to be dealing with repainting using layout, which already aligns them and paints them and then the loop control is passed to the parent, who then resize and repaint themselves. So, internally, it is handling repaints the moment we change their bounds, hence, we can also remove shell resize and shell layout from the dpi change handler for Shell and Control's handleMonitorSpecificDPIChange.

This commit contributes to reducing the number of redraws and only draw
once all the widgets have performed scaling using their
Widget:handleDpiChange handlers.

contributes to
eclipse-platform#62 and
eclipse-platform#128
@HeikoKlare HeikoKlare force-pushed the amartya4256/dpi_performance_improvement/reduce_redraws branch from c48a23f to ea39b0e Compare September 5, 2025 13:44
@HeikoKlare
Copy link
Contributor

Sounds good. Thank you for the explanation! Let's keep potential further improvements for follow-up PRs.

@HeikoKlare HeikoKlare merged commit f0e13ed into eclipse-platform:master Sep 5, 2025
17 checks passed
@HeikoKlare HeikoKlare deleted the amartya4256/dpi_performance_improvement/reduce_redraws branch September 5, 2025 15:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Reduce Redraw On DPI Scaling

2 participants