Opened 12 years ago
Last modified 5 years ago
#11606 reopened defect
Poor graphics performance on retina display with VirtualBox 4.2.x
Reported by: | cmil | Owned by: | |
---|---|---|---|
Component: | GUI | Version: | VirtualBox 4.2.10 |
Keywords: | Cc: | ||
Guest type: | all | Host type: | Mac OS X |
Description
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.
Attachments (4)
Change History (84)
by , 12 years ago
Attachment: | VBox-4.2.10.log added |
---|
comment:1 by , 12 years ago
comment:2 by , 11 years ago
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.
comment:3 by , 11 years ago
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.
comment:5 by , 11 years ago
If I can add my vote/support for getting retina support via #12315
Is there a version we can test?
comment:6 by , 11 years ago
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'.
comment:8 by , 11 years ago
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.
comment:9 by , 11 years ago
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.
comment:10 by , 10 years ago
Workaround pointed by Gitarooman works. I've installed "Display Menu" (free version). Now Ubuntu 14.04 with Unity 3D is working very well.
comment:11 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
The Retina issue was fixed in VBox 4.3.x, please install the latest available 4.3.x version (currently VBox 4.3.16).
follow-up: 43 comment:12 by , 10 years ago
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*
comment:13 by , 10 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
comment:14 by , 10 years ago
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.
comment:15 by , 10 years ago
The absolute minimum amount of information we need is a VBox.log file of a VM session running on your Retina Mac.
comment:18 by , 9 years ago
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?
comment:19 by , 9 years ago
Same problem. Just upgraded to VirtualBox 5.0.0 r101573 - OSX 10.9.5 host - ubuntu 14.04 guest.
comment:20 by , 9 years ago
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.
comment:21 by , 9 years ago
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/
comment:22 by , 9 years ago
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.
comment:23 by , 9 years ago
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.
comment:24 by , 9 years ago
The problem is up to the point that PowerPoint within the guest system (Win7) hangs when trying to run presentation (F5).
comment:25 by , 9 years ago
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.
comment:26 by , 9 years ago
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.
comment:27 by , 9 years ago
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.
comment:28 by , 9 years ago
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.
comment:29 by , 8 years ago
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
comment:30 by , 8 years ago
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
comment:31 by , 8 years ago
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)
comment:32 by , 8 years ago
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.
comment:33 by , 8 years ago
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 ??
comment:34 by , 8 years ago
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.
comment:35 by , 8 years ago
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.
comment:37 by , 8 years ago
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.
comment:38 by , 7 years ago
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.
follow-up: 40 comment:39 by , 7 years ago
Yesterday, I updated to VirtualBox to 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. :)
follow-up: 42 comment:40 by , 7 years ago
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"
comment:41 by , 7 years ago
That was the test fix from ticket #16436, but improved by wiser people than me.
comment:42 by , 7 years ago
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.
comment:43 by , 7 years ago
Dear Diver.
Could you clarify if 4.1.28->4.1.30 regression (you've observed) happens to be when:
- GA installed in your Linux VM
- 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*
comment:44 by , 7 years ago
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!
comment:45 by , 7 years ago
In that case you are using a guest without any acceleration (no Guest Additions installed).
comment:49 by , 7 years ago
I would really like to try the test build as I have to use vmware fusion
comment:50 by , 7 years ago
Hello Diver, thank you for patience. Started reverting 4.1.30 vs 4.1.28 to prepare test build for you.
comment:52 by , 7 years ago
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...
comment:56 by , 7 years ago
On which Haiku version (32-bit or 64-bit) you've got 4.1.28->4.1.30 regression ?
comment:57 by , 7 years ago
Back then I used 32-bit version. But I believe it was the same with 64-bit as well.
comment:58 by , 7 years ago
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.
comment:59 by , 7 years ago
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)
comment:60 by , 7 years ago
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.
follow-up: 64 comment:61 by , 7 years ago
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.
comment:62 by , 7 years ago
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.
comment:63 by , 7 years ago
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.
comment:64 by , 7 years ago
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:
- "Arrow head" - host cursor
- "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" ?
comment:65 by , 7 years ago
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.
follow-up: 68 comment:66 by , 7 years ago
follow-up: 71 comment:67 by , 7 years ago
DmitrG, any news about the test build or a way for me to build it myself?
comment:68 by , 7 years ago
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.
follow-up: 72 comment:69 by , 7 years ago
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 |
comment:71 by , 7 years ago
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 .
comment:72 by , 7 years ago
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?
comment:73 by , 7 years ago
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.
comment:74 by , 7 years ago
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
comment:75 by , 7 years ago
Thanks I did
VboxManage modifyvm Haiku --graphicscontroller vmsvga
but that didn't change anything unfortunately :(
comment:76 by , 7 years ago
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.
by , 7 years ago
Attachment: | Haiku-2017-10-18-09-57-09.log added |
---|
comment:77 by , 7 years ago
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
comment:78 by , 7 years ago
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.
follow-up: 80 comment:79 by , 5 years ago
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.
comment:80 by , 5 years ago
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
Yes, Retina support is still ongoing work.