Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

perf(x11): use a Timer instead of a DispatcherTimer for render callbacks #19054

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

ramezgerges
Copy link
Contributor

GitHub Issue (If applicable): closes #19042

PR Type

What kind of change does this PR introduce?

What is the current behavior?

What is the new behavior?

PR Checklist

Please check if your PR fulfills the following requirements:

Other information

Internal Issue (If applicable):

@ramezgerges ramezgerges changed the title chore(x11): use a Timer instead of a DispatcherTimer for render callbacks perf(x11): use a Timer instead of a DispatcherTimer for render callbacks Dec 10, 2024
@ramezgerges
Copy link
Contributor Author

@HakanL With this PR, the Uno app shouldn't be scheduled by the OS at all if there's nothing to do and should not be spin-waiting at all. Let us know if this fixes the problem.

// running XConfigureEvent and rendering callbacks on a timer is necessary to avoid freezing in certain situations
// where we get spammed with these events. Most notably, when resizing a window by dragging an edge, we'll get spammed
// with XConfigureEvents.
_timer = new Timer(static obj =>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we conditionally stop the timer if we know we do not have anything to draw?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can't directly pause the System.Threading.Timer but I think there are ways to get around this, if we're careful enough. However, I don't think it matters. The Timer actually sleeps (i.e. the equivalent of a Thread.Sleep) so waking up and immediately sleeping again 60 times a second should be more than fine.

Copy link
Member

@jeromelaban jeromelaban Dec 10, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The issue here is about CPU idle time, which may prevent CPU to go in low-power modes. It's generally best to avoid doing work we know nothing needs to be done.

@unodevops
Copy link
Contributor

🤖 Your Docs stage site is ready! Visit it here: https://unodocsprstaging.z13.web.core.windows.net/pr-19054/index.html

@HakanL
Copy link

HakanL commented Dec 10, 2024

@ramezgerges I'd be happy to test this on my RPi once you think it's ready to try. I haven't run my application with non-Nuget Uno (from source), do you have any docs on how to do that? I think last time I tried I wasn't able to successfully build it, but it was a while ago (may have been missing dependencies for Android, Mac, etc, since I'm only doing Win and Linux).

@unodevops
Copy link
Contributor

🤖 Your WebAssembly Sample App stage site is ready! Visit it here: https://unowasmprstaging.z20.web.core.windows.net/pr-19054/index.html

@unodevops
Copy link
Contributor

🤖 Your Docs stage site is ready! Visit it here: https://unodocsprstaging.z13.web.core.windows.net/pr-19054/index.html

@unodevops
Copy link
Contributor

🤖 Your WebAssembly Sample App stage site is ready! Visit it here: https://unowasmprstaging.z20.web.core.windows.net/pr-19054/index.html

@unodevops
Copy link
Contributor

⚠️⚠️ The build 149972 has failed on Uno.UI - CI.

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.

Raspberry Pi CM4 High CPU usage
4 participants