Poor graphics performance on retina display with VirtualBox 4.2.x

[cmil]

I'm happily using VirtualBox on a MacBook Pro with Retina display. However, ever since the release of VirtualBox 4.2 moving windows in a guest OS is very slow, i.e. the movement of the window is considerably lagging behind the pointer movement up to a degree where it gets unusable. This happens on both, a Gentoo Linux VM with a XFCE4 desktop and on a Windows Vista VM. The problem also occurs no matter which resolution the MacBook's retina display is configured to use. Moving windows works fine, however, when I move the VM window to a secondary (non-retina) display.

I tried several 4.2.x releases of VirtualBox including 4.2.10 which all showed the same behaviour. I'm currently using 4.1.24 which seems to be the last version not to have this problem.

[Frank Mehnert]

Yes, Retina support is still ongoing work.

[augustl]

I have a question about "retina support is still ongoing work".

Is this about the virtualbox GUI, such as adding retina icons and what not to support full retina rendering on OS X?

Or does it go deeper? Example, perhaps the os x video drivers on retina macs are very different to the ones on non-retina macs, so that virtualbox isn't as efficient in rendering regardless of number of pixels on retina macs as on non-retina macs.

[smithkl42]

I'm having the same issue (see ​https://forums.virtualbox.org/viewtopic.php?f=8&t=57256). It would be very nice if this could get addressed.

[edmund.highcock]

I am experiencing the same issue, one more vote here!

[myitcv]

If I can add my vote/support for getting retina support via #12315

Is there a version we can test?

[Gitarooman]

As a temporary work around, you can install one of the resolution changing apps (QuickRes - probably the best, Display Menu, SwitchRes, etc) and set them to not run in 'HiDPI' mode as this 'scaling' seems to be at least part of the issue. For instance, I can run 1920x1200 no problem in the VM without HiDPI. If I turn HiDPI on for that same resolution, everything slows to a crawl. Hope this helps someone. EDIT: The sluggishness is there regardless of the resolution when HiDPI is set to 'on'.

[Skyke]

Another vote from me!

[carlhill]

I am having the same issue. MacBook Pro Retina 13" late 2013, Mavericks 10.9.1, Virtualbox V4.3.6 with Windows 7 guest. In the Windows guest, when dragging a window the cursor moves but the window drags behind very slowly.

[joosty]

Same issue here. MacBook Pro Retina 15" late 2013, Mavericks 10.9.2, Virtualbox 4.3.8, Windows 7 guest.

Another workaround: connect to the VirtualBox instance using RDP. In case of Windows guest, enable remote desktop and connect to it using the "Microsoft Remote Desktop" app available for free in the App Store. Or enable the VirtualBox "Remote Display" (VRDE) feature, and connect to that using that same app (in that case do remember to connect to 'localhost' and the configured port, not the guest IP). On top of that you could then start the guest in headless mode, to save some system resources: VBoxManage stratum "<vbox-name>" --type headless

This workaround doesn't require you to switch to a non-retina resolution, and the graphics performance is MUCH better.

[leeeeeo]

Workaround pointed by Gitarooman works. I've installed "Display Menu" (free version). Now Ubuntu 14.04 with Unity 3D is working very well.

[Frank Mehnert]

The Retina issue was fixed in VBox 4.3.x, please install the latest available 4.3.x version (currently VBox 4.3.16).

[Sergei Reznikov]

Just tried VirtualBox-4.3.20-96996-OSX.dmg with ​http://download.haiku-os.org/nightly-images/x86_gcc2_hybrid/current-vmware on my MBP w/ OSX 10.8.5 and graphics performance is still painfully slow. Going back to 4.1.28 again:/ *sigh*

[benc]

Same issue. Slow scrolling/and window moving. Windows 7 Guest, OSX 10 (Yosemite) host. I gave the guest 8 GB RAM and 8 Processors and maxed out the GPU memory. It seemed to help a bit but the issue is still there. I bought my MacBook Pro in March 2015.

[Frank Mehnert]

The absolute minimum amount of information we need is a VBox.log file of a VM session running on your Retina Mac.

[bypr3]

log file of the phenomenom in my instance

[Sergei Reznikov]

Still here with VirtualBox-5.0.0-101573-OSX.dmg

[mpasternak79]

Replying to diver.:

Still here with VirtualBox-5.0.0-101573-OSX.dmg

Hello diver, thank you for this issue report. What version of MacOS X are you using?

