-
Notifications
You must be signed in to change notification settings - Fork 48
Please help test smooth window resizing logic #19
Comments
Windows 7, nVidia GTX 1070, 1080p, no dpi scaling. Edit: also might be handy to know: i7-2600K (at stock speed). Frame times appear to be consistently in the range of 16.0ms-17.5ms. It rapidly flips back and forth. There's definitely a 0.5ms in there, but I'm not sure if it's 16.5 or 17.5. The spinner appears to turn smoothly. The situation is unchanged with a maximised window. One oddity I noticed when maximised: the window appears to be inset by one or two pixels on the left, right, and bottom. What I mean by that is that I can see the non-client window border around the edge of the screen. I have to move the cursor in by two pixels to get the "text selection" cursor to appear. Checking with an Explorer window confirms this is not normal. Clicking on this border doesn't appear to do anything save focus the window, and the window buttons indicate the window is maximised, so... I dunno. 's weird. Resizing from the left toward the right is mostly smooth; the diagonal line will sometimes "jump". It appears to be the top-right vertex moving to the right, outside the bounds of the client area. However, this glitch is inconsistent and doesn't appear on every frame. Resizing from the left toward the left leaves behind a white gap on the left of the window. It also exhibits the same inconsistent jumping of the diagonal line, except that now it jumps to the left, and leaves a horizontal line segment from the jumped-to position, across to the actual top-right corner of the window. Looking at the text, it doesn't appear to be smearing (i.e. stretching the right-most column of pixels from the existing bitmap), but I'm not sure. It's hard to tell at 60Hz. Also, to clarify: the white gap on the left appears to consistently be the difference in the client window rect between frames. The diagonal line does not appear to have the same behaviour. I can try to record a video of this in action if that will help. |
Windows 10, GTX 1080, 1440p @ 144Hz, no DPI scaling. Commit 8e306fd. Frame time alters between 6.0ms and 7.0ms, which is right on target for my display. Spinner runs smoothly, unchanged at full screen. It is using 3.5% of my 8C/16T CPU, which seems a little excessive, reasonable if you're invalidating a lot of the window. Dragging the left side of the window feels perfect, with no stutter or desync from my mouse cursor.
|
Win 7, 2x NVIDIA GeForce GTX 550 Ti, 2560x1080 Default size or nearly-full: 16.0 or 17.0ms/frame (never saw .5). Consistently smooth. Resizing at any height: ok, though some judder. Seems to gets a bit further from the top right widening compared to narrowing. Note that |
Windows 7 - Intel HD Graphics 4600 -1680*1050
|
Windows 10, Intel HD 520, Surface PRO 4, external display 1440p with normal DPI and no scaling I only checked on the current master branch.
|
Windows 10, GTX 1080 Ti, 1440p@60hz, no DPI scaling. No visual issues on However the frame-time for On Interestingly enough, minimizing the window actually causes the highest CPU usage of all on the Switching back to |
Windows 10, GTX 1050, 1080@60hz, no DPI scaling Everything seems smooth and comparable on both branches. On On |
Win 10, Intel(R) Xeon(R) CPU E3-1271 v3 @3.6GHz, NVIDIA Quadro K620 (1x display port -> display port hub -> 3 DVI monitors @ 1920x1080)
As @DanielKeep mentioned the border seems to be offset by a couple pixels. This is most noticeable when the application is maximized. It can also be detected when the window is not maximized. Note that the point becomes the drag icon a few pixels outside the border instead of when directly on the edge. |
idle (#18) branch
flip_hwnd branch
Basically 0 issues for me, window seems to run perfectly with no visual problems |
Windows 10 1803 (insider build 17133.73), GT 620, 1920 x 1080 @60Hz.
On resizing
|
master:
idle branch:
flip_hwnd branch:
|
On both CPU usage is ~2% when idle, ~2.3% when constantly resizing back and forth horizontally, ~2.7% diagonally. |
Device Eve V 2 in 1
Yes
Yes
Yes
Yes
Smooth
Stays glued to right corner. flip_hwndSame results. |
Windows 10, Nvidia GTX 770, 1920x1080@120Hz, 100% DPI scaling.
Yes.
It's either steady at 8ms or jumps between 8ms and 15-16ms.
Yes.
Yes.
Smooth.
It stays glued to the upper right corner. Same results with the |
Windows 10 Pro x64, Nvidia GTX 1080ti, 2560x1440@144hz, 100% DPI scale
Yes
~6.9-7.0ms which is right on for 144hz.
Yes
Yes
Smooth
Stays glued to right corner. Windows 10 Pro x64, Nvidia GTX 1080ti, 3140x2160@60hz, 125% DPI scale
Yes
Yes
Yes
Yes
The left side is smooth. The right side of the window janks and moves around by a pixel or 2 while the left is moving. It's all smooth on the
Stays glued to right corner. Also, the text looks a bit blurry on the 4k due to the 125% DPI. Not as smooth as text in a browser window on the same monitor. |
Thanks all! These results are encouraging enough I feel like I can move forward with the flip+hwnd hybrid approach. One of the main remaining problems, aside from cleanup, is making it load optionally, to preserve Windows 7 compatibility. I'm still interested in whether there's a better approach, but if there is one it's neither easy to figure out or already known to Windows developers. The extra window border when maximized is because I had WS_EX_OVERLAPPEDWINDOW, removed in #20. Thanks for pointing it out. The blurry text at 125% is because it's using system rather than per-monitor dpi. I have an experiment where I got per-monitor dpi working, but haven't merged it into xi-win yet. It's fairly tricky, generally they want you to put the dpi capabilities in the manifest, but I don't have one yet. Also, I'm not sure it's straightforward to include a manifest in example binaries, so for this it might be better to do it in code. |
Windows 10 17133.73, Intel HD Graphics 520 & Nvidia GTX 960M, UHD resolution (3840x2160@60Hz), 175% scaling.
On the master branch: Frame rate is 60 FPS when the window is not too big, but drops to 30 FPS when the window is nearly full screen. On the flip_hwnd branch: Frame rate is stable at 60 FPS, regardless of window size.
Everything is super smooth when resizing on both branches. The window only flickers when being maximized from a small size. |
Eager testers might want to check out #21, which is a cleaned up version. It should work on Windows 7 (using the hwnd approach only). Overall I expect it to perform pretty similarly, maybe a bit better (I removed some stray present operations that weren't needed when sizing). |
Hi! Since this PR, the window resizing is really super smooth but there is a "bug" when i maximized with the windows button. We have to type on the keyboard for a return to normal colors. I'm pretty sure it was not like that in before ! With last commits since today on master. My configuration :
Yes, 16-17ms, and when i resize it seems to get down to 9ms (very fast!).
Same think as before.
Yes.
So smooth !
It stay glued. Otherwise, it's an amazing work! I'm super happy to see this project growing up. |
On maximize (as opposed to drag resize), the new size is drawn inside the WM_SIZE handler. The application's draw logic needs to have the correct size, which means calling its size method before the render. Cleanup for issue reported in #19
As I've described in #17, I'm trying to figure out how to get good performance on resizing and also scrolling. It turns out to be quite tricky. I have a couple of approaches, and I'm trying to collect data on how close either is to being acceptable. Please test on your hardware and respond as a comment.
All testers
Let me know OS version, graphics card, monitor size, DPI scaling. Please test master (or #18, if that hasn't been merged yet). The test procedure is:
Does the spinner spin smoothly? Does the frame interval hold steady at 16-17ms? Does it still perform well if the window is nearly fullscreen?
Grab the left side of the window and resize. Does the window frame track the mouse? Is it smooth or is there jank? Does the diagonal line stay glued to the upper right corner or does it judder?
Don't worry too much about the spinning when resizing - for some reason it can get stuck when starting a move gesture. I also don't expect the frame interval to be consistent while resizing, though smoother is better.
Windows 8.1 and higher
Also try the
flip_hwnd
branch. Master just uses hwnd render targets, but flip_hwnd uses a more sophisticated approach. In steady state, it uses DXGI swap chains (in the FLIP_SEQUENTIAL swap effect). However, flip presentation is not synchronized with window resize, so it switches to hwnd when resizing, then back to flip.Do
git checkout flip_hwnd
then the same tests as above. Is there flashing or any artifact when entering and exiting sizing? Is performance roughly comparable?Multiple monitors / multiple GPUs
My main laptop is a Gigabyte Aero 14, which has integrated HD 630 and a GTX 1060 in an Optimus configuration. The laptop display is connected to integrated graphics, and the external monitor to discrete. It matters which GPU is selected (which is generally the "make this my main display" in display settings); performance is always degraded when crossing between the two.
Based on testing, I think I always want to draw with discrete graphics, at least in flip mode (in hwnd mode I don't seem to have the choice). How is performance affected when "make this my main display" is selected?
Higher frame rate monitors are also trickier? Does the frame interval hold steady at the faster rate?
Thanks in advance to the testers!
The text was updated successfully, but these errors were encountered: