lag

[ethugbaby]

there is significant lag while moving the window when the vibrancy is enabled

[YuhangQ]

me too!

[seo-rii]

What version are you using?
If version is less than v0.3.0, then please upgrade the module to v0.3.0. Version 0.3.0 changed option for processing acrylic effect, so it got faster.

[xanderfrangos]

This is a known issue with using Acrylic with Electron:
EYHN/vscode-vibrancy#5

It appears to be related to the mouse polling rate on the user's PC. I've tried to work around it with no success. If you have a dragable or resizable window, you'll run into lag.

[xanderfrangos]

One possible workaround would be to replace the move/resize functionality in Electron with one that only updates at the refresh rate of the display.

[ethugbaby]

@seo-rii this is the version im using "electron-acrylic-window": "^0.3.0", i had the old version in a different project and that didnt lag

[seo-rii]

@ethugbaby Could you tell me the Windows version? (Containing build number)

[seo-rii]

@xanderfrangos Yes, there was some lag on this module since using blur option as ACCENT_ENABLE_ACRYLIC, as same as the module that you mentioned. But since v0.3.0, It changed method into ACCENT_ENABLE_ACRYLICBLURBEHIND, which option added from RS4, and in my case(Windows 10 20h1, build 19041), there isn't any lag. But I couldn't test it on other windows version like 19h1, which can act differently with my case.

[ethugbaby]

@seo-rii windows 10 v1903 (OS Build 18362.959)

[fearganni]

@seo-rii I appreciate you putting this update out to use the acrylic blur versus the blurbehind, however, I am also experiencing the same lag on version 20H2.

It occurs when dragging the window around the screen, and also resizing the window. Please let me know if there's any more information i can provide you :)

EDIT: I am not experiencing the lag that @xanderfrangos was mentioning. My lag is like, a delay. I move the window and then like a second later it actually moves.

[xanderfrangos]

@FearGannicus Do you mind trying this test app and letting me know if it lags when you move/resize it?
https://1drv.ms/u/s!AiWKFpjcSKRQhdMmVpFThY7oEW8MJQ?e=foxppB

Extract and run Blur Test.exe

[seo-rii]

@FearGannicus When I tested it again, there was a slight lag when I resized the window. However, this was not the case when moving the window.

[fearganni]

@FearGannicus Do you mind trying this test app and letting me know if it lags when you move/resize it?
https://1drv.ms/u/s!AiWKFpjcSKRQhdMmVpFThY7oEW8MJQ?e=foxppB

Extract and run Blur Test.exe

Feel free to link me the source code, I'm not trying to run any exe file that I don't know what it does haha.

@FearGannicus When I tested it again, there was a slight lag when I resized the window. However, this was not the case when moving the window.

Very odd, I haven't yet tested on my desktop. Currently on my laptop. Would providing more specs for you help? This is a pretty beefy laptop. It's hard to explain what is really happening. I move the window with my mouse but it feels super delayed, same issue when I resize. it's smooth, not choppy. just super super delayed for some reason.

[xanderfrangos]

@FearGannicus Sure: https://github.com/xanderfrangos/electron-acrylic-window/tree/electron-builder-test
If you're concerned about the executable, just run npm i and npm run test. It's the same thing, just not in an Electron Builder package.

[fearganni]

@FearGannicus Sure: https://github.com/xanderfrangos/electron-acrylic-window/tree/electron-builder-test
If you're concerned about the executable, just run npm i and npm run test. It's the same thing, just not in an Electron Builder package.

@xanderfrangos Alright, it fixed the delayed lag i was expieriencing, however, now it looks a lot choppier, not as smooth as other applications.

EDIT: I just looked at your pull request and see the choppiness for me must have something todo with you setting the polling rate:

const pollingRate = 59.997 // TO-DO: Detect the current monitor's refresh rate

Is there currently no way of getting the current monitors refresh rate?

Just for a reference here's the specs of my laptop;