[d_format]

Same problem. Just upgraded to VirtualBox 5.0.0 r101573 - OSX 10.9.5 host - ubuntu 14.04 guest.

[ubentobox]

VirtualBox 4.3.28 r100309 OSX 10.10.5 Kali Linux Guest

Drag response issue still present.

Updated to VirtualBox 5.0.0 r101573

Issue seems to have alleviated.

[bluzer]

5.0.0 didn't help me (guest is ubuntu 14.04). This did: ​http://linuxbsdos.com/2014/10/31/solutions-for-low-screen-resolution-in-ubuntu-14-0414-10-and-virtualbox/

[d_format]

I had Drag'n'drop set to bidirectional in virtualbox Generanl-Advanced settings. htop showed CPU% usage would spike when moving a window "" /usr/bin/VboxClient --seamless drag'n'drop "". Disabling Drag'n'drop reduced window movement lag a lot.

[xtrek]

same issue:

VirtualBox 5.03r102137

Host OS: Macbook Pro retina 13' OSX 10.10.5

Guest OS: Ubuntu 14.04 (same issue with both default and MATE desktops)

This issue is only present on mac.. I am running the same setup under Windows, and there is ZERO lag when moving windows around. On Mac it is close to unusable.

[Bugsy]

The problem is up to the point that PowerPoint within the guest system (Win7) hangs when trying to run presentation (F5).

[ad248]

Hello Oracle developers ... is there any interest in looking at this issue reported by so many people? How many reports does it take for someone to look into this.

[Michael Thayer]

I'm afraid that the number of reports is not the only factor in play. The main factor is having a developer with the necessary skills, knowledge and hardware available and with enough time free from other tasks and commitments to look at the issue (looking at any issue is a substantial time investment, and there are more than enough to choose from).

And this is probably not what you want to hear, but given that VirtualBox is open source, we also assume that if an issue really affects enough people there is likely to be one or two among them with the required skills to investigate it themselves in more depth; if no one shows interest in doing so we tend to take that into account too.

That said, chances are this will be looked at at some point, we just can't make promises. And though psychological pressure of the sort you tried to apply in your last comment actually make us less keen to look at an issue, we try for the sake of other users not to take that into account either.

[Michael Thayer]

I followed up on this with Arend in private communication. (Arend has indeed contributed fixes to VirtualBox in the past.) A point which I forgot to mention above which came up in our exchange, and which is worth making publicly, is that the VirtualBox developers are often more interested in good analyses of the cause of a problem than in actual patches, as understanding all the possible implications of a patch often takes as long as actually fixing a properly understood problem (we have to take full responsibility for any patch which we commit with any potential regressions). The exception here is regular contributors (and people who are interested in being regular contributors): as we work with them more regularly we can integrate patches from them with much less effort on both sides.

[PatPend]

Non-developer and dedicated long-time user here. Would setting up a bounty provide impetus to tackle this issue? Perhaps to purchase a test platform or beer? Retina Macs are everywhere nowadays and I am definitely willing to contribute.

EDIT: For sure it's something in the scaling function. If you check Settings>Display>Use Unscaled HiDPI Output, the screen display goes tiny but there is zero lag.

[archy]

PatPend's mention of enabling the Unscaled HiDPI Output option vastly improved the lag for me, and by setting the Scale Factor via the View menu I can get back to normal-ish resolution. Setting the scale factor in the view menu doesn't cause the same lag issue.

I also found that if Use Host I/O cache was enabled on any of my storage controllers, the lag got really bad even with Unscaled HiDPI Output enabled

OS X 10.11.6; VBox 5.1.4 r110228

[claudio_ch]

rendering issue in 5.1.6

[claudio_ch]

Some time ago I discovered, the here described workaround using "Unscaled HiDPI Output". Unfortunately with 5.1.6 it does not work anymore, because rendering produces often grey areas (see attached screen shot for an example). This does not happen when deselecting "Unscaled HiDPI Output" but then I have the window lag.

Host OSX 10.11 or macOS12. Guest Ubuntu 16.04

[marklmc]

I too, am having the same issue as claudio_ch above

Using "Unscaled HiDPI Output", but getting the same boxes around text (black boxes for me though)

​http://i.imgur.com/IugEeci.png

• Host: OS X 10.11.3
• Gust: Linux haddock 4.7.4-1-ARCH #1 SMP PREEMPT Thu Sep 15 15:24:29 CEST 2016 x86_64 GNU/Linux
• WM: i3
• VirtualBox: Version 5.1.6 r110634 (Qt5.5.1)

