Page 1 of 1
[Bug] Major VSync/Tearing
Posted: 14. Nov 2014, 23:32
by pt__
On OS X Yosemite, Retina MacBook Pro 13" (Late 2014), with Ubuntu 14.10 guest. No discrete graphics card.
When moving windows around or scrolling, there is constant visual tearing. I believe this is because there is no vsync.
Parallels 10 has an "enabled vsync" option; with this enabled, there is no tearing when using Parallels. With it disabled, there is tearing. In VirtualBox, there is no such checkbox.
Re: [Bug?] Visual tearing (no vsync?) with Ubuntu 14.xx gues
Posted: 21. Jan 2015, 21:45
by pt__
Any update on this?
Using VirtualBox on OS X is very laggy because of this and it is very hard to e.g. read content while scrolling due to choppy screen updates.
Re: [Bug] Major VSync/Tearing
Posted: 28. Jan 2015, 17:01
by loukingjr
I'm going to assume you installed the guest additions in Ubuntu and you are using VB 4.3.20.
I have multiple non-Retina Macs most of which have Ubuntu 14.10 installed as guests. There is no tearing in any of them. Parallels and VMWare directly support Retina displays whereas VirtualBox does not.
You might try playing with the scaling settings for your MBP.
Re: [Bug] Major VSync/Tearing
Posted: 4. Mar 2015, 01:41
by pt__
I now have VB 4.3.22, but I the issue occurs on 4.3.20 as well. Yes I do have the guest additions installed. I have created many new VMs to test this and they all have the same issue.
I have tried disabling scaling (e.g. by using an external monitor or by setting OS X to a non-HiDPI resolution using a third party tool). The issue remains.
To reproduce: Open a "Files" (nautilus) window. Resize the window so that it is tall. Drag the window slowly from the left side of the screen to the right side of the screen. Look at the left edge of the window (including the shadow). You will see that it tears, as if "chunks" of the window are being redrawn at slightly different times. Immediately compare this with VMWare Fusion or Parallels and you will see that the dragging is *much* smoother. This immediate comparison also shows that in VirtualBox the updates look like they are at a lower frames per second (perhaps <= 20FPS) while VMWare and Parallels look more like 60FPS. It almost seems like the tearing itself causes low FPS, as if redraws are happening sporadically and are thus inefficient. This is sometimes easier to see when you drag windows a bit faster.
Re: [Bug] Major VSync/Tearing
Posted: 4. Mar 2015, 14:10
by loukingjr
Just searching through the web it seems tearing occurs with Ubuntu and/or Compiz even on metal to some degree depending on video cards. As far as why the two other hypervisors you mentioned seem "smoother". One explanation would be both of them license certain Apple APIs not available in VirtualBox because of the cost. That's not a bug.
Re: [Bug] Major VSync/Tearing
Posted: 4. Mar 2015, 15:26
by pt__
Do you have a source for the licensing of "certain Apple APIs"? Or was it just a guess? I can't think why any weird API would be needed to fix this issue (it is just drawing to the screen without tearing, which all apps and games on OS X seem to be able to do just fine) nor how it would be enforced (you can call any built-in OS X function however you want, unless your app is in the OS X App Store).
Re: [Bug] Major VSync/Tearing
Posted: 4. Mar 2015, 17:02
by loukingjr
I know someone at VMWare. I can't help what you can't think.
BTW, the reason Fusion and Desktop still don't support 3D acceleration for OSX guests is because there are still negotiations over access to other necessary APIs which I assume you can't think of either.
Re: [Bug] Major VSync/Tearing
Posted: 6. Mar 2015, 20:05
by pt__
I did try looking into this, but I don't have any experience with the source code of VirtualBox (or any VM software) and obviously it is a complex beast.
It looks like it may be necessary to set "NSOpenGLCPSwapInterval" to "1" on the "NSOpenGLContext". It looks like this used to be done in an older version of VirtualBox, but it is not done any more. Or, perhaps there is a higher level parameter or function (e.g. on NSWindow) that is relevant -- I am not sure if an OpenGL context is used for the display output, but I assume it might be, even if it is implicit. Apparently, when this parameter is 1 buffer swaps will block until the screen is about to be refreshed.
On the other hand, redraws on the OS X frontend seems quite slow and laggy which may remain even if the tearing is fixed. If so, then I guess more substantial changes (e.g. a re-write of OS X specific parts) would be better.