[xanderfrangos]

@FearGannicus Thanks for testing it out. That confirms that the mouse polling rate is the problem. I'm guessing your mouse or trackpad is polling at 500Hz or 1000Hz. The choppiness you're seeing is because the window is only moving at 60Hz. If in index.js you change pollingRate to 240 instead of 59.997, the window should move smoothly.

[fearganni]

@FearGannicus Thanks for testing it out. That confirms that the mouse polling rate is the problem. I'm guessing your mouse or trackpad is polling at 500Hz or 1000Hz. The choppiness you're seeing is because the window is only moving at 60Hz. If in index.js you change pollingRate to 240 instead of 59.997, the window should move smoothly.

I will test that out now to confirm, but def looks like you are on the right track. Is there a way for us to detect the monitors refresh rate in node/electron?

edit: changed the pollingRate to 240 and now its completely smooth, no lag or choppiness when moving the window. However, the lag still exists when resizing the window.

[xanderfrangos]

Electron exposes everything but the refresh rate, unfortunately. I'm not aware of any public Node modules that can do what is needed either, but I'll see if my friend @djsweet would like to help. He has an unpublished Node module that can detect the refresh rate of each display.

[fearganni]

@xanderfrangos Hmm... it's a shame that sometimes we are so limited in what electron can offer us. Hopefully this becomes offered in the future.

I don't know about getting each monitor or a speific monitors refresh rate, but I just saw this node module: https://github.com/Richienb/refresh-rate

Perhaps there's something we can see from there, that could help us.

[seo-rii]

I found another module to get frame rate. https://github.com/sebhildebrandt/systeminformation
This is not to calculate the frame rate, but to get information from the system, so it seems to be more accurate.
You can test it by :
si.graphics().then(data => console.log(data['displays'][0]['currentRefreshRate']))
+There's been a lot of discussion while I was away! I may not be able to check this discussion often because I have something outside of programming these days. I'm really sorry about this.

[fearganni]

@seo-rii no worries, I feel as though we can try our best to assist you with fixes, and testing.

edit: after checking out that systeminformation module, i don't seem to get a refresh rate in the callback.

{
  controllers: [
    {
      vendor: 'Intel Corporation',
      model: 'Intel(R) UHD Graphics',
      bus: 'PCI',
      vram: 1024,
      vramDynamic: true
    },
    {
      vendor: 'NVIDIA',
      model: 'NVIDIA GeForce RTX 2080 Super',
      bus: 'PCI',
      vram: 4095,
      vramDynamic: true
    }
  ],
  displays: [
    {
      vendor: '(Standard monitor types)',
      model: 'Generic PnP Monitor',
      main: true,
      builtin: true,
      connection: 'INTERNAL',
      resolutionx: 1920,
      resolutiony: 1080,
      sizex: 38,
      sizey: 21,
      pixeldepth: '32',
      currentResX: 1920,
      currentResY: 1080,
      positionX: 0,
      positionY: 0
    },
    {
      vendor: '',
      model: '',
      main: false,
      builtin: false,
      connection: 'DVI',
      resolutionx: 1680,
      resolutiony: 1050,
      sizex: 47,
      sizey: 30,
      pixeldepth: '32',
      currentResX: 1680,
      currentResY: 1050,
      positionX: 1920,
      positionY: 0
    }
  ]
}

[seo-rii]

Then I think the best way is to use the https://github.com/Richienb/refresh-rate module you just mentioned.

[seo-rii]

@FearGannicus I tested with https://github.com/Richienb/refresh-rate, but it does not works well. I'm using 144hz monitor, but it returns 60.

[fearganni]

@FearGannicus I tested with https://github.com/Richienb/refresh-rate, but it does not works well. I'm using 144hz monitor, but it returns 60.

hmm... maybe the best way is to make a cpp module?

