VirtualBox

Ticket #16436 (new defect)

Opened 3 years ago

Last modified 12 months ago

Lagging and long pauses in all guests on recent MacOS hosts

Reported by: pixelfairy Owned by:
Component: guest additions/x11/graphics Version: VirtualBox 5.1.14
Keywords: osx, linux Cc:
Guest type: Linux Host type: Mac OS X

Description (last modified by michael) (diff)

Developer update: this problem needs user investigation. See comment:108.

when using os x (10.12.2) as the host and linux guests, gui performance is ok, except for dragging or resizing windows within the gui. then it takes several seconds for the windows to move or resize following the drag event. drag and resize both seem a little faster horizontally and vertically. horizontal is sometimes almost at normal speed.

maximized apps (full screen) are not affected by this bug and will resize with the virtualbox window in both directions as fast as can be expected.

the only exception is ubuntu desktop, and only when guest extensions are installed. then performance is fine. gnome-desktop, in ubuntu, debian, or red-hat, still has the bug. all other desktops or window managers ive tried also show this bug, lxde, xfce, fvwm, and kde

windows and linux hosts are not affected.

to see the bug, just run a live installer like fedora, debian, or red hat. open an app window and try to drag it around. you can even run the mouse in loops or circles than sit back and watch the window follow its trail.

with debian and lxde, installing guest additions sometimes temporarily solves the issue, but then it spontaneously comes back.

mac is a late 2013 retina with hybrid intel/nvidia graphics.

Attachments

WinXP Pro-2017-02-12-16-09-40.log.zip Download (24.1 KB) - added by cs2015 3 years ago.
WinXP Pro-2017-01-01-11-05-49.log.zip Download (16.9 KB) - added by cs2015 3 years ago.
VBox.log Download (123.7 KB) - added by agodfrin 3 years ago.
VBOX Log: macOS 10.12.3 (16D32), vbox 5.1.16 r113841 (Qt5.6.2)
VirtualBoxVM_2017-03-13-152517_ironman.wakeups_resource.diag.gz Download (8.2 KB) - added by opcenter 3 years ago.
VirtualBox diagnostic report with spindump
DisableDockiconOverlay.png Download (213.5 KB) - added by DmitrG 2 years ago.
How to disable "Dock Icon" updates.
vm_Xubuntu-2018-08-01-21-32-51.log Download (138.5 KB) - added by danaussie 15 months ago.
vm_Xubuntu-2018-08-01-23-26-05.log.zip Download (25.6 KB) - added by danaussie 15 months ago.

Change History

comment:1 Changed 3 years ago by pixelfairy

meant to write "horizontal drag and resize events seem a little faster than vertical ones"

comment:2 Changed 3 years ago by lastal

Same thing happens with Windows guest too!!!

MacBook Pro (15-inch, 2016), VirtualBox version 5.1.14, Mac OSX 10.12.3, Windows XP SP2

comment:3 Changed 3 years ago by cs2015

Also seeing the same problem with a Windows guest. Very slow sluggish stuttering movement when moving or resizing windows on screen within guest. Reverting to 5.0.30 doesn't have this issue.

iMac 3.06GHz Core 2 Duo (500GB SSD, 8GB RAM) Virtualbox 5.1.X (Any version starting 5.1 has this problem) MacOS Sierra 10.12.3 Win XP Pro SP3 guest

Last edited 3 years ago by cs2015 (previous) (diff)

Changed 3 years ago by cs2015

Changed 3 years ago by cs2015

comment:4 Changed 3 years ago by cs2015

Just found another log file from when I was running 5.1. Have attached this too.

comment:5 Changed 3 years ago by jsdev

I have this issue too, although not several seconds behind. More like 0.25 to 0.5 seconds.

comment:6 Changed 3 years ago by DmitrG

The discussed issue is NOT reproduced on the following configuration without hybrid graphics:

MacBook Pro Retina 15inch 2880x1800 Late 2013
OSX 10.12.3 Sierra
Graphics: Intel Iris Pro (DEV_ID 0x0d26, REV_ID 0x0008)

I suspect that the issue is reproduced only if hybrid graphics is enabled. Could you please recheck that by forcing hybrid graphics to OFF in power management settings ?

comment:7 follow-up: ↓ 8 Changed 3 years ago by jsdev

Forcing it off did not help me.

comment:8 in reply to: ↑ 7 Changed 3 years ago by DmitrG

Replying to jsdev:

Forcing it off did not help me.

Did you follow Apple's instructions  https://support.apple.com/en-gb/HT202053 ?.

You should set "Automatic graphics switching" option to ON and put your MacBook to "Better battery life" mode - for example by unplugging AC jack. In such case all graphics will be performed by Intel GPU.
It also worth to check "Requires High Perf GPU" column in Activity monitor.

comment:9 Changed 3 years ago by harg

Same problem here :

Guest OS : Windows server 2008 R2

Host OS : OSX 10.12.2

Macbook Pro Retina 15inch Mid 2015
2,2Ghz Core I7
Intel Iris Pro (no discrete GPU)

comment:10 Changed 3 years ago by socratis

@harg: Since the original bug was opened for Linux guests, can you follow the original poster's suggestion and confirm that it is actually the same bug in the OSX host and not something in the Guest Additions?

To see the bug, just run a Live installer like Fedora, Debian, or Red Hat. Open an app window and try to drag it around. You can even run the mouse in loops or circles than sit back and watch the window follow its trail.

comment:11 Changed 3 years ago by DmitrG

@harg: Please also confirm that the problem appears both in case of "3D acceleration" enabled and in case of "3D acceleration" disabled.

comment:12 Changed 3 years ago by harg

"3D acceleration" disabled has no effect, the bug is still here.

Virtual Box 5.1.14 r112924 Guest OS : Windows server 2008 R2 Host OS : OSX 10.12.2

I tried Debian 8 live (cinnamon), it looks fine. The display is a bit laggy but i think this is due to the lack of hardware acceleration (no guest additions).

comment:13 Changed 3 years ago by opcenter

I've been seeing the same thing.

Guest OSs I've tried and see it: Ubuntu Linux 16.04, Oracle Linux 7, Debian Linux 8 - it's most obvious in XFCE, slightly less obvious in Gnome, Cinnamon

I can specifically see that it's the mouse reporting that's lagging behind because when I disable and then re-enable mouse integration, I can see the host's mouse cursor moving as I move the mouse and guest's cursor lagging way behind. I've tried different choices for the mouse type in the VM settings (USB Tablet, USB Multitouch Tablet, PS/2 Mouse) with no difference. 3D acceleration on/off doesn't make any difference.

Host OS: macOS Sierra 10.12.3

MacBook Pro Retina 13" Late 2013 2.6 GHz Core i5, 16 GB, Intel Iris

VirtualBox 5.1.14