[rlovtangen]

Drag response issue also on a late 2016 MBP 15"
Host: MacOS Sierra
VirtualBox 5.1.12
Guest: Windows 7

Best workaround so far is to set screen resolution for host to minimum. The bigger window I have for the guest, the more lag.

[BrendanSimon]

Drag response issue also on a 2016 MBP 15" (purchased Feb 2017).

• MacBook Pro 15" -- i7, 16GB RAM, 1TB SSD (30GB free)
• Host: MacOS Sierra
• VirtualBox 5.1.14 (extensions and guest additions installed)
• Guest: Windows 7 Ultimate -- 4GB RAM, 64MB VRAM, 1 CPU, 100GB HDD (14GB free)

Checking Unscaled HiDPI Output provided high resolution display (tiny pixels) and moving guest windows was very acceptable. Scale Factor set to 100%

Setting Scale Factor set to 200% caused lots of (unaccpetable) latency when dragging guest windows.

Any forthcoming fixes or workarounds for this ??

[BrendanSimon]

A reasonable workaround for me was to:

• Check Unscaled HiDPI Output
• Set Scaling Factor to 100%
• Change Windows 7 scaling to 150% in User Accessibility settings (that's the highest available).

I still have to squint a little bit on the high resolution retina display. If Win 7 had 200% scaling then that would be a reasonable workaround.

Still waiting for my USB-C to DisplayPort adaptor to arrive so I can test with my external monitor.

[BrendanSimon]

Hmmm, actually no. If I have a small window it drags ok. If I try to expand the window to something largish, then the expansion slows down, and moving/dragging it is also very slow.

[Socratis]

Cc: socratis, related ticket: #16436.

[agodfrin]

Same issue here. I just started suffering from it because I replaced my older MacBook with a new one that happens to have a retina display. I am a heavy user of Linux VMs and this is is really becoming a hindrance in doing my job. I am surprised this has been going on for 4 years now without any resolution.

The implication is that VirtualBox is no longer a viable option for use with MacBooks and MacBook Pros, since all current configurations come with Retina displays. It is still a valid option for older MacBooks without Retina displays, but those are slowly disappearing.

I wish the VirtualBox community raises this issue to a higher priority. The risk is to loose the Mac user community altogether. I personally will try VMWare, even though it is a commercial offering.

[Tayger]

I am having the same problem on iMac (latest edition), Virtualbox 5.1.8, original VM from Oracle (ODI 12c Getting Started VM). Moving a windows in Linux 6.4 takes seconds till its at its moved position. All sliders are moved far into green area, so enough resources for VM. Checking the performance monitor dies not show any significant use of CPU, memory, etc.everything stays low. Changing any other VM parameters (3D accelerator, changing chipset, etc.) didn't help to improve GUI performance. I am also confused this problem persists since 4 years.

[commorancy0]

Yesterday, I updated to VirtualBox version 5.1.20 r114629 (Qt5.6.2) for the Mac and the slow dragging of windows in CentOS seems to have inexplicably gone away. I've not made any changes to MacOS X at all. I noticed this change almost immediately after the upgrade even before upgrading to the latest Guest Additions. While I can't guarantee that this performance issue has been resolved for all versions of Linux, it seems to have been resolved for at least CentOS 6 as of this release.

I just want to confirm that someone intentionally rolled a change in the graphics performance area for the latest VirtualBox release? I don't see any developer comments here or on other threads regarding making any changes around this issue. However, things don't generally fix themselves. :)

[Socratis]

Replying to commorancy0:

I just want to confirm that someone intentionally rolled a change in the graphics performance area for the latest VirtualBox release? I don't see any developer comments here or on other threads regarding making any changes around this issue. However, things don't generally fix themselves. :)

It might not be the graphics performance after all. I did a source code comparison between 5.1.18 and 5.1.20 and the following seems to be the "cure":

#ifdef VBOX_WS_MAC
    // WORKAROUND:
    // Since we are handling mouse move/drag events in the same thread
    // where we are painting guest content changes corresponding to those
    // events, we can have input event queue overloaded with the move/drag
    // events, so we should discard current one if there is subsequent already.
    EventTypeSpec list[2];
    list[0].eventClass = kEventClassMouse;
    list[0].eventKind = kEventMouseMoved;
    list[1].eventClass = kEventClassMouse;
    list[1].eventKind = kEventMouseDragged;
    if (AcquireFirstMatchingEventInQueue(GetCurrentEventQueue(), 2, list,
                                         kEventQueueOptionsNone) != NULL)
    return true;
