Slow performance in macOS
Closed this issue · 8 comments
Describe the bug
I'm not sure if this is a bug...
When I connect to my mac with noVNC it is way too slow.
To Reproduce
Just connect to macOS.
Expected behavior
When connecting to window OS, it works perfectly without lagging.
Only slow on macOS.
Client (please complete the following information):
- OS: [e.g. iOS]
- Browser: Chrome
- Browser version: 85.0.4183.102
Server (please complete the following information):
- noVNC version: 1.2.0
- VNC server: macOS buildin VNC
- WebSocket proxy: websockify
Additional context
Is there any way to make this faster for macOS?
Could you explain this slow-ness? Does the initial connection take a long time? Does the mouse cursor lag behind when moving it? Is the screen updated too slowly when watching a video?
Can confirm that with the recent Chrome 85 update the rendering started to become slower and fonts get blurry at times, especially if there are many moving animations in the vnc stream (tested on macOS, did not happen in Firefox so far).
the update of the screen is slow. i have no program running on my mac and when just trying to connect to it the log in screen pop up in like 30 seconds and everything i do shows up in after like 5~10 seconds.. i don't think this is a problem with my network speed..
I tested both macOS 10.15.6 and the macOS 11 beta (Big Sur) as clients here. I used Chrome 85, Firefox 80, Safari 14, and Safari 13.1 (on macOS 10.15). I connected from the macOS machines to a Linux machine running a TigerVNC server.
It seems to work well for me, I can't see any performance issues. I did not try macOS's built-in VNC server.
When connecting to window OS, it works perfectly without lagging.
I assume you mean you connected to a different VNC server on a Windows machine here?
This seems to indicate that the problem lies with macOS's VNC server, and that it isn't a noVNC problem. I'm surprised you managed to connect at all, to be honest, we haven't had the best experience with their VNC server in the past.
To verify that this is a server issue you should try a different VNC viewer and see if you are having performance issues with that as well.
@samhed, I'm experiencing what I think are issues similar to those of @holamisa. One in particular being that when connecting to a macOS 10.15.7 system (with either "Screen Sharing" or "Remote Management" enabled) using noVNC, a dot cursor is displayed (that in some cases reverts to a normal arrow cursor after some time - see below) in the MC2 console. I've been playing around with macOS settings and things seem to improve slightly when I've added "meshagent_osx64" to the allowed apps lists of "Accessibility" and "Full Disk Access" in "System Preferences | Security & Privacy | Privacy" AND if I've logged in with a macOS account with administrative rights and stop and restart "meshagent" (i.e. "sudo launchctl stop meshagent" then "sudo launchctl start meshagent"). After doing that, sometimes you'll have an arrow cursor that behaves normally or that changes to a dot cursor when moved until the cursor hasn't been moved for a few moments and reverts to an arrow cursor; other times you might get an I-beam cursor or a double-headed arrow (i.e. the cursor displayed when resizing a window by click-dragging a corner). I'll try experimenting with other VNC servers.
Could you test with a different VNC client? If it's slow with every client then I'm afraid there isn't anything we can do about it, as that just means the macOS server is slow (which is generally the case).
@CendioOssman and others, sorry, I must have been confused about which GitHub project I was posting to when I added my previous comment (thought I was posting to the MeshCentral2 project's "Issues"; MC2 uses noVNC to access macOS endpoints). FWIW I tested connecting directly to the same system using Remmina and don't have any issues with the cursor when the macOS endpoint is configured to use either "Screen Sharing" or "Remote Management". There does seem to be some slowness with Remmina - tolerable but a little frustrating.
The cursor issue is a known one unfortunately (see #1430). We don't have a workaround for that right now.
I'm going to go ahead and close this now as we're not getting any more updates from the original poster on the initial issue.