VBox > 4.3.14 has flicker / slow redrawing of UI elements (regression)

[Michael]

Host: Fedora 20 x86_64 Host video card: NVIDIA 9500 (driver 340.58) Guest: Windows 7 x86_64

Any VirtualBox newer than 4.3.14 causes UI elements to flicker or slow / not redraw when the mouse hovers over them when 3D support is enabled and the 3D driver is installed.

VBox guest additions version does not matter. I can have 4.3.20 guest additions installed on 4.3.14 and no flickering occurs, but upgrading the host binaries to 4.3.16, 4.3.18, or 4.3.20 will induce UI flickering. It causes 3D / Aero to be unusable.

Also see: ​https://forums.virtualbox.org/viewtopic.php?f=7&t=64424&p=305456

[AHti]

Same problem here.

Host : Mageia 5 (cauldron) x86_64 Host video card : nVIDIA Quadro K3000M Guest : Windows 7 32

[BartonC]

I, too, have been seeking a solution for the Win7 guest Aero instability issue since 4.3.14.

My (unsupported) host is 3.16.4-1-ARCH #1 SMP PREEMPT Mon Oct 6 08:22:27 CEST 2014 x86_64 GNU/Linux.

I also use proprietary nVidia driver ([legacy] nvidia-340xx)

Interestingly, I've been able to work around the issue by downgrading only the front end and extensions:

Name           : virtualbox
Version        : 4.3.14-4
Name           : virtualbox-ext-oracle
Version        : 4.3.14-1

Kernel modules are (were) up to date. I'm posting here just prior to an upgrade as I'll probably need to downgrade again, but will take the opportunity to do a little more experimentation.

Name           : virtualbox-guest-iso
Version        : 4.3.18-1
Name           : virtualbox-host-modules
Version        : 4.3.18-1

I'm glad to hear that I won't need to downgrade the guest after moving to 4.3.20.

I've considered that I don't really need Aero all that much, but always end up rejecting that notion. It will be really nice one day to have the post 4.3.14 regression sorted out. Reading ticket#10200 piqued my interest a bit.

Best regards, Barton

UPDATE: I can confirm that the issue remains unchanged for me with

Name           : virtualbox-guest-iso
Version        : 4.3.20-3
Name           : virtualbox-host-modules
Version        : 4.3.20-3

I've also installed intel-ucode on the host and done the Intel INF update on the guest to no avail.

This has been reported to work on a machine similar to mine on the Arch Users Form.

This is an i5 Dell with modern graphics chipset so my next step will be to pull the video card.

UPDATE > 2: SUCCESS!

It turns out that, at some point, VirtualBox stopped playing nicely with NVidia drivers.

I've pulled my video card and reverted to xorg xf86-video-intel (i915) and once again have nice, beautiful Aero theme working.

UPDATE > 3: Further testing: ​One person has tried non proprietary drivers but did NOT have great success.

[universaltourist]

Same problem here. Running virtualbox 4.3.20 on Ubuntu 14.04 host (3.13.0-33-lowlatency kernel amd64) using NVidia GeForce GTX 750Ti with nvidia proprietary driver 343.22. On a Windows 7 client the flickering with Aero occurs. On a Windows 8.1 client and a Ubuntu 14.04 client running on the same host everything works fine.

[AHti]

Hello,

Unfortunately the problem still exists with version 4.3.22.

Host : Mageia 5 (cauldron) x86_64 Host video card : nVIDIA Quadro K3000M with nvidia proprietary driver 346.35 Guest : Windows 7 32

[AHti]

Hello,

And for 4.3.24 version too !

[AHti]

I have tested 4.3.26 today. Problem is still here.

[Frank Mehnert]

So you are talking about the guest UI elements, not UI elements of the VirtualBox GUI, right?

[Michael]

Yes, the guest UI. There is nothing wrong with the VBox GUI.

[AHti]

Yes, the problem is with the guest UI.

[Michael]

This issue is still occurring with VirtualBox 5.0 BETA 1. The flicker occurs with the 4.3.14 additions as well as the 5.0 BETA 1 additions.

[AHti]

This issue is still occuring with 5.0 BETA 2 either with 4.3.26 or 5.0 BETA 2 additions.

[David Crenshaw]

Is anyone still looking at this? I have upgraded again to the latest version of Virtualbox and this still happens.

As stated previously, I am running Ubuntu 12.10 64bit with 2 NVIDIA 560 cards. I have the very latest NVIDIA drivers. I am running Virtualbox 4.3.14.r95030. Also installed is matching guest additions and the matching Extension Pack. I have Windows 7 Ultimate installed and patched up to date. Everything works great with this configuration.

However, If I update VB to any other newer (4.3.26-98988~Ubuntu~precise) version I get the flashing as my mouse passes over windows or icons in the Windows 7 guest. This makes it unusable. Seems like since VB (and its components) are the only changes then it must be VB. If I remove 4.3.26-98988~Ubuntu~precise and reinstall 4.3.14-95030~Ubuntu~precise, everything goes right back to working.

[Perry G]

Adding name to track ticket.

[as123]

I assume the other posters who use the word 'flicker' or 'flash' are seeing what I am seeing. A better description of what I am seeing is a combination of off-screen buffers being displayed before rendering has been completed to them, and stale, out-of-date buffers being shown (before rendering has even started?). I also see the problem with Windows 8.1 guests and some Linux guest desktops too. The graphics card is an NVIDIA GeForce GTX 460.

With Windows 7 as a guest using the VirtualBox WDDM driver, bits of windows go missing. Sometimes a window's border, the chrome, is only partially redrawn. Sometimes the window's contents itself are missing. Even when a window's contents are seemingly fully and correctly composited, the borders of windows that are further down the window stack, and should not be shown, are sometimes drawn over that higher window. With Windows 8.1 as a guest, windows' contents appear to be always redrawn fully, but the chrome from windows lower down the windows stack is still sometimes incorrectly drawn over the top.

Compiz is affected. Unity when using the VirtualBox Chromium driver and MATE with Compiz enabled both have flicker. The flicker with Unity on an Ubuntu 12.04 guest is similar to a Windows 7 guest, with the Unity panel and windows' chrome winking in and out of view. Unity on a Ubuntu 14.04 guest is different. There are never any partial renderings, only out-of-date buffers being shown, so windows will appear to jump backwards in time and then jump forwards. Mutter and the Muffin fork are not affected, so guests using GNOME Shell and Cinnamon have no problem.

With an Ubuntu guest with a non-compositing window manager, host overlay windows for guest applications using OpenGL are affected. Something simple, like mplayer using OpenGL in the guest, is flicker-free. Something more complex, like Google Earth using OpenGL in the guest, will flicker horribly, with most redraws looking like incomplete renderings. With a Windows 7 guest when not using the VirtualBox WDDM driver, OpenGL works perfectly. Go figure.

The guest display corruption is the same on an Ubuntu 10.04 host (kernel 2.6.32, X.org 1.7.6) with NVIDIA Display Driver 304.125 as it is on an Ubuntu 15.04 host (kernel 3.19.0, X.org 1.17.1) with NVIDIA Display Driver 349.16, and every combination of versions in between that I have tried.

I diffed the source code for VirtualBox 4.3.14 and 4.3.16, hoping to see a single-line change where someone had removed a workaround for the NVIDIA driver thinking that would be an optimization. But, there are a lot of changes related to OpenGL. I noticed the introduction of the two definitions CR_VBOX_CAP_CMDBLOCKS_FLUSH and CR_CMDBLOCK_CHECK_FLUSH, so I tried starting with

CR_SERVER_CAPS=15 VirtualBox --startvm ...

but that does not help.

The issues as described above occur with VirtualBox 4.3.16 and every subsequent version so far released, including the three 5.0 betas.

I am very close to giving up on VirtualBox with an NVIDIA GPU. Unfortunately, unlike a previous poster, the CPU in my main desktop machine does not have integrated graphics, although I do have such a machine to hand. The Arch Linux wiki says that Bumblebee has been tested successfully on a desktop PC, so that could be something. That is not a criticism of VirtualBox; I am prepared to change the hardware before the software. My understanding is that 3D acceleration in VirtualBox is still classed as experimental, and so not to be relied upon.

[AHti]

No change with 4.3.28.

[Quickbooks Office]

Replying to AHti:

No change with 4.3.28.

Same here...Its still broken.

[Technologov]

patch for VirtualBox 5.0. Really ugly code.

[Technologov]

Okay, I have written some really ugly patch, that (partially) reverts to v4.3.14 OpenGL state. Aero works with NVIDIA now.

There is no way for Oracle to accept this patch, until it is improved significantly, but no reasons for you to throw away your NVIDIA cards, like "as123" suggested.

Aero patch is part of VirtualBox_TE series; Which stands for Technologov's Edition. (similar to Linux_AC, Alon Cox series)

Build for Linux x64: (based on v5.0.0-BETA4)

​https://drive.google.com/file/d/0BycgkMZbeQOzTUItV3dSd0puZFU/view?usp=sharing

More info: ​https://forums.virtualbox.org/viewforum.php?f=10

-Technologov, 20.May.2015.

[Quickbooks Office]

Replying to Technologov:

Okay, I have written some really ugly patch, that (partially) reverts to v4.3.14 OpenGL state. Aero works with NVIDIA now.

There is no way for Oracle to accept this patch, until it is improved significantly, but no reasons for you to throw away your NVIDIA cards, like "as123" suggested.

Aero patch is part of VirtualBox_TE series; Which stands for Technologov's Edition. (similar to Linux_AC, Alon Cox series)

Build for Linux x64: (based on v5.0.0-BETA4)

​https://drive.google.com/file/d/0BycgkMZbeQOzTUItV3dSd0puZFU/view?usp=sharing

More info: ​https://forums.virtualbox.org/viewforum.php?f=10

-Technologov, 20.May.2015.

Maybe I am doing something wrong, but I cannot apply the patch cleanly. Is my command line correct?

[m1@j VirtualBox-5.0.0_BETA4]$ patch -p2 < vbox-host-AllOpenGL-beta1-v5.0.0-BETA2.patch 
patching file src/VBox/Additions//common/crOpenGL/load.c
patching file src/VBox/Additions//common/crOpenGL/pack/packspu_context.c
Hunk #1 succeeded at 598 (offset 7 lines).
patching file src/VBox/Additions//common/crOpenGL/pack/packspu_getstring.c
patching file src/VBox/Additions//common/crOpenGL/pack/packspu.h
patching file src/VBox/Additions//common/crOpenGL/pack/packspu_misc.c
patching file src/VBox/Additions//common/crOpenGL/pack/packspu_net.c
patching file src/VBox/Additions//common/crOpenGL/pack/packspu_special
patching file src/VBox/GuestHost//OpenGL/include/chromium.h
patching file src/VBox/GuestHost//OpenGL/include/cr_dump.h
patching file src/VBox/GuestHost//OpenGL/include/cr_error.h
patching file src/VBox/GuestHost//OpenGL/include/cr_glstate.h
Hunk #2 succeeded at 268 (offset 1 line).
Hunk #3 succeeded at 283 (offset 1 line).
patching file src/VBox/GuestHost//OpenGL/include/cr_pack.h
patching file src/VBox/GuestHost//OpenGL/include/cr_server.h
patching file src/VBox/GuestHost//OpenGL/include/cr_sortarray.h
patching file src/VBox/GuestHost//OpenGL/include/cr_unpack.h
patching file src/VBox/GuestHost//OpenGL/include/state/cr_texture.h
patching file src/VBox/GuestHost//OpenGL/packer/opcodes.py
patching file src/VBox/GuestHost//OpenGL/packer/pack_beginend.c
patching file src/VBox/GuestHost//OpenGL/packer/pack_bufferobject.c
patching file src/VBox/GuestHost//OpenGL/packer/pack_context.c
patching file src/VBox/GuestHost//OpenGL/packer/packer.py
patching file src/VBox/GuestHost//OpenGL/packer/pack_init.c
patching file src/VBox/GuestHost//OpenGL/packer/pack_lists.c
patching file src/VBox/GuestHost//OpenGL/packer/pack_pixels.c
patching file src/VBox/GuestHost//OpenGL/packer/pack_program.c
patching file src/VBox/GuestHost//OpenGL/packer/pack_shaders.c
patching file src/VBox/GuestHost//OpenGL/packer/pack_swap_texture.c
patching file src/VBox/GuestHost//OpenGL/packer/pack_texture.c
patching file src/VBox/GuestHost//OpenGL/spu_loader/spuload.c
patching file src/VBox/GuestHost//OpenGL/state_tracker/state_diff.c
Hunk #1 succeeded at 593 (offset 9 lines).
Hunk #2 succeeded at 611 (offset 9 lines).
patching file src/VBox/GuestHost//OpenGL/state_tracker/state_framebuffer.c
patching file src/VBox/GuestHost//OpenGL/state_tracker/state.h
patching file src/VBox/GuestHost//OpenGL/state_tracker/state_init.c
patching file src/VBox/GuestHost//OpenGL/state_tracker/state_lists.c
patching file src/VBox/GuestHost//OpenGL/state_tracker/state_texture.c
patching file src/VBox/GuestHost//OpenGL/util/error.c
Hunk #1 FAILED at 174.
Hunk #2 FAILED at 458.
2 out of 2 hunks FAILED -- saving rejects to file src/VBox/GuestHost//OpenGL/util/error.c.rej
patching file src/VBox/GuestHost//OpenGL/util/sortarray.cpp
patching file src/VBox/HostServices//SharedOpenGL/crserver/crservice.cpp
patching file src/VBox/HostServices//SharedOpenGL/crserverlib/presenter/server_presenter.cpp
Hunk #2 succeeded at 952 (offset 21 lines).
Hunk #3 succeeded at 3990 (offset 27 lines).
patching file src/VBox/HostServices//SharedOpenGL/crserverlib/server.h
patching file src/VBox/HostServices//SharedOpenGL/crserverlib/server_lists.c
patching file src/VBox/HostServices//SharedOpenGL/crserverlib/server_main.c
Hunk #1 succeeded at 285 (offset 5 lines).
Hunk #2 succeeded at 387 (offset 5 lines).
Hunk #3 succeeded at 494 (offset 5 lines).
Hunk #4 succeeded at 515 (offset 5 lines).
Hunk #5 succeeded at 3942 (offset -14 lines).
patching file src/VBox/HostServices//SharedOpenGL/crserverlib/server_misc.c
patching file src/VBox/HostServices//SharedOpenGL/crserverlib/server_muralfbo.cpp
Hunk #1 FAILED at 116.
Hunk #2 FAILED at 189.
2 out of 2 hunks FAILED -- saving rejects to file src/VBox/HostServices//SharedOpenGL/crserverlib/server_muralfbo.cpp.rej
patching file src/VBox/HostServices//SharedOpenGL/crserverlib/server_retval.py
patching file src/VBox/HostServices//SharedOpenGL/crserverlib/server_stream.c
patching file src/VBox/HostServices//SharedOpenGL/crserverlib/server_window.c
patching file src/VBox/HostServices//SharedOpenGL/Makefile.kmk
Hunk #2 succeeded at 374 (offset 3 lines).
patching file src/VBox/HostServices//SharedOpenGL/render/renderspu.c
patching file src/VBox/HostServices//SharedOpenGL/render/renderspu_glx.c
patching file src/VBox/HostServices//SharedOpenGL/render/renderspu.h
patching file src/VBox/HostServices//SharedOpenGL/render/renderspu_init.c
patching file src/VBox/HostServices//SharedOpenGL/unpacker/unpack.py
[m1@j VirtualBox-5.0.0_BETA4]$ 