Update: I tried downgrading to 5.0.32 and saw the same mouse lag. Sounds like something is broken on the macOS side. :(

Last edited 3 years ago by opcenter (previous) (diff)

comment:14 Changed 3 years ago by Lou P

Hi,

This is a "me too" for this issue. The graphics perform *much* better (albeit not extremely fast) with any 5.0.* version of VirtualBox. However, with any 5.1.* version of VirtualBox, the graphics is quite slow (e.g. moving a window across the screen is *very* slow and laggy), which renders the use of RedHat on VirtualBox extremely difficult and frustrating.

Please note that my configuration is the following: Apple MacBook Pro (15-inch, 2016) with 2.7GHz i7 processor with 16GB RAM and both Radeon Pro 455 (2GB) and Intel HD Graphics 530 (1.5GB) macOS Sierra version 10.12.3 on VirtualBox, I am running RedHat linux.

I did try the different suggestions that were pointed out here and there but nothing really made a difference.

Best regards and thank you for your help.

comment:15 follow-ups: ↓ 16 ↓ 17 Changed 3 years ago by DmitrG

Could someone collect OpenGL Profiler data in this way:

  1. Download OpenGL Profiler from  https://developer.apple.com/opengl/ (AppleID is required)
  2. Choose a VM with enabled "3D acceleration" and GA installed, start that VM
  3. Close all other VirtualBox clients including VirtualBoxManager
  4. Enable "Collect traces" in OpenGL Profiler and attach it to VirtualBox process
  5. Replay the drawing lag by moving a window inside VM during ~10 seconds
  6. Detach Profiler, export verbose trace data to a txt file, compress and share it

I'll try to compare duration of OpenGL API calls with my case when NO drawing lag happens  https://drive.google.com/file/d/0B0wjx9PlNhMuOW9fMllHeUZjbFU/view?usp=sharing

comment:16 in reply to: ↑ 15 Changed 3 years ago by opcenter

Replying to DmitrG:

Could someone collect OpenGL Profiler data in this way:

  1. Download OpenGL Profiler from  https://developer.apple.com/opengl/ (AppleID is required)
  2. Choose a VM with enabled "3D acceleration" and GA installed, start that VM
  3. Close all other VirtualBox clients including VirtualBoxManager
  4. Enable "Collect traces" in OpenGL Profiler and attach it to VirtualBox process

I gave this a try on two different macs and unfortunately VirtualBox crashed after I attached, so I wasn't able to collect any data:

  1. 13" Retina MacBook Pro Late 2013 -
  2. 15" Retina MacBook Pro Late 2013 (w/nvidia GPU)

Any ideas?

comment:17 in reply to: ↑ 15 ; follow-up: ↓ 18 Changed 3 years ago by Lou P

Replying to DmitrG:

Could someone collect OpenGL Profiler data in this way:

  1. Download OpenGL Profiler from  https://developer.apple.com/opengl/ (AppleID is required)
  2. Choose a VM with enabled "3D acceleration" and GA installed, start that VM
  3. Close all other VirtualBox clients including VirtualBoxManager
  4. Enable "Collect traces" in OpenGL Profiler and attach it to VirtualBox process

My VirtualBox (running RedHat) also dies as soon as I click on "attach" in OpenGL Profiler. Note that I am currently running 5.0.34 and I was going to collect traces for both 5.0.34 and then to 5.1.* after installing it (again). So the crash occurred on 5.0.34. I am guessing that opcenter witnessed the crash on a 5.1.* version.

My two cents...

  1. Replay the drawing lag by moving a window inside VM during ~10 seconds
  2. Detach Profiler, export verbose trace data to a txt file, compress and share it

I'll try to compare duration of OpenGL API calls with my case when NO drawing lag happens  https://drive.google.com/file/d/0B0wjx9PlNhMuOW9fMllHeUZjbFU/view?usp=sharing

comment:18 in reply to: ↑ 17 Changed 3 years ago by opcenter

Replying to Lou P:

Replying to DmitrG: My VirtualBox (running RedHat) also dies as soon as I click on "attach" in OpenGL Profiler. Note that I am currently running 5.0.34 and I was going to collect traces for both 5.0.34 and then to 5.1.* after installing it (again). So the crash occurred on 5.0.34. I am guessing that opcenter witnessed the crash on a 5.1.* version.

Correct, I was on 5.1.16.

comment:19 follow-up: ↓ 20 Changed 3 years ago by DmitrG

Hi LouP and opcenter. Great thanks you for you quick responce.

That problem with OpenGL Profiler is well known and workaround is described here  https://forums.developer.apple.com/thread/70141.

Just try to connect to OpenGL Profiler 'remotely':

"The only way I found to use OpenGL Profiler on macOS 10.12 is to enable remote profiling from the preferences. (checkbox is disabled while you don't set a password) Once enabled, you can connect to it using another or the same machine".

I've checked that OpenGL profiler works fine in such 'remote' way.

Please, reproduce "windows motion lag" and attach or share verbose traces.

Thank you in advance!

comment:20 in reply to: ↑ 19 ; follow-up: ↓ 23 Changed 3 years ago by Lou P

Replying to DmitrG:

Just try to connect to OpenGL Profiler 'remotely':
Please, reproduce "windows motion lag" and attach or share verbose traces.

Hi,

I am not sure what I am doing wrong, but I am unable to see any traces and the frame rate always shows as "0.0 FPS" in the profiler main window, which I am guessing is wrong.

I went in the OpenGL Profiler's preferences, gave a name to the "Remote Profiling Name" and set a password for it, and checked the "Enable remote profiling" box. Then in the Profiler's main window, I checked the "attached to application" option and highlighted the running virtualbox line. Then, I checked "Collect trace" and clicked on "Attach". It did not kill my VB as before, and the status shows as "Running..." but the "Frame Rate" changes from "----- FPS" to "0.0 FPS" and nothing shows up in the trace window.

I am not familiar with OpenGL Profiler so not sure at all what is going on. Note that I am still running VB 5.0.34 but I would guess that the trace should show something for any version of VB.

Please let me know what to do...

Last edited 3 years ago by Lou P (previous) (diff)

comment:21 follow-up: ↓ 24 Changed 3 years ago by opcenter

Just to add another data point, I tried connecting my mouse as a USB device directly to the guest just to prove that it's likely something to do with the mouse integration and it worked perfectly. Of course that's not really a great way to work because then my mouse doesn't work in the host OS, but I thought it might be of interest.

I'm going to give the remote connect a try with OpenGL Profiler to see what happens.

Update: Remote connect still crashes VirtualBox. :(

Last edited 3 years ago by opcenter (previous) (diff)

comment:22 Changed 3 years ago by michael

@opcenter I agree, that does sound like a problem with pointer input. To me it does not sound like a pointer integration problem though: people have reported that it happens using Linux live installer images with no integration. My guess is that OS X is not providing the VirtualBox application on the host with frequent enough updates on the pointer position, and that when you pass through a USB mouse directly the problem goes away because it no longer goes through OS X (that is, only the USB packages have to go through OS X, and that is a very different code path).

To investigate that path (I am sure Dmitrii is still interested in the OpenGL Profiler information) you could try enabling additional logging as described in the wiki mouse debugging page<1> and looking at the output in the machine log file. You might also add the "msprog" release log flag<2> to get timing information in the log statements. (Feel free to submit patches to improve the wiki pages by the way! They were written by busy developers in-between.) People seeing this problem with X11 guests could also try xev logging in the guest.

  1. MouseInput
  2. VBoxLogging

comment:23 in reply to: ↑ 20 ; follow-up: ↓ 29 Changed 3 years ago by DmitrG

Replying to Lou P:

Replying to DmitrG:

Just try to connect to OpenGL Profiler 'remotely':
Please, reproduce "windows motion lag" and attach or share verbose traces.

Hi,

I am not sure what I am doing wrong, but I am unable to see any traces and the frame rate always shows as "0.0 FPS" in the profiler main window, which I am guessing is wrong.

I went in the OpenGL Profiler's preferences, gave a name to the "Remote Profiling Name" and set a password for it, and checked the "Enable remote profiling" box. Then in the Profiler's main window, I checked the "attached to application" option and highlighted the running virtualbox line. Then, I checked "Collect trace" and clicked on "Attach". It did not kill my VB as before, and the status shows as "Running..." but the "Frame Rate" changes from "----- FPS" to "0.0 FPS" and nothing shows up in the trace window.

I am not familiar with OpenGL Profiler so not sure at all what is going on. Note that I am still running VB 5.0.34 but I would guess that the trace should show something for any version of VB.

Please let me know what to do...

Hi Lou P. Everything was correct with OpenGL Profiler except the one step: select menu item File->Connect and choose the name of your 'remote' target (which is really your local Sierra).

But if attaching USB mouse directly to guest really eliminates the issue than OpenGL Profiler logs are not required! Instead, we should profile Mouse events delivery, I'll find a proper way to do it now.

Could you please confirm @opcenter results on your MacBook by attaching USB mouse directly to guest?

comment:24 in reply to: ↑ 21 Changed 3 years ago by DmitrG

Replying to opcenter:

Just to add another data point, I tried connecting my mouse as a USB device directly to the guest just to prove that it's likely something to do with the mouse integration and it worked perfectly. Of course that's not really a great way to work because then my mouse doesn't work in the host OS, but I thought it might be of interest.

I'm going to give the remote connect a try with OpenGL Profiler to see what happens.

Update: Remote connect still crashes VirtualBox. :(

Hi opcenter! Thank you for great idea.

Please confirm one more time that attaching USB mouse directly to guest completely cures the "window drag and resize slowly" problem.

comment:25 Changed 3 years ago by michael

And has anyone checked whether playing with VirtualBox and/or Retina scaling settings makes a difference? Warning: do not change Retina scaling settings while VirtualBox is running, it has been known to cause problems.

comment:26 Changed 3 years ago by opcenter

I've got some more info, though it's mostly anecdotal.

Direct connect USB for the mouse continues to bypass the issue, so it's definitely something about processing virtual mouse events (with one caveat that I will get to later).

I enabled logging from my guest for mouse events:

VBoxManage debugvm "<vm-name>" log --release "+e.l2.f+main.e.l3+dev_kbd.e.l3.f"

Logs end up in ~/VirtualBox VMs/<vm-name>/Logs.

When I tried dragging a window around it was obvious from how far behind the logs came in that processing the queued events was taking much longer than they were occurring. I took a look at CPU usage and both cores were pegged. So, I had an idea to only give the guest 1 CPU to help the host deal better with processing the event queue. My 13" MBP has 2 cores, so I switched the guest to 1 CPU and the mouse reporting seemed to keep up much better. I tried the same thing on my 15" MBP with 4 cores (went from 4 CPUs for the guest down to 2) and saw the same result. It isn't exactly smooth, but it's usable.

Another thing I remembered was that starting with OS X 10.9 (mavericks) I had issues with App Nap causing intermittent slow downs because it thinks that an app is not in the foreground, especially with VirtualBox, so I tried disabling that. Unfortunately it didn't seem to make any difference.

I'm usually running with external monitors. I have three different setups I use:

  • 1x 32" 4k display running at 2560x1440 unscaled on 13" MBP, scaled to something in between on 15" MBP
  • 1x 27" 2560x1440 display
  • 2x 23" 1920x1080 displays

The mouse lag gets really bad if I have multiple monitors connected and I move the guest VM display to the laptop display. I'm guessing this is overworking the CPU and GPU when it's dealing with the scaling. In that case, the direct connect USB for the mouse doesn't help a whole lot, everything is still really slow, but I think the extra slowdown is graphics related and the lagging mouse reporting is just making it seem even worse. This happens for both of my MBPs, it's only slightly better on the 15" because of the faster CPU and GPU.

As a general observation, OS X/macOS has performed worse for me every release since 10.9 on both of these systems. Based on what I've found it's possible there's little to nothing we can do from VirtualBox to make this any better.

Perhaps someone with more recent hardware can run some of the same tests to see what they find.

comment:27 follow-up: ↓ 28 Changed 3 years ago by agodfrin

I just switched yesterday from an older MacBook Pro (13-inch late 2011) with a 1280x800 display, to a newer model (13-inch, 2016) with a 2560 x 1600 Retina display (Intel Iris Graphics 540 1536 MB). macOS is 10.12.3 on both. Same version of VirtualBox (5.1.12 r112440 (Qt5.6.2)).

The first thing I noticed with all my Linux VMs is the strong sluggishness when dragging and moving windows around. Very annoying.

This does not happen on the older machine. I have both machines side by side, running the exact same environment (OS, VB, VMs). One is sluggish, the other works fine.

From what I see, the major difference (the only one ?) is the resolution of the MacBook display. Just as a test, I tried setting the VirtualBox app to use low-resolution (you can do that by doing a "Get Info" on the Virtual Box app in the Applications folder), but that did not make a noticeable difference.

I also tried using lower (and also higher resolutions) on the MacBook display. That also did not seem to have a noticeable effect ...

Last edited 3 years ago by agodfrin (previous) (diff)

comment:28 in reply to: ↑ 27 ; follow-up: ↓ 36 Changed 3 years ago by DmitrG

Replying to agodfrin:

I just switched yesterday from an older MacBook Pro (13-inch late 2011) with a 1280x800 display, to a newer model (13-inch, 2016) with a 2560 x 1600 Retina display (Intel Iris Graphics 540 1536 MB). macOS is 10.12.3 on both. Same version of VirtualBox (5.1.12 r112440 (Qt5.6.2)).

The first thing I noticed with all my Linux VMs is the strong sluggishness when dragging and moving windows around. Very annoying.

This does not happen on the older machine. I have both machines side by side, running the exact same environment (OS, VB, VMs). One is sluggish, the other works fine.

From what I see, the major difference (the only one ?) is the resolution of the MacBook display. Just as a test, I tried setting the VirtualBox app to use low-resolution (you can do that by doing a "Get Info" on the Virtual Box app in the Applications folder), but that did not make a noticeable difference.

I also tried using lower (and also higher resolutions) on the MacBook display. That also did not seem to have a noticeable effect ...

@agodfrin: thank you for the info.

Please clarify:

  1. Do you have "3D acceleration" enabled or not ?
  2. Try to assign less CPU cores to VM and recheck "strong sluggishness when dragging and moving windows around".

comment:29 in reply to: ↑ 23 Changed 3 years ago by Lou P

Replying to DmitrG:

Everything was correct with OpenGL Profiler except the one step: select menu item File->Connect and choose the name of your 'remote' target (which is really your local Sierra).

Yes, I had done the "connect" part but forgot to report it in my previous post (actually if I do not "connect" then the VB would crash). But unfortunately the frame rate is reporting as 0.0 and nothing is really traced.

If you have any other suggestion to get the trace to work, let me know and I will give it a try.

In any event, I will also try attaching a USB mouse and will let you know how that goes.

comment:30 follow-up: ↓ 31 Changed 3 years ago by Lou P

Hi again,

I just tried attaching a USB mouse but the problem persists with VB 5.1.*. Just note that I am on a 2016 MacBook Pro so my USB mouse is plugged in a USB-to-USBC adapter so that it can be plugged to the laptop. I guess I am downgrading again to 5.0.34 now!

comment:31 in reply to: ↑ 30 ; follow-up: ↓ 32 Changed 3 years ago by opcenter

Replying to Lou P:

Hi again,

I just tried attaching a USB mouse but the problem persists with VB 5.1.*. Just note that I am on a 2016 MacBook Pro so my USB mouse is plugged in a USB-to-USBC adapter so that it can be plugged to the laptop. I guess I am downgrading again to 5.0.34 now!

Just to clarify, when I said "direct USB connection" I assigned the USB mouse device to the VM directly in the VM settings to bypass the virtual device layer. Can you confirm that that's what you did? Thanks.

comment:32 in reply to: ↑ 31 ; follow-up: ↓ 33 Changed 3 years ago by Lou P

Replying to opcenter:

Replying to Lou P:

Hi again,

I just tried attaching a USB mouse but the problem persists with VB 5.1.*. Just note that I am on a 2016 MacBook Pro so my USB mouse is plugged in a USB-to-USBC adapter so that it can be plugged to the laptop. I guess I am downgrading again to 5.0.34 now!

Just to clarify, when I said "direct USB connection" I assigned the USB mouse device to the VM directly in the VM settings to bypass the virtual device layer. Can you confirm that that's what you did? Thanks.

No, I simply attached my mouse to the laptop before (through the USB-to-USBC adapter) and that did not make any difference with the slowness of window moves. However, now I am trying to follow your instructions but cannot figure them out. When you say to "assign the USB mouse directly to the guest VM", how do you do it exactly? I tried going under Settings, then "Ports", then USB and creating an empty filter (and I left all the entries empty), but nothing changed...

comment:33 in reply to: ↑ 32 ; follow-up: ↓ 34 Changed 3 years ago by socratis

Replying to Lou P:

I tried going under Settings, then "Ports", then USB and creating an empty filter (and I left all the entries empty), but nothing changed...


Follow the steps below:

  1. Make sure that the Extension Pack is installed on the host. The same version as VirtualBox.
  2. Make sure that at least USB2 (EHCI) is enabled in your VM settings.
  3. Under VM Settings » Port » USB, create a USB filter in your guest settings while the device is plugged in the host. Delete all the values except Name, VendorID and ProductID.
  4. Unplug the device.
  5. Start your guest (the one that you applied the filter to). Let it start completely. Log in if you have to.
  6. Plug your device. The filter should capture it and pass control to your guest.

comment:34 in reply to: ↑ 33 ; follow-up: ↓ 35 Changed 3 years ago by Lou P

Alright, now it worked with the external mouse! Thanks for the instructions. Just note that I had to turn off "mouse integration" otherwise the USB mouse was behaving strangely (it would allow me to click either left or right buttons but did not show the mouse pointer on the screen).

I will recap my configuration in case it can help you in debugging or help other users in temporarily overcoming this problem (or report their findings).

  1. Host: Apple 15" MacBook Pro 2016 with macOS 10.12.3.
  2. Very sluggish trackpad (and external USB mouse) on my guest RedHat Linux seen when guesting on VB 5.1.*. However no problem seen on VB 5.0.*. Note that my external USB mouse was connected to my Mac through a USB-to-USBC adapter.
  3. The turnaround to get it to work:
    1. Quit VB on macOS and install VB Extensions from VB's website.
    2. While guest is powered off, connect the external USB mouse, then run VB.
    3. Open the VB settings of the guest OS, click on "Ports", then "USB", make sure "Enable USB Controller" is turned on.
    4. Select either the 2.0 or 3.0 (EHCI or xHCI) controller.
    5. In the "USB Device Filters", click on the "add a new USB filter" icon and select the item corresponding to your USB mouse (and not the Apple iBridge entry).
    6. Double click on the entry you created, keep the "Name", "Vendor ID", and "Product ID" entries and delete all the rest.
    7. The bottom "Remote" entry should be set to "No".
    8. Close these windows to save and get back to the main VB window.
    9. Remove the mouse from the USB/USB-C port then start the guest OS in VB.
    10. Once the guest is running, plug in the USB/USB-C mouse.
    11. From the VB menu bar, open "Input" and disable the "Mouse Integration".
    12. The window dragging works fine now with the external USB mouse (although still slow with the built-in trackpad).

Thanks for all your help and I hope you can get to resolve this problem soon!

Last edited 3 years ago by Lou P (previous) (diff)

comment:35 in reply to: ↑ 34 ; follow-up: ↓ 37 Changed 3 years ago by socratis

Replying to Lou P:

@Lou P
You really don't have to quote the whole previous message just to repeat it again point-by-point, because your answer ends up being way more than a page and it really becomes difficult to read the whole discussion, especially if you're quoting the message just before yours, i.e. it's a direct reply.

If you want to quote specific parts, please quote specific parts. Like:

Very sluggish trackpad ... when guesting on VB 5.1.*. However no problem seen on VB 5.0.*.

Have you tested all the previous 5.0.x and 5.1.x versions? Because the problem started appearing (first mentioned) after 5.1.14, so if you saw it before 5.1.14, be exact to avoid the confusion. Especially for the developers that are trying to pinpoint the exact version where this started happening.

comment:36 in reply to: ↑ 28 Changed 3 years ago by agodfrin

Replying to DmitrG:

Replying to agodfrin:

I just switched yesterday from an older MacBook Pro (13-inch late 2011) with a 1280x800 display, to a newer model (13-inch, 2016) with a 2560 x 1600 Retina display (Intel Iris Graphics 540 1536 MB). macOS is 10.12.3 on both. Same version of VirtualBox (5.1.12 r112440 (Qt5.6.2)).

...

@agodfrin: thank you for the info.

Please clarify:

  1. Do you have "3D acceleration" enabled or not ?
  2. Try to assign less CPU cores to VM and recheck "strong sluggishness when dragging and moving windows around".
  1. No I don't have 3D acceleration enabled. I tried with and without and it did not make a difference
  2. CPU cores: the VM uses just one core.

To be on the same page as others, I also just upgraded to the latest VirtualBox [5.1.16 r113841 (Qt5.6.2)] complete with extensions and guest additions. Did not make any change. I am attaching the vbox.log file

CORRECTION: I had to revert back to guest additions 5.0.20. This is because later versions of guest additions no longer use full screen. I logged another ticket for that one: https://www.virtualbox.org/ticket/16347

Last edited 3 years ago by agodfrin (previous) (diff)

Changed 3 years ago by agodfrin

VBOX Log: macOS 10.12.3 (16D32), vbox 5.1.16 r113841 (Qt5.6.2)

comment:37 in reply to: ↑ 35 ; follow-up: ↓ 44 Changed 3 years ago by Lou P

Replying to socratis:

You really don't have to quote the whole previous message just to repeat it again point-by-point, because your answer ends up being

Thank you for the lesson; I wished it was delivered a bit softer though. I am just trying to help and am no expert at this. Trying to be useful, I repeated but added extra details to the point-by-point steps since they were a bit ambiguous and you may end up getting unreliable feedback from users in case they did not carefully follow all the steps.

Anyway, more importantly:

Have you tested all the previous 5.0.x and 5.1.x versions?

Yes, I had already done that and that is why I stated "5.0.*" and "5.1.*". In other words, I can confirm that the problem does not show up in 5.0.34 (and lower), whereas it does show up in version 5.1.0 (and beyond).

Thanks again.

Last edited 3 years ago by Lou P (previous) (diff)

comment:38 follow-up: ↓ 42 Changed 3 years ago by michael

Be warned, there are likely to be more questions coming, as at present we can't reproduce this and there is a lot of guessing involved. I understand that enabling and disabling 3D for a virtual machine makes no visible difference to the symptoms. Confirmation that that is (or is not) the case welcome. It would also be good to know what the relationship is between CPU load (for all cores) and the sluggishness observed. I am not a Mac person, but it seems that Activity Monitor is the tool to use<1>.

  1.  https://support.apple.com/en-us/HT202060

@opcenter You said that the additional logging showed delays in handling events. Could you please post an extract from the logging with comments about how you interpret it? Adding timing information to the logging using the log flags might be good.

Please also check /Library/Logs/DiagnosticReports/ for spindump reports related to VirtualBox.

comment:39 follow-up: ↓ 40 Changed 3 years ago by socratis

Replying to Lou P:

Thank you for the lesson; I wished it was delivered a bit softer though.

It seems no matter how hard I try, these "lessons" always seem "harsh" to the "pupil". Plus, I'm not known to "sugar coat" things... ;)

I had already done that and that is why I stated "5.0.*" and "5.1.*".

Excellent! That's a good data point for the developers (I think/I'd like to believe). It's just that no one reported anything before the 5.1.14 update, that's why I wanted to make sure...

comment:40 in reply to: ↑ 39 Changed 3 years ago by Lou P

Replying to socratis:

It seems no matter how hard I try, these "lessons" always seem "harsh" to the "pupil".

No worries, no permanent damage on this side... :)

It's just that no one reported anything before the 5.1.14 update

I waited a few versions before reporting this issue hoping that it would be ironed out by itself. But for my config, it is sure that the problem started when VB jumped from 5.0.34 to 5.1.0.

comment:41 Changed 3 years ago by iustinn

Same issue here. I have 3 macbooks pro here, running macOS Sierra 10.12.3

Macbookpro late2013 (i7, intel iris 5200 only) Macbookpro mid2015 (i7, radeon R9 M370X 2048 MB) Macbookpro late2016 (i7, Radeon Pro 460)

I am running windows XP,windows10 & a few linux'es (ubuntu,kali,manjaro)

ALL machines have the same problem. Virtualbox 5.1.16 r113841 (Qt5.6.2) (this problem is now old for me, struggling with it since last year..)

Tried all combinations, more/1 cpu cores, 3d/2d one by one,all at once, external displays,different resolutions, scaling/no scaling etc etc.

The only thing that made things better is to disable mouse integration but than cursor is inaccurate and you loose the super useful feature :(

I am SURE that this is something Apple changed (aka broke) in Sierra or ElCapitan because everything works perfectly on macos Yosemite. Like, the fact you were no longer able to scroll line-by-line, but partially fixed later (although for ex. in latest version of firefox it is no longer working again => weird)

I know maybe Apple should fix the damn' mouse multiple issues, but that again, except VB and a few other free apps, everything works well so they won't bother.

If i can help ... THANK YOU for this software that allowed me to learn so much during the 10years since I am using it!

comment:42 in reply to: ↑ 38 Changed 3 years ago by opcenter

Replying to michael:

@opcenter You said that the additional logging showed delays in handling events. Could you please post an extract from the logging with comments about how you interpret it? Adding timing information to the logging using the log flags might be good.

Unfortunately the logging that I get isn't all that helpful because it just shows the mouse movement events in linear time without any points of reference like when did I actually start moving the mouse vs. when did it show up in the guest. If tail the log I can see it continuing to run well after I've completed the mouse movements. Let me know if you can think of a specific way to capture that info.

Please also check /Library/Logs/DiagnosticReports/ for spindump reports related to VirtualBox.

Looks like I do have one. I'll attach it.

Changed 3 years ago by opcenter

VirtualBox diagnostic report with spindump

comment:43 follow-up: ↓ 55 Changed 3 years ago by michael

Another test which would at least give a clue whether this is more due to slow updates delaying input or more due to slow input would be to have something else running on the guest screen which updates regularly (glxgears? On Ubuntu and probably Debian it is in the mesa-utils package; on Fedora installed by default) and report whether updates also slow down when the drag and resize problems occur. Results with both 3D enabled and disabled would be interesting.

comment:44 in reply to: ↑ 37 ; follow-up: ↓ 45 Changed 3 years ago by iustinn

Replying to Lou P:

Replying to socratis:

You really don't have to quote the whole previous message just to repeat it again point-by-point, because your answer ends up being

Thank you for the lesson; I wished it was delivered a bit softer though. I am just trying to help and am no expert at this. Trying to be useful, I repeated but added extra details to the point-by-point steps since they were a bit ambiguous and you may end up getting unreliable feedback from users in case they did not carefully follow all the steps.

Anyway, more importantly:

Have you tested all the previous 5.0.x and 5.1.x versions?

Yes, I had already done that and that is why I stated "5.0.*" and "5.1.*". In other words, I can confirm that the problem does not show up in 5.0.34 (and lower), whereas it does show up in version 5.1.0 (and beyond).

Thanks again.

.

Hi, this is not true.

Just tested on a macbookpro mid2015, i7, radeon M370X and: (windows10 x64 as guest)

5.1.18 -> NOT working
5.0.36 -> NOT working (it was even worse..)
5.0.34 -> NOT working

As far as I see things, you can try all versions, it won't work. Apple did some changes and it requires a new VB version that can adapt to this "changes" (if possible..)

On the same machine I booted Yosemite a couple of weeks ago. It worked great with the latest version at that time,and a couple of the previous ones.

If any developer interested, i can leave a machine with team-viewer or something for testing ...

Last edited 3 years ago by iustinn (previous) (diff)

comment:45 in reply to: ↑ 44 ; follow-up: ↓ 46 Changed 3 years ago by Lou P

Replying to iustinn:

Hi, this is not true.
5.0.34 -> NOT working

Well,
The truth is a relative concept here! It definitely is true for me; 5.0.34 does work fine for my config (checked and re-checked).
No wonder this bug is difficult to catch!

comment:46 in reply to: ↑ 45 ; follow-ups: ↓ 47 ↓ 51 Changed 3 years ago by iustinn

Replying to Lou P:

Replying to iustinn:

Hi, this is not true.
5.0.34 -> NOT working

Well,
The truth is a relative concept here! It definitely is true for me; 5.0.34 does work fine for my config (checked and re-checked).
No wonder this bug is difficult to catch!

Well, i am not even talking about external mouse. Using the track-pad with nothing else attached. You have latest version of Sierra ? You have windows10 x64 as the testing guest?

I have near me a macbookpro 2016, copied the .vdi on that one, same result. I wonder what do you do/have that is different ? ...

3 different macbooks, same result here. Yosemite is ok with any version tested.

comment:47 in reply to: ↑ 46 ; follow-up: ↓ 48 Changed 3 years ago by Lou P

Replying to iustinn:

You have latest version of Sierra ? You have windows10 x64 as the testing guest? I wonder what do you do/have that is different ? ...

Please refer to comment 34 above, it lists my exact configuration / problem.

Last edited 3 years ago by Lou P (previous) (diff)

comment:48 in reply to: ↑ 47 Changed 3 years ago by iustinn

Replying to Lou P:

Replying to iustinn:

You have latest version of Sierra ? You have windows10 x64 as the testing guest? I wonder what do you do/have that is different ? ...

Please refer to comment #34 above, it lists my exact configuration / problem.

Page/forum is like made by 'developers for developers' - personally I am just a simple user. Don't have the clear mind,time and maybe IQ level to find-it.Sorry.

I did see something about ubuntu? I am talking Windows in my tests.. Maybe version 5.0.34 is ok for linux..

comment:49 follow-up: ↓ 52 Changed 3 years ago by michael

Please, everyone is entitled to their own opinion and everyone is entitled to their own bug symptoms, though it is great of course if people compare to try to find the common and different factors. (Developers are also free to ask someone to open a new ticket if they think that two issues are different. So far we do not have a clear enough idea in this case to make that interesting.) Still interested in an answer to the question I asked in comment:43.

comment:50 follow-up: ↓ 58 Changed 3 years ago by BrendanSimon

Have you got "Use Unscaled HiDPI Output" setting checked?

I found that this seriously slows down dragging windows in my Win7 guest. To get reasonable performance I had to uncheck that options AND set the Scale Factor to 100% (in View menu).

On hi-res screen (retina or external) the fonts, etc are very small (and fairly unusable). The best workaround I had is to change the Windows usability settings to scale by 150% (largest avaialble). This works ok on hi-res screens (like my MacBook Pro retina) but moving the window to my external monitor (Dell 27") it was way too magnified ..... sigh ....

I also found that the size of the window being dragged has a big impact. The dragging is exponentially worse the larger the window.

Dragging scrollbars is also very slow and laggy. Using two finder push up/down gestures seem to work better.

Can't wait for all this slow window moving / mouse event processing (or whatever) to fixed ASAP. It's quite the pain.

BTW, I'm running VB v5.1.18 on MacBook Pro 15" (late 2016) with macOS Sierra (10.12) with 16GB RAM.

Last edited 3 years ago by BrendanSimon (previous) (diff)

comment:51 in reply to: ↑ 46 Changed 3 years ago by iustinn

Replying to iustinn:

Replying to Lou P:

Replying to iustinn:

Hi, this is not true.
5.0.34 -> NOT working

Well,
The truth is a relative concept here! It definitely is true for me; 5.0.34 does work fine for my config (checked and re-checked).
No wonder this bug is difficult to catch!

Well, i am not even talking about external mouse. Using the track-pad with nothing else attached. You have latest version of Sierra ? You have windows10 x64 as the testing guest?

I have near me a macbookpro 2016, copied the .vdi on that one, same result. I wonder what do you do/have that is different ? ...

3 different macbooks, same result here. Yosemite is ok with any version tested.

Lou, you are somehow correct. Version 5.0.34 is OK with winXP and Kali, but not with windows10 :( This is one weird pain in the AS*!

comment:52 in reply to: ↑ 49 Changed 3 years ago by iustinn

Replying to michael:

Please, everyone is entitled to their own opinion and everyone is entitled to their own bug symptoms, though it is great of course if people compare to try to find the common and different factors. (Developers are also free to ask someone to open a new ticket if they think that two issues are different. So far we do not have a clear enough idea in this case to make that interesting.) Still interested in an answer to the question I asked in comment:43.


Please download - glxgears, screen recordings of 3 guests on 2 VB versions.  http://fastupload.rol.ro/e536cf3d4f3a719e1e7e52749dfd85a4.html

Windows10 is the most affected.

comment:53 follow-up: ↓ 54 Changed 3 years ago by michael

Thanks for the videos. I have trouble though seeing what interests me - does other screen animation in the guest continue as normal while the slow drags and/or resizes are occurring? It looks to me like it does, but I have trouble saying for sure. Also, I was interested in what the host CPU monitors said.

comment:54 in reply to: ↑ 53 Changed 3 years ago by iustinn

Replying to michael:

Thanks for the videos. I have trouble though seeing what interests me - does other screen animation in the guest continue as normal while the slow drags and/or resizes are occurring? It looks to me like it does, but I have trouble saying for sure. Also, I was interested in what the host CPU monitors said.


ok - will try again monday and upload @ higher quality.

yes - animation is fine, everything is for the matter, except when you want to move/resize windows. it is hard with 3 different guests, because of the possible options/combinations in settings and upgrading/downgrading guest additions (in kali is a pain)

I propose I stick with windows10 only. Any glxgears? or something that you want to see in win10?

comment:55 in reply to: ↑ 43 Changed 3 years ago by agodfrin

Replying to michael:

Another test which would at least give a clue whether this is more due to slow updates delaying input or more due to slow input would be to have something else running on the guest screen which updates regularly ...

If that counts, I can play youtube videos and also local files (mp4) in my Linux VM without any problem. The output is smooth.

comment:56 Changed 3 years ago by michael

glxgears was just an example. Anything which produces animation will do, maybe even those CPU usage graphs, though they are somewhat jerky, so not such a good test. What interests me is whether the animation slows down when the window moves start getting delayed.

comment:57 Changed 3 years ago by gonhidi

This seems similar to ticket #11606, which has been around for several years now.

comment:58 in reply to: ↑ 50 Changed 3 years ago by michael

Replying to BrendanSimon, comment:50:

Have you got "Use Unscaled HiDPI Output" setting checked?

I found that this seriously slows down dragging windows in my Win7 guest. To get reasonable performance I had to uncheck that options AND set the Scale Factor to 100% (in View menu).

This reads to me as the opposite of what you wrote in ticket:11606#comment:34. Could you please edit one of the two comments to clarify?

comment:59 follow-up: ↓ 60 Changed 3 years ago by iustinn

Ok, this is so frustrating... is there a way to contribute to virtualbox team with money/products? I find it ridiculous for a good developer in the 21th century NOT to have all the required software and hardware for which he is writing code!

You need a macbookpro, windows licence, BASIC stuff! Opensoftware ok,but everyone must be payed!

On the troubleshooting side, there IS a subtle animatian lag when moving the mouse --> see attached video.  http://fastupload.rol.ro/2913e45ec8aa580ea433bcb9595606b5.html

comment:60 in reply to: ↑ 59 Changed 3 years ago by socratis

Replying to iustinn:

Ok, this is so frustrating... is there a way to contribute to virtualbox team with money/products? I find it ridiculous for a good developer in the 21th century NOT to have all the required software and hardware for which he is writing code''


My rough estimate would be:

  • 4-5 different MBPs that have been mentioned in this thread, for testing.
  • About a month's time for a senior development to drop everything that they're doing and focus solely on a cosmetic bug with a known workaround.
  • About 15,000 euros/dollars for development/testing costs. It is a senior developer we're talking about.
  • No need to worry about the Windows license, MS offers pre-made Windows VMs. But it's not Windows only...
  • Peace, quite, understating, maturity and most of all restrain from the end-users.

comment:61 Changed 3 years ago by iustinn

1,2,3 and 4 - what is the problem? put up a damn' fundraising/contribution campaign! That is not much! 5 point .. well, that one I'm afraid you can't have! :)

comment:62 follow-up: ↓ 64 Changed 3 years ago by michael

@iustinn The idea is good. A small point is that we are unfortunately not able to add developer time on short order, so you would have to find an external developer to do the work as well as raise the funds to pay them. Since integrating code is often quite a bit of work for both sides, a competent analysis of the problem might well be as good as or better than a patch.

And apart from that,

  1. I was wondering whether there is any other common change that people seeing this problem might have made to their hosts, such as a particular configuration setting, or installing a particular piece of software, which would explain why none of us was able to reproduce it: our Mac systems are mainly for development so they are more likely to be close to the factory state.
  2. I create a test build<1> with a small change: mouse position events which are lagging the host pointer position too badly are dropped and not passed to the virtual machine. This is definitely not a fix, and will probably break other things, but I would be interested to know whether this is more bearable for people with this problem than the current situation.
  1. https://www.virtualbox.org/download/testcase/VirtualBox-5.1.19-114107-OSX.dmg
Last edited 3 years ago by michael (previous) (diff)

comment:63 Changed 3 years ago by opcenter

@michael - I gave your test build a try and it is more usable. Window dragging is a bit choppy (to be expected), but at least it doesn't keep queueing events so I have to wait for the window to stop moving.

comment:64 in reply to: ↑ 62 Changed 3 years ago by Lou P

Replying to michael:

  1. I was wondering whether there is any other common change that people seeing this problem might have made to their hosts (...)

Hi, No changes in my config. The only thing is that I am carrying the guest (RedHat) .vdi file for a while, i.e. several years, so it is not a fresh install; perhaps this could be why you cannot easily reproduce the problem at your end (?!?).

  1. I create a test build<1> with a small change (...)

Your 5.1.19 test build seems to fix the problem. It is still not super fast but I would say that it solves 95% of the problem.

comment:65 Changed 3 years ago by iustinn

@michael - "none of us was able to reproduce it" - this is new and incredible!

We are a small group here of technical people with macs (all kind) that try to provide support for other people with macs, so we use them for our work because we have to, not because we are fans or something else.(they are a love/hate thing..)

So, on all our macs, older to newest, the problem is present. One 2016 touchbar mac was just unboxed and I have copied my win10 machine to that new mac and it was having the same behavior, so there were no special configurations, apps installed, etc. (just stuff like firefox,viber,gimp and doublecommander)

I have just installed your build and 0 changes. (upgraded guestadditions too)

comment:66 Changed 3 years ago by michael

If you have things on your Mac like Firefox, Viber, Gimp and Double Commander installed on your Mac then it is presumably not quite at factory settings. I assume you also did some localisation (all of our systems are US English as far as I know - I do not use a Mac). And asking it seems that people on the team have seen some slow down, but only using 2D rendering (with the caveat that enabling 3D does not mean that the host is actually using it: you can tell by the fact that the 3D icon at the bottom of the screen - which looks like a single monitor - flashes). These people reported the same as opcenter and Lou P about the test build.

comment:67 follow-ups: ↓ 68 ↓ 71 Changed 3 years ago by michael

It seems safe to assume though that there are quite a lot of Mac users who are not affected by this, given the number of people who are reporting it compared to the size of our Mac user population (even if some are just not worrying enough to report it).

comment:68 in reply to: ↑ 67 ; follow-up: ↓ 70 Changed 3 years ago by iustinn

Replying to michael:

It seems safe to assume though that there are quite a lot of Mac users who are not affected by this, given the number of people who are reporting it compared to the size of our Mac user population (even if some are just not worrying enough to report it).


I don't see is "safe". I reported it by a 'mistake' - having a period with free time, being a person that uses it both on mac and windows, wanting to help a little, but i have this problem since a long time, and it was just "well, it is free, no one has time, apple broke the mouse, no one will care and it is not that bad ..."

we use English US too, and if firefox and gimp are the guilty ones, well, than we should not use vb at all...

PS: "I do not use a Mac" - than how do you even know what an how ? mouse stays behind the windows movement no mater what settings used, on a lot of different macs. Please give me a teamviewer on a mac that doesn't.

comment:69 Changed 3 years ago by michael

I know what and how from descriptions and videos. I implemented a generic, operating system-independent work-around - just dropping input events - which clearly made a difference to a couple of people. This was for diagnostic purposes as much as anything else, which might (possibly) suggest that you are seeing something different to other people. And no, I can't tell you why the change helped some people but none of the Mac systems you have access to.

Unfortunately the people best placed to fix this on our team have many other things to do as well. I can understand if people do not want to buy support to escalate this sort of issue (though I must admit I have no idea of the prices, nor of what escalation might even be possible) but in that case you have to live with the resources we have available. Or you can try your fundraising campaign. So far I don't remember anyone actually doing that to solve a bug, but I would be interested to see a first. Of course, I can't promise we won't fix it some time soon, which might be a bit awkward if you were sponsoring someone to look at it, but I can't promise we will either.

comment:70 in reply to: ↑ 68 Changed 3 years ago by Lou P

Replying to iustinn:

Replying to michael: (...) but i have this problem since a long time, and it was just "well, it is free, no one has time, apple broke the mouse, no one will care and it is not that bad ..."

I agree. I am positive that this problem is well spread and that many people are not reporting it. I stayed quiet about it for a long time (because it is not that bad, it is a free software, etc.) and actually created an account on this site just so that I can report this issue since it was a very obvious bug / limitation.

Since it seems that the VB team is not able to systematically reproduce this behavior (although it is 100% reproducible and predictable on my configuration), the only thing I wonder is: could this be related to carrying a .vdi file from an old version of VB to a new one? I.e. if I were to install a new guest right now, would the problem still show up? Unfortunately, I do not have the means to try this out without considerable effort, but perhaps someone else can report on this... My two cents...

comment:71 in reply to: ↑ 67 Changed 3 years ago by agodfrin

Replying to michael:

It seems safe to assume though that there are quite a lot of Mac users who are not affected by this, given the number of people who are reporting it compared to the size of our Mac user population (even if some are just not worrying enough to report it).

Well I have been using VB for many years without seeing any problem. I started seeing the problem when I switched to a 2016 MBpro with a retina display. I have both my older 2012 MBPro running next to my 2016 MBPro. Both run the latest Sierra. Both runs the same test VB. One is fine, the other is sluggish. I posted logs for the 2016 MBpro. Tweaking 2d/3d acceleration makes no difference.

MacBook Pros tend to have a long useful life (I only changed my previous 2012 MBPro because I needed more RAM and I could not increase that - otherwise I would have happily stayed with it). I expect that we will see more Mac users complaining about the issue as they switch to newer retina models.

comment:72 Changed 3 years ago by michael

Our latest 5.1 test builds<1> contain a slightly improved version of the work-around. Hopefully this will make the problem more bearable for some people.

  1. https://www.virtualbox.org/wiki/Testbuilds

comment:73 Changed 3 years ago by michael

Regarding guest applications, we had a report that one person had ceased to see slowdowns after they updated Chrome on their Windows guest.

comment:74 Changed 3 years ago by socratis

It's tough sometimes for some people to understand what "factory settings" means for a computer. They think that Chrome or any other "simple" application is just an application, until they figure out that the background services running (like Chrome's GoogleUpdate and GoogleErrorReporter) can have an adverse effect on the state of the computer. Even physical ones, let alone virtual.

You ask people "Did you install any 3rd party apps?" and they always come with a "No", but then you figure out that they've installed almost everything available on c|net, and they expect you to figure out what's wrong with their system and why (oh, why) you can't reproduce it!

(sorry, had to get it off my chest)

comment:75 follow-up: ↓ 77 Changed 3 years ago by unsightlygod

Hi,

This issue affects me too. I'm a long time VirtualBox user, mainly running Linux guests on Linux hosts. Recently got a 2015 MacBook Pro at work and loved it so much I've now got a 2016 MacBook Pro at home. Both are running VirtualBox 5.1.18.

As a test I've created a new (from ISO) install of Debian 8 64-bit on each machine, using the defaults provided by VirtualBox in each case. I haven't touched a single setting of the VM.

Started without guest additions installed, using the default resolution 1024x768.

Using a USB mouse, connected to the host, with/without pointer integration enabled:

There is significant lag on both Macs when dragging windows around in the guest on both the Retina display, and an external display connected via HDMI (on the 2015 mac). Usable with much annoyance, the lag is very very noticeable at 3-4 seconds at its worst :-)

Using a USB mouse, connected to the guest via usb passthrough, with pointer integration disabled:

Window dragging lag is massively reduced to a perfectly usable level. Same on both the Retina display and external display (in the case of the 2015 mac).

Installed guest additions, upping the resolution to 1280x720 (using the View menu):

Using a USB mouse, connected to the host, with/without pointer integration enabled:

There is significant lag on both Macs when dragging windows around in the guest on both the Retina display, and an external display connected via HDMI (on the 2015 mac).

Using a USB mouse, connected to the guest via usb passthrough, with pointer integration disabled:

Window dragging lag is massively reduced to a perfectly usable level. Same on both the Retina display and external display (in the case of the 2015 mac).

Interestingly there's often a slight slowdown of the mouse when connected via USB passthrough. It appears to be when the mouse is passing over areas of the display which respond to it, for example due to hover-over icons. May be a placebo effect though - I'm looking more closely than usual.

I repeated the tests above (without the USB passthrough) using the integrated touch pads on both macs, the same results were observed.

Appears that rather than a display issue it may well be an input issue, when using the host mouse.

For now as I generally use the laptop standalone I'm using the VM via the remote display feature....which works around the issue......while feeling a little dirty.

Must admit I've been looking at VMWare's offering for mac but I love using VirtualBox across all the platforms I work on - it's been such a dependable workhorse over the years.

I'm a software developer by trade (generally Embedded rather than desktop). I had a quick go compiling the latest version of VirtualBox but found myself hacking bits of the build system all over the place. Doesn't look like it's been built on Sierra before :-(....and doesn't seem to like Qt's official distribution.....I suspect I'm doing terrible things to it.

I may look to take my build discussion onto the forums. I'm more than happy to assist in any way I can to resolve this issue. Apologies for the long post.

Thanks,

Phil

comment:76 Changed 2 years ago by DmitrG

Could someone check if disabling "Show Monitor Preview" in Dock menu has an impact on "input lag" issue? Also "Disable Icon Overlay" influence would be interesting.

Avoiding an extra-features should probably improve performance.

Changed 2 years ago by DmitrG

How to disable "Dock Icon" updates.

comment:77 in reply to: ↑ 75 Changed 2 years ago by DmitrG

Hi Phil. Could you try to disable updates of "Dock tile icon" as shown here https://www.virtualbox.org/attachment/ticket/16436/DisableDockiconOverlay.png. On my MackBook that seriously reduced redrawing delay while a window is dragged by mouse in guest.

Replying to unsightlygod:

Hi,

This issue affects me too. I'm a long time VirtualBox user, mainly running Linux guests on Linux hosts. Recently got a 2015 MacBook Pro at work and loved it so much I've now got a 2016 MacBook Pro at home. Both are running VirtualBox 5.1.18.

As a test I've created a new (from ISO) install of Debian 8 64-bit on each machine, using the defaults provided by VirtualBox in each case. I haven't touched a single setting of the VM.

Started without guest additions installed, using the default resolution 1024x768.

Using a USB mouse, connected to the host, with/without pointer integration enabled:

There is significant lag on both Macs when dragging windows around in the guest on both the Retina display, and an external display connected via HDMI (on the 2015 mac). Usable with much annoyance, the lag is very very noticeable at 3-4 seconds at its worst :-)

Using a USB mouse, connected to the guest via usb passthrough, with pointer integration disabled:

Window dragging lag is massively reduced to a perfectly usable level. Same on both the Retina display and external display (in the case of the 2015 mac).

Installed guest additions, upping the resolution to 1280x720 (using the View menu):

Using a USB mouse, connected to the host, with/without pointer integration enabled:

There is significant lag on both Macs when dragging windows around in the guest on both the Retina display, and an external display connected via HDMI (on the 2015 mac).

Using a USB mouse, connected to the guest via usb passthrough, with pointer integration disabled:

Window dragging lag is massively reduced to a perfectly usable level. Same on both the Retina display and external display (in the case of the 2015 mac).

Interestingly there's often a slight slowdown of the mouse when connected via USB passthrough. It appears to be when the mouse is passing over areas of the display which respond to it, for example due to hover-over icons. May be a placebo effect though - I'm looking more closely than usual.

I repeated the tests above (without the USB passthrough) using the integrated touch pads on both macs, the same results were observed.

Appears that rather than a display issue it may well be an input issue, when using the host mouse.

For now as I generally use the laptop standalone I'm using the VM via the remote display feature....which works around the issue......while feeling a little dirty.

Must admit I've been looking at VMWare's offering for mac but I love using VirtualBox across all the platforms I work on - it's been such a dependable workhorse over the years.

I'm a software developer by trade (generally Embedded rather than desktop). I had a quick go compiling the latest version of VirtualBox but found myself hacking bits of the build system all over the place. Doesn't look like it's been built on Sierra before :-(....and doesn't seem to like Qt's official distribution.....I suspect I'm doing terrible things to it.

I may look to take my build discussion onto the forums. I'm more than happy to assist in any way I can to resolve this issue. Apologies for the long post.

Thanks,

Phil

comment:78 Changed 2 years ago by socratis

The "Disable Icon Overlay" should not have an impact on the performance. It's a static icon after all. The "Show Application icon" vs. "Show Monitor Preview" could very well have one. It definitely has on the Dock.app, that's why I have it disabled globally on all of my VMs:

VBoxManage setextradata global GUI/RealtimeDockIconUpdateEnabled false

See also:  https://forums.virtualbox.org/viewtopic.php?f=8&t=51624

comment:79 follow-up: ↓ 81 Changed 2 years ago by diver.

Can anyone check if version 4.1.28 had this problem?  http://download.virtualbox.org/virtualbox/4.1.28/

For me this was the last version which didn't lag on MacBook Pro. See ticket:11606#comment:12.

Maybe someone can create a diff between 4.1.28 and 4.1.30 and share it somewhere?

comment:80 Changed 2 years ago by diver.

Well, I downloaded sources of both versions:  http://download.virtualbox.org/virtualbox/4.1.28/VirtualBox-4.1.28.tar.bz2  http://download.virtualbox.org/virtualbox/4.1.30/VirtualBox-4.1.30.tar.bz2

Unpacked them and compared using diff:

diff -Nuar VirtualBox-4.1.28/src/VBox/Devices VirtualBox-4.1.30/src/VBox/Devices

Most of the changes were in src/VBox/Devices/VMMDev/VMMDevHGCM.cpp

Here is the output if anyone cares to look:  http://paste.debian.net/932283/

comment:81 in reply to: ↑ 79 Changed 2 years ago by DmitrG

Replying to diver.:

Hi Diver. VirtualBox 4.1.28 is too old and incompartible with OSX Sierra and can't be installed on it.

Can anyone check if version 4.1.28 had this problem?  http://download.virtualbox.org/virtualbox/4.1.28/

For me this was the last version which didn't lag on MacBook Pro. See ticket:11606#comment:12.

Maybe someone can create a diff between 4.1.28 and 4.1.30 and share it somewhere?

comment:82 Changed 2 years ago by unsightlygod

Hi,

Didn't get a notification of those few posts.

Tried the overlay / preview options, they didn't appear to have any effect....except my missing the adorable little preview.

What seemingly has had an effect is my upgrade from 5.1.18 to 5.1.22.

In 5.1.18 I could easily drag a window around for a little, getting it to lag a few seconds behind the mouse.

In 5.1.22 this effect to have been significantly reduced, there's still a little lag but the getting seconds behind the mouse doesn't seem to happen....or is much harder to trigger at least.

Happy to try any other suggestions / help where I can.

Thanks,

Phil

comment:83 Changed 2 years ago by agodfrin

Also just upgraded to 5.1.22. I still see a lag, but it seems less than before (I was running 5.1.16).

comment:84 Changed 2 years ago by agodfrin

Upgraded to current latest 5.1.26. Still seeing the lag when dragging windows around (guests Linux and Windows). Not as bad as originally, but still not as it is on my Mac without retina display.

comment:85 follow-up: ↓ 86 Changed 2 years ago by iustinn

Had such high hopes - was thinking in using VB again but nope, the text below is wrong :(

"GUI: Fixed double mouse cursor when using mouse integration without Guest Additions, actually a Qt 5.6 bug fixed with QT 5.6.3 (Mac OS X hosts only; bug #15610) "

As you see, the issue is clear - it is working ok WITHOUT guest additions!

 http://fastupload.ro/f8ab7d42e294b76f6a5c014bbae27773.html

Last edited 2 years ago by iustinn (previous) (diff)

comment:86 in reply to: ↑ 85 Changed 2 years ago by socratis

Replying to iustinn:

Had such high hopes - was thinking in using VB again but nope, the text below is wrong :(

"GUI: Fixed double mouse cursor when using mouse integration without Guest Additions, actually a Qt 5.6 bug fixed with QT 5.6.3 (Mac OS X hosts only; bug #15610)"

The text that you quoted is from a different bug. And that bug is fixed. I opened that bug, and I tested the very first build with Qt 5.6.3, before it was even made public. That was a week after 5.6.3 came out, and I was working with the developers to see if that issue had been resolved. And it did, no question about it. We're not even talking about the same guests!

So, I'm not quite sure what you're referring to. Let me remind you that the ticket's title is quite different from what you're showing in the video and quite different from the bug that you quoted. Maybe you're referring to a completely different symptom? Which would require the opening of a new ticket?

And what's missing so far, is a VBox.log. ZIPPED. With all the "me too", there are very few, old, outdated logs. So after having installed the latest and greatest VirtualBox:

  • Follow a "start the VM from cold-boot" / "observe error" / "shutdown the VM" cycle.
  • With the VM shut down completely (not paused or saved), right-click on the VM in the VirtualBox Manager and select "Show Log".
  • Save only the first "VBox.log", ZIP it and attach it to your response.

comment:87 Changed 2 years ago by iustinn

Different bug? Ok ... this bug, the one in this post, in my video, is over 1 year old, two versions of macOS (sierra and high sierra), multiple versions of VB, different macbook pros (late2013, mid2015 and latest 2016) so I don't have hopes anymore. Used to be a good free product that has helped me test a lot of stuff and loved it's simplicity. We do use vmware at work and I have license for use at home, but still, I always enjoyed the less bureaucratic and stable VB, all up to Sierra :(

I would like to help but I get it, no money, no time, not very many developers with expensive macs and the windows version runs perfectly. So... if there is anything else...

I can spend some time testing stuff maybe or whatever, but only if there is a developer with a real mac and the time to take it int-o consideration.

Good luck.

PS: You can't attach anything to this forum ...so here is a link.

 http://fastupload.rol.ro/17fd9c779dc9d4c78074a05498a8a775.html

comment:88 Changed 2 years ago by michael

I hope everyone will excuse me for deleting the last few comments here. I think we can agree that there was indeed a mistake regarding which bug was fixed and which not.

I can provide some update on this problem. No one is currently working on this issue that I am aware of. However I hope that it will be resolved at some point as a side-effect of other work which is being done. I am also sorry that we can't offer a way for non-paying customers to pool money to pay for a fix. If anyone knows of third party developers who will do contract fixes to open source software feel free to let us know though.

comment:89 Changed 2 years ago by bootup

Hi folks, First, glad I found this thread (I came from Ticket #16561opened by user iustinn and having the priority major) and than sad to find this one, marked "minor" and with a last comment from michael (hope hi has no idea about the developers work) that said no one gives a damn about it.

Virtualbox at the moment on macOS high sierra with a window10 guest can hardly be called usable.

I have switched from a windows PC to macOS and I used virtualbox for years but now, due to the mouse lag/windows dragging lag or how you want to call it is a pain :(

I have seen the video from user iustinn a couple of days ago and I have exactly the same issue. Tried everything, every virtualbox settings combinations, 3D/2D/All D,no D it does not work. My mackbookpro has a dedicated Radeon card, i7cpu and 16GB of DDR3 so it is not the hardware. Also, if in bootcamp, no problem at all.

So, is there anything I can do to help in resolving this issue ? I don't have money to buy Parallels and do constant payed updates and I still need windows for school and stuff :( (and if you think i'm rich because of the macbook... you are wrong, but that is another story)

Thank you and have a nice day.

comment:90 Changed 18 months ago by amko

Hi.

Any update on this issue? When it will be fixed?

Parallels still does not have support of Ubuntu 18 at all, VirtualBox has but it is not usable due to this issue.

Changed 15 months ago by danaussie

comment:91 Changed 15 months ago by danaussie

UI is quite sluggish for me too. I've attached my logs. I am using the new MacBook Pro 15' for this test (just released a few days ago). High Sierra 10.13.6.

Last edited 15 months ago by danaussie (previous) (diff)

comment:92 Changed 15 months ago by danaussie

I found out that if I

  • install the latest box (5.2.16)
  • use that to successfully install the guest additions on my xubuntu 18.04 guest (which fails in previous versions of virtual box)
  • then revert to virtual box 5.0.40

The vm still seem to work fine. AND the UI performance is a lot closer to acceptable.

Logs attached.

Last edited 15 months ago by danaussie (previous) (diff)

Changed 15 months ago by danaussie

comment:93 Changed 14 months ago by clouddev

Still seeing sluggish window dragging in Linux VMs. Running High Sierra 10.13.6 on a 2018 i7 MacBook Pro with VirtualBox 5.2.18 (3D acceleration enabled/disabled doesn't make a difference.) I previously used these VMs on an older Windows PC with VirtualBox and saw much snappier UI responsiveness there. Tried with 3 VMs on this mac so far (2 Ubuntu 18 and one Ubuntu 14) with the same issue.

comment:94 Changed 14 months ago by clouddev

Also want to add that like the poster in comment 92 I'm seeing much better results after downgrading to VB 5.0.40. Window movement is still not as smooth as it was on the Windows host, and there is now some tearing when moving windows around quickly, but it's much less sluggish.

Last edited 14 months ago by clouddev (previous) (diff)

comment:95 Changed 13 months ago by cesarcafe

I confirm this bug is still present in 5.2.18, and I guess it affects all Macs with recent MacOS versions, although you are not getting the expected number of complaints/reports because IMHO this ticket is misplaced: It has nothing to do with Linux guests, it affects all guests. And it's not a problem about just dragging/resizing windows, but about moving anything on the screen (interactive 3D included) while the CPU has relatively high load (even clicking GUI controls becomes almost impossible when the CPU load is high).

I believe a number of users affected by this bug didn't read this ticket just because the title sounds quite different to the problem they see (in fact, I was going to skip it in the search engine, but no other tickets matched the problem, so I decided to read it supposing it was unrelated, and to my surprise, this is exactly the bug I was getting).

I'm experiencing this bug with a brand new 2018 MacBook Pro (15inch, 6-core i9, 32GB RAM), and it's pretty annoying. I noticed it because I was using Revit 2019 on a Windows 7 x64 VM (my host is High Sierra 10.13.6), and while dragging a 3D view, a few frames were rendered, and then the VM became like frozen: no mouse pointer, no screen updates, nothing. Reading this ticket, I found the direct USB mouse trick, and it works (in fact, if I drag a Revit 3D view with the Trackpad and it becomes stuck, I can make it resume by dragging the (direct USB) mouse.

My first guess is that the cause was because either this i9 was too new and proper virtualization for it wasn't implemented in VirtualBox yet, and it was being used in a way that all its performance was invested in Mesa/Gallium OpenGL and no cycles were left for updating the UI. Another guess was that it could perhaps be related to memory access (the VM getting temporarily stuck because of some memory access bug)... I had a quick feeling that it could be a matter of mouse input, but I didn't take it too seriously. I mention my first guesses just to show that other Mac users suffering this bug can be searching for it following totally wrong clues.

Please consider fixing this. All users with recent Macs are likely to get the mistaken impression that VirtualBox is not adequate for their purposes. I purchased this new MacBook Pro instead of a lighter MacBook Air just for having more RAM and more power for VirtualBox, as I'm using VMs in my public presentations. I'm glad that the USB mouse workaround can be used, but my presentations are not going to be the same without pointer integration, and with the steps needed to attach/detach the USB capture.

Last edited 13 months ago by cesarcafe (previous) (diff)

comment:96 Changed 13 months ago by michael

Could you suggest an update to the bug title? Disclaimer: I haven't followed all the details here, because I don't have access to a Mac and I have more than enough other things I could be fixing if I had time.

comment:97 Changed 13 months ago by cesarcafe

Thanks a lot for your prompt reply, Michael. For a more accurate title, I'd suggest "Lagging and long pauses in all guests on recent MacOS hosts".

I'd remove the phrase "performance otherwise is fine" because it's not true: when the CPU load is high, the loss of input events is so severe that you cannot use the VM for 30 seconds or even for a minute, until it starts to react again to input events, and even then is jumpy and hard to control (it looks like if the guest UI becomes frozen during these "pauses", but the host CPU meter reports that the VM is still taking the same CPU cycles as before the "pause"). NOTE: I believe the cause is related to all input events, the keyboard included: it's not just that the mouse cursor doesn't respond, but key presses neither. I think all High Sierra genuine Macs are affected. I say "genuine Macs" because it's possible that hackintoshes are not affected. I'm not sure about Sierra, but High Sierra is affected for sure.

Different symptoms for the same bug:

  • Two mouse pointers when dragging/resizing windows, the guest cursor lagging after the host cursor.
  • In Linux guests with Mesa (no 3D acceleration), when you start glxgears and maximize the window, it's no longer possible to close the window or resize it again, or it's extremely difficult to do so, because the Linux guest doesn't get input events, or gets just a very small subset of them.
  • In Windows guests, 3D applications using software rasterization make the VM to suffer "pauses" of even 1 minute or more when you try to navigate 3D views interactively. It seems that because a lot of CPU load is used for the software rasterization, the VM loses input events, and the guest OS looks like "paused", while still consuming the same amount of CPU load.

The workaround of using a USB mouse with direct interface to the VM (bypassing MacOS) makes all these symptoms disappear.

I appreciate a lot your interest, but I'm using VMs in a professional environment, doing software presentations with VMs, so this bug has a severe impact in my work, even with the USB mouse workaround (its use and its configuration is uncomfortable when you are going to do this everyday).

Because of this, if the VirtualBox development team lacks access to Mac machines, or considers this to be a bug of minor importance, I'll have no other option but purchasing a license for a commercial virtual machine software. It's not that I'm making a threat or something, but that I need this for work, and for the same reason the VirtualBox team cannot afford a Mac, I cannot afford this bug in my professional presentations. I hope you understand my position. I prefer open source software whenever possible, provided that my platform is properly supported. The current situation is that VirtualBox is broken in current (genuine) MacOS hosts, and that there's no priority nor plans for fixing it. In this situation, I need to move to another virtualization platform, for obvious reasons.

comment:98 Changed 13 months ago by michael

Thank you. Please note that I (who does not have access to a Mac) am thankfully not the entire VirtualBox team. If you are looking at purchasing licences, it might be worth enquiring about a licence for VirtualBox, though I believe we are more oriented towards large customers when it comes to paid support, so it might not help you so much. And no, I didn't take that personally: I understand that you have your own business needs. I don't know whether paying customers have been having this problem, though due to the fact that it has not been addressed I suspect not. Given that a lot of people do though, has anyone considered setting up a bug bounty for it? I think this should be something that developers outside of the VirtualBox team with reasonable OpenGL programming skills should be able to address.

comment:99 Changed 13 months ago by michael

  • Summary changed from windows drag and resize slowly, up to several seconds behind mouse. performance otherwise is fine. to Lagging and long pauses in all guests on recent MacOS hosts

Updating the summary as per your suggestion, if anyone disagrees please add a comment.

comment:100 follow-up: ↓ 104 Changed 13 months ago by socratis

@cesarcafe

A couple of points:

  • Having the bare minimum of licenses won't get you far. The priorities are not set as a one-to-one relationship between licenses and priority.
  • Do you seriously think that Oracle can't afford, or doesn't have a Mac? Seriously now?

There can be some issues that can be frustrating, I get it. But if there are workarounds, like not using the GAs, or not using 3D acceleration, or lowering your expectations on what a "virtual GPU" can achieve or not, might help your mindset...

comment:101 Changed 13 months ago by michael

@cesarcafe Unfortunately, none of the team members who do Mac development have ever seen this issue. We do test (and develop) on a range of different systems with different configurations. The question, which no one reporting this issue has been able to answer yet, is what is special about those systems which do have the problem.

I went through all the comments (more or less) and the summary was that the problem goes away if a USB mouse is passed through to the guest (I wonder whether disabling mouse integration does it too?), and that it started with VirtualBox 5.1, which is when we switched from Qt 4 to Qt 5. Out of interest, do you get the problem with a Fedora 28 guest with the Guest Additions which come pre-installed? Those ones do not support using the host mouse cursor.

Last edited 13 months ago by michael (previous) (diff)

comment:102 Changed 13 months ago by michael

And of course any software you might have on the system which might interact with the mouse is of interest.

comment:103 Changed 13 months ago by michael

And is there any way, on a Mac, to change the mouse reporting resolution/sensitivity?

comment:104 in reply to: ↑ 100 Changed 13 months ago by opcenter

Replying to socratis:

  • Do you seriously think that Oracle can't afford, or doesn't have a Mac? Seriously now?

Coincidentally, I work for Oracle (but not anything remotely close to VirtualBox). In my experience, Oracle considers having a Mac an exception and it's only allowed for certain business units.

And of course any software you might have on the system which might interact with the mouse is of interest.

That's a good thought. I was running  Better Touch Tool which is used for watching mouse events to allow dragging windows for tiling purposes. It was running on every Mac that tried. I'll see if I can dig up the Mac I was using to try without it.

comment:105 Changed 13 months ago by klaus

Please don't extrapolate anything from the fact that Michael doesn't have a Mac. Different team members have different equipment, based on their needs and preferences.

The important fact he stated is that our developers do not observe the reported lags. This means that the top priority is to collect as much information snippets as possible from the users who do, to hopefully allow us to collectively figure out what triggers the problem. Once a problem is reproducible by the dev team it is much easier to solve.

comment:106 Changed 13 months ago by cesarcafe

I'm evaluating a commercial alternative for virtual machines for Mac, and it works fine. I understand the VirtualBox developer team might have other priorities, and that's ok because every project has it's priorities. In my work I have other priorities (I really need pristine support for MacOS --I just cannot afford to pause a presentation and say the audience "hey, wait I minute, this got frozen but the USB passthrough should be working to resume this lagging, let me check what's going on").

As I said, it's not personal, just that I need perfect (professional-grade) operation on the Mac. If you have Mac developers and they are not seeing this issue, then either they don't have a machine with a recent MacOS release, or they are on a Hackintosh. If they try VirtualBox on 10.13.6 with a genuine Mac, they are going to see this issue for sure.

Thanks for your replies and clarifications, and my best wishes for success in your priorities.

comment:107 Changed 13 months ago by amko

Soon we will celebrate 2 years since this major issue was opened ))

Really don't understand why this issue still not fixed. For my opinion Mac OS version of VirtualBox should not be available at download section on virtualbox.org just because it is not passing main test case - ability to work smooth with graphical desktops in guest OS.

I can confirm that this issue reproduces very easy - just setup Virtualbox and create a fresh VM with Windows or Linux, run it.

comment:108 Changed 13 months ago by michael

  • Description modified (diff)

I will be patient again and explain one of the reasons this has not been fixed: this does not reproduce very easily. A few people are able to reproduce it easily, most people (we have a large and generally happy Mac user community), including all of our developers who use Macs, are not. So unfortunately, even apart from the fact that we have many other things to work on, we would be unable to do anything here, as we are dependent on people who do have the problem to investigate for us, which so far none of them has been able to do. As I mentioned several times, my personal suspicion is some additional software installed on the Mac, quite possibly something which interacts with the cursor. @opcenter was one of the people who did take some time to look and suggested that "Better Touch Tool", which they are using, might be a candidate.

So anyone genuinely interested in seeing this fixed would do well to take a good look at how their Mac is set up, and what might be different from someone else's Mac, and try changing that/uninstalling pieces of software (it might be something big or something small) to see if that makes the difference, then reporting back. Of course, if this is too much work for anyone I understand if they prefer to use different software, as @cesarcafe did. That said, if I were affected them investigating myself would make more sense to me than obtaining, learning and switching to a complete new tool.

comment:109 Changed 13 months ago by michael

  • Description modified (diff)

comment:110 Changed 12 months ago by cesarcafe

My MacBook Pro has no suspicious third-party software installed. I'm not using Better Touch Tool (but it's a new MBP with TouchBar, if that matters). I've been evaluating a commercial alternative for a month, and it didn't suffer this issue, so I'm buying a license today. I understand @michael preference for investigating the issue rather than moving to a new tool, but I'm on a tight schedule and I needed things working, so moving was the best option for me. Sorry.

comment:111 Changed 12 months ago by michael

Please don't get me wrong. I would like to see this solved for the benefit of the people experiencing it, but you should of course do what makes most sense for you.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use