* Don't show window until after initialization
Shortens #1802, but does not completely solve it
* format code
* Present first frame immediately before showing window
This resolves the white flash almost completely, but is a hack. Window
visibility should be derived from the AppOutput, and the first frame
should not be painted before the event loop has processed initial
events.
Working on a better implementation.
* Integrate window showing with AppOutput
This allows an app to keep the window hidden (never shown) by calling
Frame.set_visible(false) on the first update. This includes a slightly
less nasty hack than the last commit did.
Also fixes an accidental cross-contamination of pull requests.
* fmt
* add comments
* add comments
* add comments
* add comments
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
* eframe: Repaint immediately on RepaintAsap, fixes#903
This completely eliminates the white flickering seen on Windows when
rapidly resizing a window on the glow backend. The reason that happens
is because DWM only waits for the resize event to be delivered before
displaying the window at its new size. You must repaint synchronously
inside that iteration of the event loop or else you get flickering.
* Differentiate between RepaintAsap and RepaintNext
RepaintNext looks like it is indeed needed in at least one case instead
of RepaintAsap.
* Use RepaintNext in more situations
Starting to understand why this was the behavior. It looks like only a
few special cases should be given RepaintAsap, such as the window being
resized. All other cases should be RepaintNext, as it can wait.
Using RepaintAsap in all situations will cause things like lag when
changing a slider by keyboard with a high key repeat rate.
* Add explanatory comments
I am a total hypocrite for forgetting to add these.
* Rename RepaintAsap to RepaintNow
There is no notion of "possibility" here like there is when waiting for
RedrawEventsCleared. RepaintNow causes an immediate repaint no matter
what.
* Fix RepaintNow comment
"Delays" is ambiguous.
* introduce new wgpu configuration option to allow configuring wgpu renderer
* use new options with wgpu web painter
* use on_surface_error callback
* changelog update
* cleanup
* changelog and comment fixes
* Bug fix: reset repaint countdown when we pass it
* eframe: debug-print what winit event caused a repaint
* egui-winit: don't repaint when only moving window
* fix docstring
* eframe: allow hooking into EventLoop building
This enables native applications to add an `event_loop_builder` callback
to the `NativeOptions` struct that lets them modify the Winit
`EventLoopBuilder` before the final `EventLoop` is built and run.
This makes it practical for applications to change platform
specific config options that Egui doesn't need to be directly aware of.
For example the `android-activity` glue crate that supports writing
Android applications in Rust requires that the Winit event loop be
passed a reference to the `AndroidApp` that is given to the
`android_main` entrypoint for the application.
Since the `AndroidApp` itself is abstracted by Winit then there's no
real need for Egui/EFrame to have a dependency on the `android-activity`
crate just for the sake of associating this state with the event loop.
Addresses: #1951
* eframe: defer graphics state initialization until app Resumed
Conceptually the Winit `Resumed` event signifies that the application is
ready to run and render and since
https://github.com/rust-windowing/winit/pull/2331 all platforms now
consistently emit a Resumed event that can be used to initialize
graphics state for an application.
On Android in particular it's important to wait until the application
has Resumed before initializing graphics state since it won't have an
associated SurfaceView while paused.
Without this change then Android applications are likely to just show
a black screen.
This updates the Wgpu+Winit and Glow+Winit integration for eframe but
it's worth noting that the Glow integration is still not able to fully
support suspend and resume on Android due to limitations with Glutin's
API that mean we can't destroy and create a Window without also
destroying the GL context, and therefore (practically) the entire
application.
There is a plan (and progress on) to improve the Glutin API here:
https://github.com/rust-windowing/glutin/pull/1435 and with that change
it should be an incremental change to enable Android suspend/resume
support with Glow later.
In the mean time the Glow changes keep the implementation consistent
with the wgpu integration and it should now at least be possible to
start an Android application - even though it won't be able to suspend
correctly.
Fixes#1951
Since https://github.com/emilk/egui/pull/1919 we can continue
the application after closing the native window. It therefore makes
more sense to call `frame.close()` to close the native window,
instead of `frame.quit()`.
