Using WM_PAINT for controlling the event loop is way too slow for real-time rendering #2782
Labels
Comments
fredizzimo
added a commit
to fredizzimo/neovide
that referenced
this issue
May 18, 2023
The default event loop on winit, at least on Windows is too slow. See rust-windowing/winit#2782
fredizzimo
added a commit
to fredizzimo/neovide
that referenced
this issue
May 19, 2023
The default event loop on winit, at least on Windows is too slow. See rust-windowing/winit#2782
fredizzimo
added a commit
to fredizzimo/neovide
that referenced
this issue
May 19, 2023
The default event loop on winit, at least on Windows is too slow. See rust-windowing/winit#2782
|
When debugging another issue I saw the following calls stack That is probably caused by these extra WM_PAINT messages and could explain why a few frames still are dropped on Windows with neovide/neovide#1870. |
|
Hi, it could be worth taking a look at #2767 where I've overhauled the structure of the event loops for each platform. Overall I'd say that the Windows backend was the one that changed the most, including enabling the use of PeekMessage when we want to check for messages without blocking. |
|
Thank you @rib. That does indeed look promising. I will take a closer look, maybe during the weekend. |
fredizzimo
added a commit
to fredizzimo/neovide
that referenced
this issue
May 25, 2023
The default event loop on winit, at least on Windows is too slow. See rust-windowing/winit#2782
fredizzimo
added a commit
to fredizzimo/neovide
that referenced
this issue
May 28, 2023
The default event loop on winit, at least on Windows is too slow. See rust-windowing/winit#2782
fredizzimo
added a commit
to fredizzimo/neovide
that referenced
this issue
Jun 5, 2023
The default event loop on winit, at least on Windows is too slow. See rust-windowing/winit#2782
fredizzimo
added a commit
to fredizzimo/neovide
that referenced
this issue
Jun 14, 2023
The default event loop on winit, at least on Windows is too slow. See rust-windowing/winit#2782
fredizzimo
added a commit
to fredizzimo/neovide
that referenced
this issue
Jun 27, 2023
The default event loop on winit, at least on Windows is too slow. See rust-windowing/winit#2782
fredizzimo
added a commit
to fredizzimo/neovide
that referenced
this issue
Jul 5, 2023
The default event loop on winit, at least on Windows is too slow. See rust-windowing/winit#2782
fredizzimo
added a commit
to fredizzimo/neovide
that referenced
this issue
Jul 5, 2023
The default event loop on winit, at least on Windows is too slow. See rust-windowing/winit#2782
fredizzimo
added a commit
to fredizzimo/neovide
that referenced
this issue
Jul 6, 2023
The default event loop on winit, at least on Windows is too slow. See rust-windowing/winit#2782
fredizzimo
added a commit
to fredizzimo/neovide
that referenced
this issue
Jul 12, 2023
The default event loop on winit, at least on Windows is too slow. See rust-windowing/winit#2782
fredizzimo
added a commit
to fredizzimo/neovide
that referenced
this issue
Jul 20, 2023
The default event loop on winit, at least on Windows is too slow. See rust-windowing/winit#2782
fredizzimo
added a commit
to fredizzimo/neovide
that referenced
this issue
Jul 20, 2023
The default event loop on winit, at least on Windows is too slow. See rust-windowing/winit#2782
fredizzimo
added a commit
to fredizzimo/neovide
that referenced
this issue
Jul 22, 2023
The default event loop on winit, at least on Windows is too slow. See rust-windowing/winit#2782
fredizzimo
added a commit
to fredizzimo/neovide
that referenced
this issue
Jul 22, 2023
The default event loop on winit, at least on Windows is too slow. See rust-windowing/winit#2782
fredizzimo
added a commit
to fredizzimo/neovide
that referenced
this issue
Jul 22, 2023
The default event loop on winit, at least on Windows is too slow. See rust-windowing/winit#2782
fredizzimo
added a commit
to fredizzimo/neovide
that referenced
this issue
Jul 24, 2023
The default event loop on winit, at least on Windows is too slow. See rust-windowing/winit#2782
fredizzimo
added a commit
to fredizzimo/neovide
that referenced
this issue
Jul 24, 2023
The default event loop on winit, at least on Windows is too slow. See rust-windowing/winit#2782
fredizzimo
added a commit
to fredizzimo/neovide
that referenced
this issue
Aug 9, 2023
The default event loop on winit, at least on Windows is too slow. See rust-windowing/winit#2782
fredizzimo
added a commit
to neovide/neovide
that referenced
this issue
Nov 1, 2023
* Split the grid into separate lines * Move scroll_region to the grid * Add some unit tests for grid scrolling * Use a ringbuffer to represent the grid This optimizes the scrolling a bit, especially pure up/down. * Draw each line as a skia picture This currently disables smooth scrolling. Which will be re-implemented using the scroll events and the skia pictures instead of the old scrolling snapshots. * Reimplement scrolling * Use simple pd controller for scrolling * Implement floating window transparency This also optimizes the blurring step, to not be done unless needed. Also removes the neovide_floating_opacity setting, since it's not clear how that should interact with neovim's default way of dealing with transparncy. * Optimize the foreground drawing a bit * Use pixel scroll offsets * Use scroll_delta * Draw directly without any surface Also speed up rendering of transparent surfaces * Remove win_viewport hack * Remove the undocumented floating_opacity setting * Split rendering and animation The animate function returs a boolean that tells if the animation should continue or not. * Improve the event loop All events are now processed before allowing rendering. * Remove the redraw_scheduler The various update functions, which are cheap to run, are always run and return true when rendering is needed. * Run the animation with equal and maximum step size * Filter the frame dt by a moving average * Use gr_context.flush_and_submit This properly submits everything to the GPU * Add a render thread The default event loop on winit, at least on Windows is too slow. See rust-windowing/winit#2782 * Implement vsync sources Windows using DwmFlush, Wayland using frame callbacks, a timer based vsync when --novsync is given, and standard swap_frame otherwise. Note on Windows, the there's some kind of race condition in the opengl implementation and waiting for DwmFlush before swapping fixes that. * Add some profiling blocks * Optimize font metrics This is done by caching the info, instead of re-calculating each time * Fix animations only running on one Window at a time * Document neovide far scroll lines * Improve performance, shape only the visible lines * Improve the scroll animation length documentation * Document neovide_refresh_rate * Update the actual rendered window on Flush rather than WinViewport * Require Neovim 0.9.2 * Rename neovide_scroll_animation_far_scroll_lines to neovide_scroll_animation_far_lines Also fix the documentation * Remove the far scroll configuration in favor of always scrolling like normal which looks better * Make multigrid default * Update multigrid docs * Review fixes * Fix lint errors * Fix reversed custom background condition * refactor: removing of nestings and early returns where possible * codestyle: calm rustfmt * fix: remove debugging leftover override of swap interval * feat: rename no_multigrid -> nomultigrid only on cmdline * Revert "Remove the far scroll configuration in favor of always scrolling like normal which looks better" This reverts commit b2ec34d. * Fix far scroll direction * feat(config)!: rename all config option sources to kebab-case * feat!: make frame naming in config file kebab-case like cmdline * refactor: fix typos in test names * codestyle: calm clippy in cmdline tests * Remove unneccessary flush command * Add a ringbuffer struct * Convert grid to use ringbuffer * Implement clone_from_iter for the RingBuffer * Make scrollback_lines use RingBuffer * Convert actual_lines to RingBuffer * Add iter_range to RingBuffer * Clean up the code using iter_range * Add size_hint to RingBuffer iterator * fix: Improve windows creation and sizing (#2027) * Move the window reposition code from WindowWrapper to creation * Handle columns and lines options * Create the window with the correct size at startup * Support the geometry parameter * Support setting lines and columns from init.lua/vim * Fix the neovide channel id * Split window creation and main loop * Don't show the window until the final size is determined * Improve the logging * Make the code easier to read * Set neovide_channel_id on all platforms * Cleanup the grid size calculation * docs: add unreleased yet note * Fix new clippy warnings from rust 1.72 * Fix clippy warnings * Try to position the floating windows inside the grid * Reposition to messages inside the window * Make sure that a redraw is performed when a floating window is moved * Fix windows positioning with padding * Refactor window padding (store it only once) * Fix some problems with the padding Ensure that it's always dynamically calculated. Also fix some cases where it was calculated wrong. * Update to Winit 0.29 master (#2035) * Update dependencies Winit master 0.29.1-beta#2422ea39d0e97fd43698391f84d9300cd169d8cd Glutin 0.4.1-beta * Fix winit breaking changes * Do a clean exit, correctly waiting for Neovim to shut down * Call neovide.quit at VimLeavePre instead of VimLeave This is recommended here neovim/neovim#7727 (comment). But I don't think it has any practical difference, other than perhaps slightly speed up the exit process. * Fix macOS build * Use winit throttling on Wayland instead of a custom solution Also always redraw on RedrawRequested. This fixes the windows not getting updated when moved in from off-screen for example. * Fix clippy warnings * Split neovim bridge into launch and attach phases This makes it possible to create the window with the correct size after it's launched, and ginit.vim/lua is processed. * codestyle: use explicit Arc::clone --------- Co-authored-by: MultisampledNight <[email protected]> * Show the window on any grid line modification and WinViewport * Remove UIReady callback * Ensure that the IME is updated * Group geometry related command line settings and update documentation * Support resizing the window using --geometry Both with a size from the command line and reading the size from init.vim/lua * Rename geometry to grid size * Fix cmd_line tests * Fix the unreleased yet tag that was lost during the rebase * Move initial setup to lua (#2062) This cleans up the code and makes it slightly faster * fix: Fix some crashes that can happen during exit (#2076) * Basic structure for handling errors at startup * Special case for clap errors * Change the startup order a bit to support building an error window * Move startup error handling to error_handling.rs * Create an error window But it still does not draw anything * Simple error text drawing * More complex error window with scrolling * Support copying to clipboard * Add help text * Use target_os instead of cfg(target) and install textlayout For some reason cfg(target) seemed to use the wrong configuration on WSL in some cases. It also seemed to not work when specified only for skia, so now skia is has been move to the same location as other Os dependent dependencies. Also make sure that textlayout is installed on all platforms, from packages with binaries. * Refactor the help message * Cleanup the code * Handle mouse scroll * Set default and minimum size * Return errors from command.rs * Handle launch errors * Enable backtraces * Report errors from nvim_attach The launch and attach functions are now combined, since there's no need to keep them splitted after some re-organization that was done. * Report errors during setup of the neovim state * Report errors when reading and setting the initial setting values * Log the error messages * Fix the tests * Use gl and textlayout for Skia on all platforms Egl, X11 and Wayland are not needed in our use cases. * Cleanup and fix error reporting Errors from Neovide were not reported correctly. * Fix clippy warning * Clean up the error window rendering Don't call layout twice * Move maybe_disown to just after command-line parsing It's not safe to fork after threads have been created, but it still feels more natural to output command line help in the terminal than in a separate window, so it's delayed a little bit. The starting of the profiler is also moved to after the fork, because it creates threads. * Properly fork the process on Linux and Mac On Windows the subsystem is set to Windows, so no console is created. The errors are always reported through the GUI. * Fix exit crash on Windows * Fix mixed min and default size * Improve the crash message * Don't panic when the event aggregator channel is closed. Closing is a normal behaviour during shutdown, and those are the only possible errors, so the error can safely be ignored. * Don't panic on ParallelCommand errors Instead log the errors to the logfile * Don't panic when the serial and parallel send loops exit in the wrong order * Don't panic on serial command failures * Fix confirm quit Neovim might exit before the response is received, so ignore all errors * Revert "Properly fork the process on Linux and Mac" This reverts commit 8ecc899. * Don't detach/attach to the console on Windows * Update to winit 0.29.2 --------- Co-authored-by: Fred Sundvik <[email protected]> Co-authored-by: MultisampledNight <[email protected]>
crupest
pushed a commit
to crupest/neovide
that referenced
this issue
Nov 4, 2023
The default event loop on winit, at least on Windows is too slow. See rust-windowing/winit#2782
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Winit is currently flooding the Windows event queue with
WM_PAINTmessages. Furthermore the main loop is always blocking withGetMessage, waiting for eitherWM_PAINTor another message to appear.This can cause long gaps between frames, event when
ControlFlow::Pollis used. For example take a look at the following captureHere there was 3.89 ms between two calls with
MainEventsCleared, almost half the frame budget when rendering at 120 FPS, causing a missed vsync here. Note that my loop is called two times in between with some other event, so this is not even a worst case, if there are multiple events, then the delay could be even longer.The main loop should never block, normally you use
PeekMessagein a non-blocking loop on Windows, or completely decouple the rendering from the event loop.Due to this I'm forced to take the second appoach and use a separate loop for the rendering, but because the events takes a timeline it's quite invonvenient #1387 to pass the events to my rendering thread.
You could perhaps use some use event to singal a new pass of the loops, but polling with
PeekMessageshould be preferred.WM_PAINTindirectly thoughRedrawWindowis really bad, because it has a very special meaning to the operating system, and probably forces a lot of interna stuff related to the window to be updated, in addition to posting the even.Note there are a few issues I found releated to this, but not exactly the same
#2698 - Not directly related, but decoupling the loop from
WM_PAINTshould fix the issue#2367 - This is mostly the same issue, the flooding of
WM_PAINT, which is increadible slow causes other events to be delayed#2287 - However, my timings on Windows 11 are much, much worse than what's reported there
The TLDR; for my suggestion is:
RedrawWindowunless the user explicitly requests itControlFlow::Poll, if there are no new eventsMainEventsClearedshould just be returned again.The text was updated successfully, but these errors were encountered: