VirtualBox

Ticket #13653 (new defect)

Opened 3 years ago

Last modified 2 months ago

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

Reported by: mooninite Owned by:
Priority: major Component: 3D support
Version: VirtualBox 4.3.20 Keywords: flickering
Cc: mpkossen Guest type: Windows
Host type: Linux

Description

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

Attachments

vbox-host-AllOpenGL-beta1-v5.0.0-BETA2.patch Download (140.7 KB) - added by Technologov 2 years ago.
patch for VirtualBox 5.0. Really ugly code.
vbox-NVIDIA-fix-v2.patch.txt Download (683 bytes) - added by Technologov 2 years ago.
patch v2. Clean code.

Change History

comment:1 Changed 3 years ago by AHti

Same problem here.

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

comment:2 Changed 3 years ago by 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.

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

comment:3 Changed 3 years ago by 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.

comment:4 Changed 3 years ago by 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

comment:5 Changed 3 years ago by AHti

Hello,

And for 4.3.24 version too !

comment:6 Changed 3 years ago by AHti

I have tested 4.3.26 today. Problem is still here.

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

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

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

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

comment:9 Changed 3 years ago by AHti

Yes, the problem is with the guest UI.

comment:10 Changed 3 years ago by mooninite

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.

comment:11 Changed 3 years ago by AHti

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

comment:12 Changed 2 years ago by dccrens

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.

comment:13 Changed 2 years ago by Perryg

Adding name to track ticket.

comment:14 Changed 2 years ago by 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.

comment:15 follow-up: ↓ 16 Changed 2 years ago by AHti

No change with 4.3.28.

comment:16 in reply to: ↑ 15 Changed 2 years ago by quickbooks

Replying to AHti:

No change with 4.3.28.

Same here...Its still broken.

Changed 2 years ago by Technologov

patch for VirtualBox 5.0. Really ugly code.

comment:17 follow-up: ↓ 18 Changed 2 years ago by 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.

comment:18 in reply to: ↑ 17 Changed 2 years ago by quickbooks

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]$ 

comment:19 Changed 2 years ago by Technologov

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

comment:20 Changed 2 years ago by frank

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

comment:21 Changed 2 years ago by 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.

comment:22 follow-up: ↓ 23 Changed 2 years ago by 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"

Changed 2 years ago by Technologov

patch v2. Clean code.

comment:23 in reply to: ↑ 22 Changed 2 years ago by quickbooks

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.

comment:24 Changed 2 years ago by mooninite

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?

comment:25 Changed 2 years ago by frank

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.

comment:26 follow-up: ↓ 29 Changed 2 years ago by klaus

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.

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

comment:27 Changed 2 years ago by Perryg

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.

comment:28 Changed 2 years ago by 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

comment:29 in reply to: ↑ 26 Changed 2 years ago by quickbooks

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?

comment:30 Changed 2 years ago by 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.

comment:31 Changed 2 years ago by 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

comment:32 Changed 2 years ago by 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

comment:33 Changed 2 years ago by 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

comment:34 Changed 2 years ago by 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

comment:35 Changed 2 years ago by 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

comment:36 Changed 2 years ago by 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.)

comment:37 Changed 23 months ago by Zrax0111

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.

comment:38 Changed 23 months ago by 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.

comment:39 Changed 22 months ago by 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.

comment:40 Changed 21 months ago by 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

Last edited 21 months ago by Jason.Lynn (previous) (diff)

comment:41 Changed 20 months ago by Jason.Lynn

Bueller?

comment:42 Changed 20 months ago by frank

Problem still under investigation.

comment:43 Changed 19 months ago by stefan.becker

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

comment:44 Changed 19 months ago by 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.

comment:45 Changed 18 months ago by 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

comment:46 Changed 17 months ago by stefan.becker

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

comment:47 Changed 16 months ago by 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.

Last edited 16 months ago by Jason.Lynn (previous) (diff)

comment:48 follow-up: ↓ 49 Changed 16 months ago by michael

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.

comment:49 in reply to: ↑ 48 Changed 16 months ago by 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?

comment:51 Changed 15 months ago by mooninite

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

comment:52 Changed 15 months ago by Perryg

@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 ]

comment:53 Changed 15 months ago by michael

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)
         {

comment:54 Changed 15 months ago by Perryg

Sure. I will here in a bit.

comment:55 Changed 15 months ago by Perryg

@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.

comment:56 Changed 15 months ago by Perryg

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.

comment:57 Changed 15 months ago by michael

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.

comment:58 Changed 15 months ago by fniessen

me too

comment:59 Changed 15 months ago by michael

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"));

comment:60 Changed 15 months ago by Perryg

@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.

comment:61 Changed 15 months ago by 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.

comment:62 Changed 15 months ago by michael

  • Cc mpkossen added
  • Component changed from WDDM to 3D support

Added mpkossen to CC list.

comment:63 Changed 15 months ago by stefan.becker

Yesterday i built a new Desktop PC. Intel Pentium G3250, Nvidia GT 610. OS is OpenSuse Leap 42.1/64 Bit, Nvidia Driver is 367.35.

With the Version above there is no Problem anymore.

So for me with this Patch the problem is solved.

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

Last edited 15 months ago by stefan.becker (previous) (diff)

comment:64 Changed 15 months ago by michael

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.

comment:65 Changed 15 months ago by stefan.becker

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

comment:66 Changed 15 months ago by michael

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.

comment:67 Changed 8 months ago by 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

comment:68 Changed 3 months ago by michael

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.

comment:69 Changed 2 months ago by 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.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use