#endif /* VBOX_WS_MAC */

So it looks it was due to an overflow of mouse events that were buffering up and causing the delays. For the source code aficionados out there:
"/src/VBox/Frontends/VirtualBox/src/runtimeUIMouseHandler.cpp"

[Michael Thayer]

That was the test fix from ticket #16436, but improved by wiser people than me.

[commorancy0]

Replying to socratis:

It might not be the graphics performance after all.

So it looks it was due to an overflow of mouse events that were buffering up and causing the delays. For the source code aficionados out there:
"/src/VBox/Frontends/VirtualBox/src/runtimeUIMouseHandler.cpp"

Thanks for the confirmation. If there's a way to also attribute that code fix to this bug report (at least for slow dragging), that would be helpful.

[Dmitrii Grigorev]

Dear Diver.

Could you clarify if 4.1.28->4.1.30 regression (you've observed) happens to be when:

1. GA installed in your Linux VM
2. GA not installed in your Linux VM

Not sure if GA changes are relevant to the problem, so please clarify the 1 and 2 questions above.

I can prepare test build for you with reverted changes of 4.1.30 vs 4.1.28.

Replying to diver.:

Just tried VirtualBox-4.3.20-96996-OSX.dmg with ​http://download.haiku-os.org/nightly-images/x86_gcc2_hybrid/current-vmware on my MBP w/ OSX 10.8.5 and graphics performance is still painfully slow. Going back to 4.1.28 again:/ *sigh*

[Sergei Reznikov]

Hi DmitrG!

For some reason I don't get notifications for ticket updates. It wasn't a Linux VM but it was a Haiku VM. Tried with both GA installed and not.

I would gladly test your build!

[Frank Mehnert]

In that case you are using a guest without any acceleration (no Guest Additions installed).

[Sergei Reznikov]

Right, regression is not in GA but in VESA performance.

[Sergei Reznikov]

DmitrG, any news about the test build?

[Sergei Reznikov]

Ping.

[Sergei Reznikov]

I would really like to try the test build as I have to use vmware fusion

[Dmitrii Grigorev]

Hello Diver, thank you for patience. Started reverting 4.1.30 vs 4.1.28 to prepare test build for you.

[Sergei Reznikov]

Great! Waiting for the test build!

[Dmitrii Grigorev]

Replying to diver.:

Great! Waiting for the test build!

Hello Diver.
About reverting code changes in 4.1.28 vs 4.1.30. I've checked that the changed code in src/VBox/Devices/VMMDev/VMMDevHGCM.cpp and src/VBox/Additions/common/crOpenGL/load.c is active only when 3D acceleration enabled and GA installed (respectively). So, if you guest is Haiku OS then the code changes are irrelevant.
Looking further...

[Sergei Reznikov]

Yep, my guest is Haiku.

[Dmitrii Grigorev]

Are you using 32-bit or 64-bit Haiku (development version)?

[Sergei Reznikov]

I'm using both versions (current nightlies).

[Dmitrii Grigorev]

On which Haiku version (32-bit or 64-bit) you've got 4.1.28->4.1.30 regression ?

[Sergei Reznikov]

Back then I used 32-bit version. But I believe it was the same with 64-bit as well.

[Dmitrii Grigorev]

Please clarify the following. If Haiku just see VGA controller emulated by VirtualBox, how can I check it? Is there a tool like lspci in Linux?

Just installed Haiku 32-bit on MacBook 2015 with Retina and see no input lag on VirtualBox 5.1.26.

[Sergei Reznikov]

Yes, Haiku doesn't use vbox driver as it doesn't provide any additional benefits to VESA driver. I disabled it in the virtualbox_guest_additions package which I sort of maintain, see: ​https://github.com/haikuports/haikuports/blob/06cd8d593c0adf2f52c12fbeebbc7f91d1fbf931/app-emulation/virtualbox-guest-additions/virtualbox_guest_additions-5.1.26.recipe#L81

To verify that you can run this:

listimage | grep accel

Not sure about input lag but moving windows around is lagging pretty bad over here on MacBook Pro (Retina, 15-inch, Early 2013)

[Socratis]

I can verify that with today's Haiku-32 nightly, right out of the box, there is no lag here whatsoever. MBPr 15", MacBookPro11,5 with 10.11.6. I will try the 64-bit as well.

[Sergei Reznikov]

Just checked myself: VirtualBox 5.1.26 with macOS 10.12.6 and window moving is laggy (no CPU usage), moving windows in VMware is smooth.

[Socratis]

Haiku 64-bit version, build 51413 (2017-09-11), no lag at all, with VirtualBox 5.1.27 and 5.2.0b2. I'd dare to say it feels like the window is a native OSX one, it's that fast.

• OSX resolution = More space (feels like 1920x1200)
• Haiku resolution = 1280x1024.

Maybe 10.12.x has something to do with it? And the fact that your MBPr is from early 2013 while mine is from mid-2015? BTW, AMD Radeon R9 M370X on the Mac.

[Sergei Reznikov]

I doubt that 10.12.x has something to do with it as it was the same with every single update I installed here.

OSX resolution 15,4-inch (2880 x 1800) but I also tried Scaled "More space (Looks like 1920x1200)"

NVIDIA GeForce GT 650M 1024 MB.

The lag looks like some frames are being dropped during window movement.

[Dmitrii Grigorev]

Replying to diver.:

Just checked myself: VirtualBox 5.1.26 with macOS 10.12.6 and window moving is laggy (no CPU usage), moving windows in VMware is smooth.

Hello Diver. Please estimate visually the lag duration - less then a second or more. Really, I see two mouse cursors:

1. "Arrow head" - host cursor
2. "Human arm" - guest cursor

Sometimes this two cursors do not coincide while guest window is being dragged. Do you mean such effect saying "input lag" ?

[Sergei Reznikov]

When I move a window around it catches up my cursor within half a second. It looks like one sees two cursors when "Input -> mouse integration" is enabled. Disabling it makes cursor speed much slower, this is with USB pointing device.

[Socratis]

Replying to DmitrG:

Really, I see two mouse cursors:

1. "Arrow head" - host cursor
2. "Human arm" - guest cursor

You should really Cc: yourselves to ticket #15610: Host cursor visible in guest, produces double cursors.

It's a known issue... ( hint, hint :p )

[Sergei Reznikov]

DmitrG, any news about the test build or a way for me to build it myself?

[Socratis]

Replying to socratis:

You should really Cc: yourselves to ticket #15610: Host cursor visible in guest, produces double cursors.

It's a known issue... ( hint, hint :p )

I'd just like to say that with the latest "Development Snapshot" (5.2.0rc1+), at least this issue of the double cursors has been addressed (by upgrading the underlying Qt to 5.6.3).

And again, no lag here. I'm sorry that I can't confirm what you're seeing diver.

[Sergei Reznikov]

​https://www.dropbox.com/s/tt7thbwxtuhhbhe/haiku_vbox.mov?dl=0

Chipset	ICH9
Pointing Device	USB Tablet
Extended Features	Enable I/O APIC
CPU	1
Video Memory	64 MB
Guest Additions	None

[Sergei Reznikov]

This is with Version 5.1.30 r118389 (Qt5.6.3)

[Dmitrii Grigorev]

Replying to diver.:

DmitrG, any news about the test build or a way for me to build it myself?

Hi Diver. If you want to build VirtualBox from sources please look here https://www.virtualbox.org/wiki/Build_instructions .

[Dmitrii Grigorev]

Replying to diver.:

​https://www.dropbox.com/s/tt7thbwxtuhhbhe/haiku_vbox.mov?dl=0

Chipset	ICH9
Pointing Device	USB Tablet
Extended Features	Enable I/O APIC
CPU	1
Video Memory	64 MB
Guest Additions	None

Hi Diver. In fact, I do not see any input lag on your video. But second mouse cursor sometimes appears. Please clarify if we have the same understading of the problem?

[Sergei Reznikov]

Reading the ticket description again makes me think it's not exactly the same problem I am having but we just happen to have the same last vbox version and retina display. In my case I observe extremely laggy window movements (don't you see that on the video?) which look like most of the frames are being dropped.

