-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Add Context::request_repaint_after #1694
Conversation
Thanks for starting to work on this! I think it is worth thinking through what the most common use cases for this feature would be. If this is a setting ("minimal refresh interval") I think it would make most sense to have it as a member of However, there could be cases were an egui widget want to schedule a deferred repaint. For instance, a clock widget may want an update every second to show move the second hand. In this case it makes more sense to have it as a member of Thoughts? |
I thought it would be best to implement this in eframe too, but then i realized other non-eframe implementations might want this feature too and decided to use The primary purpose of this issue was to just have some sort of timeout interval for the next repaint callback. I had two use cases in mind:
I did not think about widgets explicitly wanting to set a timeout. but, I don't think that changes anything here. my plan was to only just store the shortest duration too. as long as the repaint happens at or before the Instant desired by widget / user, they can recalculate their next duration according to their repaint needs just like in stop watch usecase. I guess, that settles most questions. the name so, its not that we are requesting repaint within X duration. we are rather timing out during app idle time without any input events. |
Good points! Perhaps You can also use |
should i just replace it will be a breaking change |
Yeah, I think that sounds good! |
I have no idea how to deal with web, so i left it alone except changing the type signature in the logic function.
|
Unfortunately libspeechd is failing to link on my arch. So, I could not check for failures offline with --all-features. Had to commit and wait for ci workflow to run and show me errors to fix. I hope this works now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excellent job - sorry for the slow review, but almost there now!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excellent job - sorry for the slow review, but almost there now!
@@ -194,7 +202,12 @@ pub fn run_glow( | |||
painter.destroy(); | |||
} | |||
winit::event::Event::UserEvent(RequestRepaintEvent) => window.request_redraw(), | |||
_ => (), | |||
winit::event::Event::NewEvents(winit::event::StartCause::ResumeTimeReached { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should be able to combine these with winit::event::Event::UserEvent(RequestRepaintEvent | winit::event::Event::NewEvents…
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a feeling that we might see some sort of issue with repaint_after
feature once people start using it.
so, i thought it would be better for debugging or adding special case handling for ResumeTimeReached
event if both are treated as separate events.
apologies for the delay. I had sudden irl stuff to take care of until yesterday and only now got to finally open my PC to work on this. |
think all CI should pass now. its been so long since i cared about grammar, that i forgot you capitalize first letter in a sentence :) |
Great job! |
Follow-up to #1694
* Implement repaint_after for eframe web Follow-up to #1694 * cargo fmt * Simplify demo UI for "repaint_after"
Closes #1691.
kinda my first PR.
I am wondering whether i should store this idle timeout interval in
platform output
ourfull output
. I did not implement this for wgpu yet, but should be pretty similar.by storing it in platform output, it affects the
take
function and theDefault
derive to be manually implemented.