edit: I don't know too much about making cpp modules, but maybe this will be some help? dmDisplayFrequency
https://docs.microsoft.com/en-gb/windows/win32/api/winuser/nf-winuser-enumdisplaysettingsa?redirectedfrom=MSDN

[seo-rii]

@FearGannicus So then, I'll make new module to get frame rate from monitor.

[djsweet]

@seo-rii @xanderfrangos pinged me about my unreleased refresh rate detection. I've cleaned it up and made it available as win32-displayconfig. Unfortunately, integration isn't exactly trivial.

@FearGannicus I've been working on an integration attempt at https://github.com/djsweet/electron-acrylic-window/tree/handle-polling-rate-based-on-refresh-rate, running into tons of Electron bugs along the way. Maybe it'll be OK performance-wise for you.

[seo-rii]

Thank you @djsweat! In fact, I made a module that gets frame rate, but I couldn't use it because there were some problems in a few cases. And there was this amazing module.

[fearganni]

@djsweet - ran a test of your project here is what i found.

Moving windows around;

• When the test app opens up on my main monitor (240Hz), runs nicely (a little choppy still but i can tell its not 60fps)
• However, when I drag the test app over to a secondary or connected monitor at a different refresh rate (e.g. 60Hz) I find it's super choppy and looks like 30fps.

Resizing windows;

• feels absolutely super delayed and laggy for me on both monitors

[djsweet]

@FearGannicus What commit did you test?

7e19b0e clamps resizing to 60Hz regardless of the refresh rate. We simply weren't able to get it to perform well on 4K displays with Windows-level transparency effects on otherwise.

98e8436 resets timers before actually attempting to set movement bounds (like so many operations in the Windows API, it's a surprise blocking operation) so you get closer to the actual refresh rate vs the refresh rate, waiting for the function to return, and then allowing movement to happen again.

[fearganni]

Oh shoot! Maybe I was running the wrong version @djsweet.
I've just ran the branch handle-polling-rate-based-on-refresh-rate and things seem much smoother on both monitors!

[seo-rii]

In recently commit(a62ff26), I applied patch that sets mouse polling rate based on frame rate of the monitor. This modification has been applied to v0.3.2.
Unfortunately, this upgrade did slightly reduce the lag, but it didn't completely eliminate it. I'm looking for another optimization method, but if you also have a good idea, let me know.

[xanderfrangos]

@seo-rii I believe the handle-polling-rate-based-on-refresh-rate branch has been fixed up and is ready to go. I worked with @djsweet quite a bit on it. He simply hasn't had a chance to open a PR.

[fearganni]

@seo-rii From the testing that I did, and as @xanderfrangos said, the handle-polling-rate-based-on-refresh-rate branch created by @djsweet seemed to do the trick.

[seo-rii]

In fact, the version I made works on the same principle. One problem is that it's not tested in a multi-window environment, and it's a little unstable. I believe @djsweat solved this problem. If you don't mind, can you tell me when you will send the PR? I'm about to port this module in typescript soon, because I want to keep all the issues in place before that.

[xanderfrangos]

@seo-rii I'll try to merge the branch @djsweet made with your latest code later today. His branch properly handles multi-monitor setups with different refresh rates and includes several smaller fixes (ex. Aero Snap, maximizing/unmaximizing, resizing), so it's important to get merged.

[seo-rii]

@djsweet @xanderfrangos The PR you put in contained really good modifications, but there is one serious bug. The aero effect of dragging the window to the end of the corner to fill half or a quarter of the screen does not work.

[xanderfrangos]

@seo-rii Good catch! Fix is here: #20

[seo-rii]

I found one more bug. Moving the window very slowly (especially when moving up or left) changes the size of the window.

[xanderfrangos]

I should have a better fix tomorrow that doesn't have that issue. Then hopefully we can be done with this "lag" issue. 😅

[xanderfrangos]

@seo-rii Sorry for the delay! New fix is available here.

[seo-rii]

Perfect! This patch will be applied to v0.4.0. The long-standing problem has been solved. Thank you all!