If I were to compile it myself (which, TBH, I don't really want to) would it still possible to build 4.1.28 (the last version that didn't have this problem) on macOS 10.13. Bearing in mind that compiler version changed and Qt4 may also have some problems.

Because of this issue 3 years ago I had to switch to VMware Fusion. But I keep coming back checking if newer versions of VirtualBox fixed it and would want to use it instead of VMware.

[Dmitrii Grigorev]

Hi Diver. Thank you for clarification, the phenomenon "most of the frames are being dropped" in fact can be seen on the attached video. Could you switch to another implementation of VGA adapter and recheck your problem?

VboxManage modifyvm <vm name> --graphicscontroller vmsvga

[Sergei Reznikov]

Thanks I did
VboxManage modifyvm Haiku --graphicscontroller vmsvga
but that didn't change anything unfortunately :(

[Socratis]

Why the ICH9 chipset? And could you give your VM 2 CPUs? In fact, could you:

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

[Sergei Reznikov]

Why the ICH9 chipset?

No certain reason.

And could you give your VM 2 CPUs?

I could but VirtualBox have a bug where it kernel panics Haiku after several hours of uptime with more than 1 CPU.

In fact, could you:

Sure, here is the log: attachment:Haiku-2017-10-18-09-57-09.log​

[Socratis]

