-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Web: Implement MonitorHandle
#3801
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
Conversation
bd041e8 to
d0b5a30
Compare
b7d9479 to
2c0c405
Compare
|
I extracted some unrelated changes to #3805 and based this PR on it. |
- Internal: Fix dropping `Notifier` without sending a result causing `Future`s to never complete. This should never happen anyway, but now we get a panic instead of nothing if we hit a bug. - Internal: Remove a bunch of `unwrap()`s that aren't required when correctly using `MainThreadMarker`. - `Window::canvas()` is now able to return a reference instead of an owned value. Extracted from #3801.
|
No changes so far, only rebasing on all the churn. |
| } | ||
| } | ||
|
|
||
| impl<V, S: Clone + Send, E> Eq for Wrapper<V, S, E> {} |
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.
Generally Eq/Ord go after their Partial impls.
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 generally do this alphabetically in the Web backend.
So I would like to stick to that.
I can make a follow-up PR where I align all derives and implementations in the whole crate to do PartialEq/PartialOrd before Eq/Ord and generally have the same order throughout the crate if you like.
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'd just suggest to do that for the new stuff since it's just pointless, unless we have a formatter support.
I won't block on the current order either, just noticed that it's usually other way around (you can also derive(Eq) if you have impl PartialEq).
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.
No unfortunately no formatter support ...
I will make a PR only for Web then, because Web follows alphabetical order so far.
a2739eb to
3075774
Compare
kchibisov
left a comment
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.
- already present comments about nesting, since the code is really hard to follow...
This is based on and requires #3805.This implements
MonitorHandleon Web by using the Window Management API, which is currently only implemented on Chrome.This gets a bit complicated, because to access the API the user has to explicitly be asked to give permission, on top of most calls being asynchronous. So to solve this I implemented a couple of things:
EventLoopis created, the browser is queried, in the background if the user has previously given permission to use the Window Management API.EventLoop::run(), it is delayed until this asynchronous query has finished. Which should really only be one tick.Window.screen, which is implemented on all browsers. The "downside" is that it contains much less information about the current monitor and no information about primary or other monitors.Cool things:
ActiveEventLoop::request_detailed_monitor_permission()has to be used.Futures have to polled to completion, dropping them is fine. They are only there to receive errors or allow the user to "know when something has finished doing its thing".MonitorHandles created with the Window Management API can be targeted withWindow::set_fullscreen().ActiveEventLoop::request_detailed_monitor_permission()do nothing, instead they share the result to minimize any JS overhead.Not cool things:
MonitorHandles to use the new API if they were created using the fallback.VideoModeHandleis basically useless, its only there to exposebit_depth().MonitorHandlewithWindow::set_fullscreen()only makes sense if it was created using the Window Management API, otherwise it doesn't work.Futures to completion.Follow-up:
OptionfromMonitorHandle::scale_factor().OptionfromMonitorHandle::position().Window::set_fullscreen()toWindow::request_fullscreen()and maybe return an error. If not introduce an Web-only async version of it to allow users to actually handle failure.bit_depth()toMonitorHandleand removeVideoModeHandlefrom Web again. (AddMonitorHandle::current_video_mode()#3802)