[Technologov]

The code will compile and work, despite errors. I hacked code on BETA2, then applied it to BETA4.

[Frank Mehnert]

Sorry, but this bugtracker is not for discussion such user-provided patches!

[Technologov]

And since "mpack" now policing the old forum, everyone is welcome to the new forum : ​http://www.qumble.org/forum/viewtopic.php?f=2&t=8

or see me on the mailing-lists.

[Technologov]

UPDATE: [22.May] After 3 days of almost sleepless nights, I was able to find the bug ! Fix is related to multi-threading, and I don't understand it's implications fully. And my patch could kill 3D acceleration on any other hosts, so proceed with caution !

I call Oracle to review this patch, release v5.0.0-BETA5 early with a fix, so we could test 3D acceleration on all hosts. (Windows/Mac OS X/Linux) and all GPU vendors (IntelAMD/NVIDIA). And only then back-port fixes to 4.3.x series.

This patch is a clean code (unlike the 1st patch, which was really ugly).

But this bug is worth it !

-"Technologov"

[Technologov]

patch v2. Clean code.

[Quickbooks Office]

Replying to Technologov:

UPDATE: [22.May] After 3 days of almost sleepless nights, I was able to find the bug ! Fix is related to multi-threading, and I don't understand it's implications fully. And my patch could kill 3D acceleration on any other hosts, so proceed with caution !

I call Oracle to review this patch, release v5.0.0-BETA5 early with a fix, so we could test 3D acceleration on all hosts. (Windows/Mac OS X/Linux) and all GPU vendors (IntelAMD/NVIDIA). And only then back-port fixes to 4.3.x series.

This patch is a clean code (unlike the 1st patch, which was really ugly).

But this bug is worth it !

-"Technologov"

I applied the 2nd patch to 4.3.28 and it solves the problem for me.

Thank you.

[Michael]

I can also confirm that the patch eliminates the flickering that I originally reported about.

@Frank, what is the appropriate route to get this discussed and / or fixed now that we know the cause?

[Frank Mehnert]

That finding is definitely interesting but changeset r52261 was done by intention so it has to be examined why it was done and how can it be fixed properly.

[Klaus Espenlaub]

As Frank wrote, I don't think that we (a "we" which includes many people) know the true cause or a sensible way to fix. The define is meant to move rendering unconditionally to a separate thread.

All you found out is that removing out a define (which was introduced before 4.3.16 was released) has a positive effect for some people with an NVIDIA graphics card. We don't know if all NVIDIA users are affected or if it has a negative effect for some. What's totally unknown is the situation for non-NVIDIA graphics cards.

Since this is a compile-time change affecting all 3D drivers on linux, solaris and freebsd we need to at least some feedback by people who haven't noticed significant regressions with 4.3.16 or later.

What makes the situation very tricky is the following: We tracked this change down to a fix for a complex 3D application which a customer is using. Doesn't mean the introduction of this CR_RENDER_FORCE_PRESENT_MAIN_THREAD define is correct (the comment talks about "debugging only"), but it means most likely someone will complain about a regression if this patch goes in. Looks like we have to ask the customer to try with a build where this is removed, to see if they really depend on this change or if the actual fix was elsewhere.

[Perry G]

I can add that a Windows 7 guest does have flicker ( only when aero is enabled ) when an nVidia GPU is used on the host. 3 Different hosts with various nVidia GPUs. That said it is an annoyance and not so much a critical flaw which in my mind would not require a full pull of the changeset but rather some debugging and repair of the code logic. "If then". Just my 2-cents.

[Technologov]

One idea, to reduce potential regressions, is to limit my patch to NVIDIA GPUs and X11 hosts only. And of course make the if-switch real-time, as opposed to #PRE-processor.