I don't particularly like analyzing logs in the Bugtracker, I'd rather do it in the forums, but, you can't win them all. BTW, if I hadn't underlined and put in bold the "ZIP it" part, what would you have done with the log? Post it as a binary dump?

00:00:01.398319 VRDP: Statistics created: [full], enabled: 0.
00:00:01.400506 VRDP: VRDP: VD: Frames=10 MinMS=15 MaxMS=300 HistoryMS=2000 VideoMS=300
00:00:01.402539 VRDP: TCP server listening on port 3389 (IPv4 and IPv6).
00:00:01.403004 VRDP: Audio: rate correction mode 0x3.
00:00:01.403337 VRDE: loaded version 4 of the server.
00:00:01.403358 VRDE: [IMAGE]
00:00:01.403372 VRDE: [MOUSEPTR]
00:00:01.403382 VRDE: [SCARD]
00:00:01.403392 VRDE: [TSMFRAW]
00:00:01.403401 VRDE: [VIDEOIN]
00:00:01.403410 VRDE: [VRDE::INPUT]

Are you accessing the VM via VRDP?

---

00:00:01.509018 [/Devices/piix3ide/0/Config/SecondaryMaster/] (level 5)
00:00:01.509022 [/Devices/piix3ide/0/Config/SecondarySlave/] (level 5)

Where's the PrimaryMaster? Can't seem to be able to find one. Something is not setup correctly with your IDE controller...

---

00:00:02.050014 GUI: UIMachineWindow::handleNativeNotification: Notification 'NSWindowDidEnterFullScreenNotification' received

Are you going full screen on that? Why? You got nothing to gain.

---

00:00:01.509124   CustomVideoMode1 <string>  = "2880x1800x32" (cb=13)
00:00:01.509125   CustomVideoMode2 <string>  = "2880x1800x16" (cb=13)
00:00:01.509126   CustomVideoMode3 <string>  = "1440x900x32" (cb=12)
00:00:01.509127   CustomVideoMode4 <string>  = "1440x900x16" (cb=12)

Do you mind getting rid of those? Especially the 16-bit ones? In fact get rid of all of them. Stick with the standards.

---

Speaking of standards, revert the ICH9 chipset to the PIIX3 one. And please right-click on the VM in VirtualBox Manager, select "Show in Finder", ZIP the selected ".vbox" file and attach it to your response. And finally, I would like to know the exact name of the ISO that you used to install Haiku, build, date and bitness.

[Sergei Reznikov]

I managed to find a workaround for my problem using VBox 6.0.14:

I checked Open in low resolution using Finder info window for this file

/Applications/VirtualBox.app/Contents/Resources/VirtualBoxVM.app

And then created a custom resolution:

VBoxManage setextradata Haiku "CustomVideoMode1" "1440x1024x32"

I "think" this is what I was using (and forgot about) before I first noticed this problem after an update from 4.1.28 to 4.1.30. But I'm not quite sure how reinstalling older version could re-enable Open in low resolution option.

[mikijov]

Thank you. This made using VirtualBox usable again for me. Actually, I would suggest this to be made a default when installing VirtualBox. I would expect that vast majority of users want normal performant desktop rather than test with rather slow HiDPI screen.

Replying to diver.:

I managed to find a workaround for my problem using VBox 6.0.14:

I checked Open in low resolution using Finder info window for this file

/Applications/VirtualBox.app/Contents/Resources/VirtualBoxVM.app