(NVIDIA driver for X11 hosts: FreeBSD/Linux/Solaris comes from same source code I'we read)

-Technologov

[Quickbooks Office]

Replying to klaus:

Looks like we have to ask the customer to try with a build where this is removed, to see if they really depend on this change or if the actual fix was elsewhere.

Thanks for the open response and keeping us in the loop.

Did you get any response from the customer?

[FogKnight]

The problem is still there on 4.3.28 on a Fedora 22 host with nVidia Geforce GTX 680M graphics card and latest 346.72 driver.

[AHti]

Nothing new with 5.0 RC3. Problem is still here.

Host : Mageia 5 x86_64 Video card : nVIDIA Quadro K3000M with nvidia proprietary driver 346.72 Guest : Windows 7 32

[fniessen]

The same with 5.0 final. Rolled back to working 4.3.14 again.

Host: Opensuse 13.2 x86_64; nvidia driver 346.72

[ehasis]

I'm facing the same problem with VBox 5.0 final

Video card: nVidia GeForce GTX 660; Host: Windows 8.1 Pro 64 bits, video driver 353.30; Guest: Arch Linux 64 bits, Gnome-Shell 3.16.2

[did-vmonroig]

Same problem with version 5.0.2.

Video card: 01:00.0 VGA compatible controller: NVIDIA Corporation G96 [GeForce 9400 GT] (rev a1)
Host OS: Ubuntu 14.04.3 LTS
Guest OS: Windows 10

[markh]

This is still present in 5.0.6. Is anyone actively seeking feedback on the suitability of the patch, e.g. from the original customer requesting the commit that broke it? Are there any builds available with the patch to test and provide feedback? (64bit Windows)

Video: Nvidia Quadro K1100M (+ Intel HD 4600) Hosts: Windows 8.1, Windows 10 Guest: Ubuntu 15.04

[Hastur]

Issue still very much present in VB 5.0.10.

I'm running a Debian 8 host with GeForce 660 GTX and Ubuntu 15.10 guests and I can observe the "going back in time" effects, as described by as123.

(Very irritating when what you're typing in the terminal appears to be deleted for a second and comes back again.)

[Michael Hansen]

Removing the CR_RENDER_FORCE_PRESENT_MAIN_THREAD define as Technologov suggests does improve the situation, but I notice there's still some barely visible "flicker" artifacts even with the patch. I'm not sure if it's related, but it may just be causing the draw buffer to resolve faster, rather than actually removing the cause of the bug. Or it may be something completely different I'm observing... Willing to do more testing if the devs have any suggestions.

[bmcnoldy]

As another data point, I am having the same problem. My host is CentOS 7 64-bit, with an nVidia Quadro K600 graphics card and nouveau driver. My guest is Windows 7 64-bit. I'm running VB 5.0.10 with the expansion pack and guest additions, with DirectX enabled. I use Google Earth for work, and it is unusable... it either flickers like crazy or totally freezes the whole system eventually. I had the same issue with VB 4.3, but not as bad. I thought I'd upgrade to hopefully fix the problem, but it's actually worse.

I haven't tried the patch yet, because I'm not quite savvy enough to repair any unforeseen issues that it might cause.

[fniessen]

Hi there,
the bug is older than a year and now other OS's than Windows are getting involved to this bug (CentOS 7, OpenSUSE 42, ...)

Are there any changes that this bug get fixed?

Or do I have to draw other consequences out of it and leave VirtualBox.

[Jason.Lynn]

I, too, am afflicted with this problem and have been since this change was made. Would absolutely LOVE to see a permanent fix implemented here. I've been running my VMs without 3D for well over a year now thanks to this issue. Not pleasant. In the meantime, I went ahead and built the VBoxOGLrenderspu module without CR_RENDER_FORCE_PRESENT_MAIN_THREAD and verified that this does indeed clean up the "flicker" (i.e. displaying old buffer data). Looks like I'll be doing this until this is actually fully addressed. Thanks for the band-aid, guys.

System Specs: Ubuntu 15.10, NVidia GeForce GTX 760, AMD FX 8350

[Jason.Lynn]

Bueller?

[Frank Mehnert]

Problem still under investigation.

[Stefan Becker]

Are there any News? I have again Nvidia Cards. With AMD fglrx its working. With Nvidia not.

[Stefan Becker]

Is there really nothing that i can do for you? Something like starting VBOX in DebugMode, changing Nvidia Setting, posting Logs, what else?

Its a really old and annoying bug.

[heavymx]

5.0.20 and nothing? Just to confirm that in the official versions we have not seen any kind of advance!! 5.0.20 and everything remains the same or worst!! I'm the guy that opened by first time the issue in the VB forums ​https://forums.virtualbox.org/viewtopic.php?f=7&t=64424

I have read here about the patch but for some of us, this is some kind annoying or difficult or we don't know how to apply this!! so we expect a final release with this issue solved

Any clue?

I know this excellent software is for free and I want to thank to every developer who works on it

[Stefan Becker]

No advance with 5.1/Beta2. Its old and annoying.

[Jason.Lynn]

Yeah, I simply gave up. It's really a shame as this is EASILY reproducible. Obviously, Oracle has no real motivation to fix this...and why would they? They don't make any money from this. VMware Workstation works great on Linux with NVidia, and it even allows nested virtualization. Goodbye Virtualbox. Thanks for not caring as you lead me to a superior product.

[Michael Thayer]

Just to summarise the situation: we do not currently have free developer time (as in developers with the required skills who are not already taken up with other work) to investigate this bug, much as we understand that it is annoying to the people affected. This situation might change, but that is not something we can promise. Of course, I quite understand that if this means that something else fits any individual's requirements better than VirtualBox then it is a sensible solution to use that instead.

However, the fact that VirtualBox is open source means that users who are interested have another option to get changes made, by doing the work themselves or crowd-sourcing the work. If you go this way of course, please communicate with us before starting and while doing the work, as we hate to see work go to waste due to misunderstandings like mismatches with our development style. Though this is more a fix than a feature, so likely to be easier to integrate.

See also the X11 guest 3D wiki page. Windows guest 3D is not user-maintained, but we are still rather limited in what we can do.

I would kindly request that as of now people do not add unneeded information to this ticket, such as that this is still not fixed or does not work for a given person. However, if you would like to subscribe to the ticket please add a "me too" comment, and we will delete the comment and add your nickname to the "CC" list.

[markh]

Hi Michael,

Many thanks for your clear reply on this and explanation of the current state of the guest 3D as user-supported. It's great to hear that you still welcome open source contributions.

For this particular bug a single line change has been provided as a patch which removes a #define for limiting multi-threaded rendering. That was originally added as part of a commit which has been described in the comments above as being done for "debugging only", but for an obscure customer reported problem. The same commit also removed an assertion call, without claiming which of the two changes were significant. Several people here have commented that the patch is beneficial, but there are also comments rightfully stating that it would be improper to make the change without further testing, particularly by people with other hardware that isn't currently affected by this issue.

The problem is that it's almost impossible to convince people to patch and build from source something is large as virtualbox to test a change for a bug that doesn't affect them. Therefore, would it be possible to get a pre-built test distribution (ideally, on all host platforms) to ask the community to test more widely, with more 3d applications? Or simply include the one line patch in a beta release, which would give even more feedback?

[Michael Thayer]

Sounds like a reasonable request. I was unable to prepare RPM or Deb installers unfortunately. These links will be valid for two weeks, though I could do more builds if you can persuade me that people will be testing them.

https://www.virtualbox.org/download/testcase/VirtualBox-5.1.1-108727-Win.exe https://www.virtualbox.org/download/testcase/VirtualBox-5.1.1-108727-OSX.dmg https://www.virtualbox.org/download/testcase/VirtualBox-5.1.1-108727-Linux_x86.run https://www.virtualbox.org/download/testcase/VirtualBox-5.1.1-108727-Linux_amd64.run https://www.virtualbox.org/download/testcase/VirtualBox-5.1.1-108727-SunOS.tar.gz

[Michael]

Thanks for the build. I have tested it on two systems and do not see flicker. No other wrong behavior is seen.

Host System 1: Fedora 23, NVIDIA 340.96 driver (9500 GT)
Guest System 1: Windows 7 64-bit Professional

Host System 2: Fedora 24, Mesa 12.0.0 (Intel Haswell 5100 Iris)
Guest System 2: Windows 8.1 64-bit Home

[Perry G]

@michael,

I have been commenting the "#define CR_RENDER_FORCE_PRESENT_MAIN_THREAD" off and on for about a year against various builds from SVN and it does stop the flicker in Windows-7 with aero and has no effect as far as I can tell on other guest ( Linux, Solaris, & Windows ) My main concern about leaving it commented out is that if you do update something that this would effect it could be really hard to find. How this would effect your paying customer that needed this define seems to be the real issue to me. Wish I was better at programming so I could help more, but sadly no, those years are behind me. I remember just enough to get in trouble most of the time these days. [ host = Linux and nVidia GPU ]

[Michael Thayer]

Could anyone building themselves (Linux host) try the following patch, without (!) the "#define CR_RENDER_FORCE_PRESENT_MAIN_THREAD" removed?

Just to be absolutely clear: Alexey's patch should not be applied when you try this, and the line "#define CR_RENDER_FORCE_PRESENT_MAIN_THREAD" should be present in renderspu_glx.c.

Index: src/VBox/HostServices/SharedOpenGL/render/renderspu_glx.c
===================================================================
--- src/VBox/HostServices/SharedOpenGL/render/renderspu_glx.c	(revision 108778)
+++ src/VBox/HostServices/SharedOpenGL/render/renderspu_glx.c	(working copy)
@@ -1952,8 +1952,8 @@
         crMemset(&event, 0, sizeof (event));
         event.type = Expose;
         event.xexpose.window = window->window;
-        event.xexpose.width = window->BltInfo.width;
-        event.xexpose.height = window->BltInfo.height;
+        event.xexpose.width = 0;
+        event.xexpose.height = 0;
         status = XSendEvent(render_spu.pCommunicationDisplay, render_spu.WinCmdWindow.window, False, 0, &event);
         if (!status)
         {

[Perry G]

Sure. I will here in a bit.

[Perry G]

@michael,

I removed the comment and applied your patch. At first it looked like it was going to work, but sadly no. I will leave my build env as is for now in case you want me to test more.

[Perry G]

I might add that it does work differently now. There are times when it does not flicker, and then times when it does, so that is an improvement of sorts I guess.

[Michael Thayer]

Thanks for trying that. If I understand right, it is better than unpatched, but not as good as with the "#define CR_RENDER_FORCE_PRESENT_MAIN_THREAD" line removed.

[fniessen]

me too

[Michael Thayer]

Another patch to try. I'm afraid you should not get your hopes up too high though. I am not very familiar with the code, I am just following up on a hunch on what is wrong on the part of a developer who has since left the company, and which I discovered yesterday. I understand the code well enough to write a patch to test the idea but not well enough to quickly produce more if it fails.

For those who are interested, the idea is that using an expose event to notify the rendering thread might cause unwanted side effects when other listeners react to it. I am not quite convinced, as I don't know who those are likely to be (I do understand X11 reasonably well). Testing nearly always beats reasoning though, so here it is.

Index: src/VBox/HostServices/SharedOpenGL/render/renderspu.h
===================================================================
--- src/VBox/HostServices/SharedOpenGL/render/renderspu.h	(revision 108778)
+++ src/VBox/HostServices/SharedOpenGL/render/renderspu.h	(working copy)
@@ -199,6 +199,10 @@
         CR_RENDER_WINCMD_TYPE_NOP,
 	/* exit Win Cmd thread */
 	CR_RENDER_WINCMD_TYPE_EXIT,
+	/* Execute a "present" operation (if I understand this correctly).
+	 * This command is handled specially as it was moved from another
+	 * code path. */
+	CR_RENDER_WINCMD_TYPE_PRESENT,
 } CR_RENDER_WINCMD_TYPE;
 
 typedef struct CR_RENDER_WINCMD
Index: src/VBox/HostServices/SharedOpenGL/render/renderspu_glx.c
===================================================================
--- src/VBox/HostServices/SharedOpenGL/render/renderspu_glx.c	(revision 108778)
+++ src/VBox/HostServices/SharedOpenGL/render/renderspu_glx.c	(working copy)
@@ -517,6 +517,26 @@
                 CRASSERT(event.xclient.window == render_spu.WinCmdWindow.window);
                 if (event.xclient.window == render_spu.WinCmdWindow.window)
                 {
+                    /* This code is handled seperately as it was moved from a different
+                     * path. */
+                    if (event.xclient.message_type == CR_RENDER_WINCMD_TYPE_PRESENT)
+                    {
+                        Window hWin;
+                        memcpy(&hWin, event.xclient.data.b, sizeof (hWin));
+                        WindowInfo *pWindow = (WindowInfo*)crHashtableSearch(render_spu.pWinToInfoTable, hWin);
+                        if (pWindow)
+                        {
+                            const struct VBOXVR_SCR_COMPOSITOR * pCompositor;
+
+                            pCompositor = renderspuVBoxCompositorAcquire(pWindow);
+                            if (pCompositor)
+                            {
+                                renderspuVBoxPresentCompositionGeneric(pWindow, pCompositor, NULL, 0, false);
+                                renderspuVBoxCompositorRelease(pWindow);
+                            }
+                        }
+                        break;
+                    }
                     if (render_spu.WinCmdAtom == event.xclient.message_type)
                     {
                         CR_RENDER_WINCMD *pWinCmd;
@@ -527,25 +547,6 @@
                 
                 break;
             }
-            case Expose:
-            {
-                if (!event.xexpose.count)
-                {    
-                    WindowInfo *pWindow = (WindowInfo*)crHashtableSearch(render_spu.pWinToInfoTable, event.xexpose.window);
-                    if (pWindow)
-                    {
-                        const struct VBOXVR_SCR_COMPOSITOR * pCompositor;
-
-                        pCompositor = renderspuVBoxCompositorAcquire(pWindow);
-                        if (pCompositor)
-                        {
-                            renderspuVBoxPresentCompositionGeneric(pWindow, pCompositor, NULL, 0, false);
-                            renderspuVBoxCompositorRelease(pWindow);
-                        }
-                    }
-                }
-                break;
-            }
             default:
                 break;
     	}
@@ -1950,11 +1951,12 @@
 //        renderspuVBoxPresentBlitterEnsureCreated(window, 0);
 
         crMemset(&event, 0, sizeof (event));
-        event.type = Expose;
-        event.xexpose.window = window->window;
-        event.xexpose.width = window->BltInfo.width;
-        event.xexpose.height = window->BltInfo.height;
-        status = XSendEvent(render_spu.pCommunicationDisplay, render_spu.WinCmdWindow.window, False, 0, &event);
+        event.type = ClientMessage;
+        event.xclient.window = render_spu.WinCmdWindow.window;
+        event.xclient.message_type = CR_RENDER_WINCMD_TYPE_PRESENT;
+        event.xclient.format = 8;
+        memcpy(event.xclient.data.b, &window->window, sizeof (window->window));
+        status = XSendEvent(render_spu.pCommunicationDisplay, render_spu.WinCmdWindow.window, False, StructureNotifyMask, &event);
         if (!status)
         {
             WARN(("XSendEvent returned null"));

[Perry G]

@michael,

Sorry my friend but this too does not work. I am more than willing to test anything else you might want to throw my way, and I can get by without it since I really don't do Windows any longer, so it is just an assistance to you and for the ones that do not compile their own versions and can not build with the patch. Feel free to contact me if you want to test anything else.

[Stefan Becker]

I checked the .run Installer from last week.

The machine is an Intel i5 with Nvidia GT 730. Host OS is Suse Leap 42.1 / 64 Bit. Nvidia Driver 3667.27.

Flickering on guests from Win 7, 8.1, 10 seems to be resolved.

I must build another machine on the weekend with an Pentium Processor and Nvidia 6x Card. This card was before the one with the most Problems. I will report later.

I cant check the Patches directly. At the moment with my Suse Machines i cant compile VBOX myself.

[Michael Thayer]

Added mpkossen to CC list.

[Stefan Becker]

Yesterday i built a new Desktop PC. Intel Pentium G3250, Nvidia GT 610. OS is OpenSuse Leap, Nvidia Driver as before.

With the Version above there is no Problem anymore.

So for me with this Patch the problem is resolved.

Would be great to add this patch in the Source Tree. Maybe not perfect, but at the moment the best solution.

[Michael Thayer]

If you are talking about the patch reverting the "#define CR_RENDER_FORCE_PRESENT_MAIN_THREAD" line, I think we have made it clear that we cannot do that, as a customer depends on it. This will not get fixed in the foreseeable future unless someone with the right programming skills debugs it (or another customer needs it fixed). We simply do not have free developer resources to analyse this ourselves now.

[Stefan Becker]

I mean the .run Installer from #50. Whatever it is, it works perfectly.

[Michael Thayer]

That is the one I mean. We already know that it fixes the problem described here for some people, and that it breaks a customer set-up which we do not want to break. I think that the person who asked for the build was interested in investigating what it broke, not the fact described that it fixes the problem for some people.

[lod911]

Hi

I have the same problem, but with a Radeon Card. I read this bug and saw, that the Oracle developers don't have time to solve this problem or couldn't because of a paying customer. I understand that. But how about implementing a switch where default is, that it works for the paying customer(s) and with a flag (maybe over the VBoxManage CLI) it's then possible to set the "#define CR_RENDER_FORCE_PRESENT_MAIN_THREAD"? Later maybe even as a preference in the GUI?

Unfortunately, I'm not the developer who can implementing something like this. But maybe someone out there could do this, so it's not necessary to build always a own version with this patch....and all are happy? Or would this not just easy as I think?

Regards

[Michael Thayer]

Quoting Klaus on ticket #15758:comment:19

Would anyone out there volunteer to provide a variant of the "fix" which performs the check at runtime (instead of proposing a compile time tweak)? It doesn't really matter what way of runtime check is used, as long it correctly triggers the two different code paths. The VirtualBox team is working on other stuff at the moment, and fixing the 'old' 3D code (which we consider in general unfixable, aiming to replace it wholesale) is so low priority that I can't see it happening in the time frame for which the people running into this issue are hoping.

[gojul]

Okay in that case a possible fix would consist in allowing the workaround through a given environment variable or some checkbox, disabled by default.

I know it is not as clean as a proper fix for your paying customer (yup I've come accross this but then no more news from what I read in the article) but at least it would solve the issue for most of us.

[Cédric Belin]

me too

[Piotr Filiciak]

CR_RENDER_FORCE_PRESENT_MAIN_THREAD as environment variable

[Piotr Filiciak]

Patch cr_render_force_present_main_thread_runtime.patch is a solution for comment:68.

You have to run VirtualBox with environment variable:

CR_RENDER_FORCE_PRESENT_MAIN_THREAD=0 VirtualBox

Without environment variable it should work as before.

[Chris Sherlock]

Can this be implemented into a release? Would be very helpful.

[raefe]

Me too /GPU Nvidia GeForce GTX 560

[Klaus Espenlaub]

The patch looks plausible (makes the code even less readable, which I thought was really hard - but in this code area I don't consider this a stopper any more). Increased the probability of this making it into a release considerably.

[Klaus Espenlaub]

All official VirtualBox builds starting with r120678 (for trunk it's a bit earlier, r120672) contain a change inspired by the provided patch. Turns out that the Windows code has a similar tweak which is now integrated the same way. I have the feeling that some people on Windows (where the default is the opposite) also need the possibility to force this special way of presenting the rendered result.

Just get the newest builds from Testbuilds until a new release is published.

This works exactly like mentioned in comment 71. Keep in mind that this is not a 100% reliable way to set the environment variable (it works only if absolutely nothing vbox related was running, i.e. VBoxSVC was not present). On Windows it needs changing the user's env variables in control panel.

[gojul]

I think it would be better to create a checkbox for this rather than relying on an env variable which is really "hacky".

[Socratis]

Replying to gojul:

I think it would be better to create a checkbox for this rather than relying on an env variable which is really "hacky".

Have you seen the solution? Have you read the debate? Do you realize how many people are affected? (hint: not that many overall)

You think that investing time in polishing the UI, for this untested, unproven hack is the wisest investment of resources at this point in time? If and when this proves to work as a proof of concept, then I believe that there are better ways to incorporate this. But for now, they're simply looking for a "it works"/"it doesn't work" kind of response...

[gojul]

Replying to socratis:

Replying to gojul:

I think it would be better to create a checkbox for this rather than relying on an env variable which is really "hacky".

Have you seen the solution? Have you read the debate? Do you realize how many people are affected? (hint: not that many overall)

You think that investing time in polishing the UI, for this untested, unproven hack is the wisest investment of resources at this point in time? If and when this proves to work as a proof of concept, then I believe that there are better ways to incorporate this. But for now, they're simply looking for a "it works"/"it doesn't work" kind of response...

I've read it yup. And yes as a POC an environment variable is fine. I was meaning in a long term.

[Iain Waddell]

I have been running v5.1.32 of VirtualBox. Today I installed a NVidia graphics card (MSI GT 1030) to replace my Intel integrated graphics (HD4600) and found this thread due to all the display flickering.

I installed VirtualBox-5.1.33-120685-Win.exe on my host (Windows 7 Pro SP1) and set the environment variable:

CR_RENDER_FORCE_PRESENT_MAIN_THREAD=0 VirtualBox

and installed these guest additions: Oracle_VM_VirtualBox_Extension_Pack-5.1.33-120675.vbox-extpack

This had no effect, so I installed VirtualBox-5.2.7-120865-Win.exe and Oracle_VM_VirtualBox_Extension_Pack-5.2.7-120822.vbox-extpack but it didn't make any difference.

I'm still getting lots of flickering. I've not noticed any difference.

[Klaus Espenlaub]

Replying to sixeyes:

I have been running v5.1.32 of VirtualBox. Today I installed a NVidia graphics card (MSI GT 1030) to replace my Intel integrated graphics (HD4600) and found this thread due to all the display flickering.

I installed VirtualBox-5.1.33-120685-Win.exe on my host (Windows 7 Pro SP1) and set the environment variable:

CR_RENDER_FORCE_PRESENT_MAIN_THREAD=0 VirtualBox

and installed these guest additions: Oracle_VM_VirtualBox_Extension_Pack-5.1.33-120675.vbox-extpack

This had no effect, so I installed VirtualBox-5.2.7-120865-Win.exe and Oracle_VM_VirtualBox_Extension_Pack-5.2.7-120822.vbox-extpack but it didn't make any difference.

I'm still getting lots of flickering. I've not noticed any difference.

The instructions above (starting the manager GUI with env variable tweaks) were meant for Linux. I don't even know if the syntax works on Windows cmd.exe, I strongly suspect it doesn't. Either way, passing the environment variable this way to a VM process (and that's the only place where it's checked) does NOT work ever on Windows due to how COM works. You need to put this environment variable in the user profile settings (don't ask me where Microsoft misplaced this on recent Windows versions).

[Socratis]

Replying to klaus:

I don't even know if the syntax works on Windows cmd.exe, I strongly suspect it doesn't.

No it doesn't. The proper syntax would be:

set CR_RENDER_FORCE_PRESENT_MAIN_THREAD=0

and it should work (in theory) if you launch "VirtualBox.exe" from the same Command Prompt.

You need to put this environment variable in the user profile settings (don't ask me where Microsoft misplaced this on recent Windows versions).

Control Panel » (User Accounts and Family Safety ») User Accounts » Change my environment variables (on the left side). Click "New...", set "Variable name:" to "CR_RENDER_FORCE_PRESENT_MAIN_THREAD", set "Variable value:" to "0".

Or you can simply put "Variable" in the search box of the Control Panel... ;)

[Cédric Belin]

I'm on Ubuntu 17.10 (x64) with VirtualBox 5.2.6.

I've set the "CR_RENDER_FORCE_PRESENT_MAIN_THREAD" environment variable to "0" in the "/etc/environment" file (i.e. a system-wide environment variable).

My graphic card is a NVidia GeForce GT 750M with NVidia Prime driver 384.111. When I use the NVidia GPU, the flickering is still there. When I switch the GPU to Intel, the flickering disappears.

Meanwhile, I saw that a new version of VirtualBox was released: I've upgraded it to version 5.2.8, and now the flickering has also disappeared with NVidia GPU! So, for me, the issue is resolved :o)

[proximous]

This fix works for me with VirtualBox 5.2.8. My host is Linux Mint 18.3, with a Dell Precision Laptop and NVidia graphics. Verified my Windows 10 guest flickers without the CR_RENDER_FORCE_PRESENT_MAIN_THREAD=0, and with CR_RENDER_FORCE_PRESENT_MAIN_THREAD=0, the problem is gone. Thanks for adding this fix! Would love to see this become an easier to select option in the future, but certainly good enough for me now.

[Michael]

As the original reporter, who reported this 3 years ago, THANK YOU. Thank you for finally applying a solution. This is an acceptable solution for now, which works for me and others, but we would love to have an easier option to toggle and possibly learn if the 3D code could be further inspected to be fixed to not require a toggle at all.

[gojul]

Thanks for the fix, it just works fine.

In a long term I think of some checkbox in an advanced tab. Anyway by just creating a file w/ the environment variable in /etc/profile.d the issue is gone. I only see a bit of blinking effect when several Windows VMs are started, but it is rather minimal compared to what it was.

Config : Debian 9.4 AMD64 + NVidia blob 384.111.

[michalkvasnicka]

Thanks for fix, but ...

1. I still see any minor problems (icon rendering is not perfortmed well, for example)
2. why is this problem still (after 3 years!!!) unsolved in VirtualBox releases???

[Iain Waddell]

Replying to klaus:

Replying to sixeyes:

I have been running v5.1.32 of VirtualBox. Today I installed a NVidia graphics card (MSI GT 1030) to replace my Intel integrated graphics (HD4600) and found this thread due to all the display flickering.

I installed VirtualBox-5.1.33-120685-Win.exe on my host (Windows 7 Pro SP1) and set the environment variable:

CR_RENDER_FORCE_PRESENT_MAIN_THREAD=0 VirtualBox

and installed these guest additions: Oracle_VM_VirtualBox_Extension_Pack-5.1.33-120675.vbox-extpack

This had no effect, so I installed VirtualBox-5.2.7-120865-Win.exe and Oracle_VM_VirtualBox_Extension_Pack-5.2.7-120822.vbox-extpack but it didn't make any difference.

I'm still getting lots of flickering. I've not noticed any difference.

The instructions above (starting the manager GUI with env variable tweaks) were meant for Linux. I don't even know if the syntax works on Windows cmd.exe, I strongly suspect it doesn't. Either way, passing the environment variable this way to a VM process (and that's the only place where it's checked) does NOT work ever on Windows due to how COM works. You need to put this environment variable in the user profile settings (don't ask me where Microsoft misplaced this on recent Windows versions).

I set the environment variable as a system environment variable in Windows 7 (my host) and installed both v5.1.34 and v5.2.8 and it didn't work. I still have flickering in both versions

The system environment variable is available to all users, so should be picked up by every executable running in Windows.

[Socratis]

Did you happen to read my comment, right after Klaus' comment?

I don't even know if the syntax works on Windows cmd.exe, I strongly suspect it doesn't.

No it doesn't. The proper syntax would be:

set CR_RENDER_FORCE_PRESENT_MAIN_THREAD=0

and it should work (in theory) if you launch "VirtualBox.exe" from the same Command Prompt.

You need to put this environment variable in the user profile settings (don't ask me where Microsoft misplaced this on recent Windows versions).

Control Panel » (User Accounts and Family Safety ») User Accounts » Change my environment variables (on the left side). Click "New...", set "Variable name:" to "CR_RENDER_FORCE_PRESENT_MAIN_THREAD", set "Variable value:" to "0".

Replying to sixeyes:

I set the environment variable as a system environment variable in Windows 7 (my host) and installed both v5.1.34 and v5.2.8 and it didn't work. I still have flickering in both versions

And it doesn't work? What if you open a Command Prompt and you type "set"? Is the "CR_RENDER_FORCE_PRESENT_MAIN_THREAD" present and set properly?

It may simply be that the issue is not the same underlying one as the one originally reported in the ticket, but something entirely different.

[Iain Waddell]

Replying to socratis:

Did you happen to read my comment, right after Klaus' comment?

I don't even know if the syntax works on Windows cmd.exe, I strongly suspect it doesn't.

No it doesn't. The proper syntax would be:

set CR_RENDER_FORCE_PRESENT_MAIN_THREAD=0

and it should work (in theory) if you launch "VirtualBox.exe" from the same Command Prompt.

You need to put this environment variable in the user profile settings (don't ask me where Microsoft misplaced this on recent Windows versions).

Control Panel » (User Accounts and Family Safety ») User Accounts » Change my environment variables (on the left side). Click "New...", set "Variable name:" to "CR_RENDER_FORCE_PRESENT_MAIN_THREAD", set "Variable value:" to "0".

Replying to sixeyes:

I set the environment variable as a system environment variable in Windows 7 (my host) and installed both v5.1.34 and v5.2.8 and it didn't work. I still have flickering in both versions

And it doesn't work? What if you open a Command Prompt and you type "set"? Is the "CR_RENDER_FORCE_PRESENT_MAIN_THREAD" present and set properly?

It may simply be that the issue is not the same underlying one as the one originally reported in the ticket, but something entirely different.

I set the environment variable, as described, as a Windows SYSTEM environment variable, not a USER environment variable. This means it's shared by everyone. So the environment variable is present in ALL command prompts and all processes started from my desktop or any command prompt.

While researching the problem I discovered another post on the problem. It indicated that I could turn off 3D rendering without upsetting Windows 10, so I've done that, and now I have no more flickering.

It would be nice to have a fix for the issue but I've set the environment variable and it didn't have any effect. Perhaps in the future a setting in the GUI will be added and I can try that?

[Mirji]

Maybe this helps you on Windows 10 host if you have an NVIDIA card:

• Download Nvidia Inspector
• Start nvidiaProfileInspector.exe
• Create a new profile and name it VirtualBox
• Add virtualbox.exe as application to the new profile Change: Since VirtualBox 6.0 you have to add virtualboxvm.exe
• Scroll down the list and change the following two entries in the "Other" section:
  1. Buffer-flipping mode: 0x00000001 OGL_FORCE_BLIT_ON
  2. OpenGL default swap interval: 0xF0000000 OGL_DEFAULT_SWAP_INTERVAL_FORCE_OFF
• Apply changes

This eliminates the flickering for me in VirtualBox fullscreen mode with 3D acceleration enabled

[nyloc]

On linux this Bug seems to be reintroduced with the "new" VBoxSVGA Graphics-Stack. I'm running VBox 6.0.4 on ArchLinux with an nVidia 1080 GTX and get the flickering even with CR_RENDER_FORCE_PRESENT_MAIN_THREAD=0.

Switching back to VBoxVGA solved the problem for now, but it would be nice if a workaround could be implemented for VBoxSVGA so I could use my graphics potential a bit better in the VM.

-- Update -- I think I was a bit too quick claiming that it works with VBoxVGA, there is a lot less flickering than with VBoxSVGA, but it is still there even with the environment variable set in my zsh config.

[jejay]

Just registered to confirm the last comment, as I have the same problem.

Host: Ubuntu 18.04, NVIDIA Quadro RTX 5000, Driver Version: 418.56 Guest: Windows 10 Pro, Guest addons installed (full install).

The environment variable CR_RENDER_FORCE_PRESENT_MAIN_THREAD=0 is set in /etc/enviroment.

[gojul]

Same problem here. There's much less flickering with VBoxSVGA but some apps are not rendered at all, for example Skype.

[andreymal]

The problem is still present with VirtualBox 6.0.12, VBoxSVGA and Nvidia GeForce 840M(+Optimus) - all transparent areas (e.g. Start Menu) are flickering or just black. ​https://youtu.be/ixYWsl7ktDg?t=1m8s

VboxVGA still works fine with CR_RENDER_FORCE_PRESENT_MAIN_THREAD=0

[Bart Grzybicki]

I can confirm this bug still exists in 6.0.14 released two days ago when I use new VBoxSVGA driver. When I switch to VboxVGA driver and use CR_RENDER_FORCE_PRESENT_MAIN_THREAD=0 set in /etc/enviroment, no flickering at all.

Host:

• Dell Latitude 5501
• Nvidia GeForce MX150 (with nvidia-driver-430)
• Ubuntu 18.04.3 LTS
• kernel: 5.0.0-1024-oem-osp1

Guest:

• Windows 10 1903
• Two virtual displays

Since the VBoxVGA is marked as deprecated, this flickering problem should be resolved for VBoxSVGA driver also.

For the moment, using the above workaround is sufficient, but I don't how long VBoxVGA will be available in next VirtualBox releases.

[Socratis]

Replying to bartgee:

For the moment, using the above workaround is sufficient, but I don't how long VBoxVGA will be available in next VirtualBox releases.

Just to clarify a couple of things:

1. The above workaround is for VBoxVGA only.

2. VBoxVGA+3D acceleration is going nowhere with the 6.0.x releases. You can always stick with that version, which is going to be supported for a long time.

3. VBoxVGA+3D is going to be deprecated, not VBoxVGA alone. It's the 3D part that's going away.

4. If you want to to see VBoxVGA+3D deprecated and work with VBoxSVGA+3D, you need to be testing the ​6.1.0beta, otherwise you're comparing apples to oranges.

[gojul]

Hi,

Issue is still there with VirtualBox 6.1.2.

Workaround for Windows 7 : do not install 3D acceleration. Unfortunately it won't work for Windows 8 and 10 as the checkbox is disabled.

With the glitch Windows 8.1 is barely usable but Windows 10 does not work at all.

Using VBoxSVGA for all three.

Additional thing : for Vista VBoxSVGA is disabled which is weird.

[api]

No matter the host is ubuntu or windows, the windows7 on vm need a windows update patch:​kb2670838

Release Date: February 26, 2013

The Platform Update for Windows 7 enables improved features and performance on Windows 7 SP1 and Windows Server 2008 R2 SP1. It includes updates to the following components: Direct2D, DirectWrite, Direct3D, Windows Imaging Component (WIC), Windows Advanced Rasterization Platform (WARP), Windows Animation Manager (WAM), XPS Document API , the H.264 Video Decoder and the JPEG XR Codec.