Gazebo GUI / Rendering is scaled

[osrf-migration]

Original report (archived issue) by Samuel Ong (Bitbucket: samuelong).

---

Hi guys, I have recently updated my MacOS to Mojave from High Sierra, running Gazebo 9.
Gazebo seems to be working but the display is really off, and I have no idea how I should fix it. Any advice would be great!! Resizing doesn't help at all, and please let me know what information do you need me to provide.

Thanks in advance.

Screenshot 2018-10-01 at 8.49.30 AM.png

[osrf-migration]

Original comment by Theppasith Nisitsukcharoen (Bitbucket: tutor-hg).

---

I'm also having this issue. Gazebo9 Menus size is very big and not usable.

[osrf-migration]

Original comment by Frank Carey (Bitbucket: frankcarey).

---

I installed using the official install script and ran into the same issue:

curl -ssL http://get.gazebosim.org | sh

Looks like there is an issue with qt 5.11 in mojave (the default version from homebrew currently). 5.12 is available if you do:

brew upgrade qt --HEAD

[osrf-migration]

Original comment by Frank Carey (Bitbucket: frankcarey).

---

I can confirm that while it took over 3 hrs to compile qt via homebrew, it did fix the issue immediately (no reboot or reinstall or anything required)

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

I'm still running high sierra on my primary mac machine, but I have confirmed the error on a mac mini running mojave.

@frankcarey great news that it is fixed in qt 5.12, but 5.12 does not yet have a release candidate; it is still on beta3:

• http://code.qt.io/cgit/qt/qt5.git/refs/tags

So I would guess it will be at least a few weeks before this fix is released, possibly more than a month.

If the unreleased patch that fixes this can be identified, we could try submitting it to homebrew as a patch on the current release of 5.11.2. It might not be accepted, but it could be worth a shot.

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

Related: https://bugreports.qt.io/browse/QTBUG-71292

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

• changed component from "rendering" to "os::osx"

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

quick update: qt 5.12.0 has a release candidate rc1 as of Nov 22

• http://code.qt.io/cgit/qt/qt5.git/refs/tags

in the past there has been 1-2 weeks between rc1 and the release, so we are probably getting closer

[osrf-migration]

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

---

Related question.

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

5.12.0 has been released; I'm testing it now and will submit a homebrew pull request unless someone else beats me to it

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

well, qt 5.12.0 is now released into homebrew and bottles are available, but gazebo on mojave still looks broken to me, though it doesn't look scaled; it just looks like nothing is appearing in the 3d window.

I'll ask @iche033 to take a look on one of our test machines.

[osrf-migration]

Original comment by Theppasith Nisitsukcharoen (Bitbucket: tutor-hg).

---

Same to me as well , After using QT 5.12 the scale rendering issue seems to disappear but there's nothing in 3d windows. It's just a grey screen with no ground plane and sun.

and when you click the sun in the object window on the left , app crashed.

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

Ooh, thanks for the tip! I've collected a backtrace from gzclient:

• https://gist.github.com/scpeters/9308dc28493b39f9af6d603b3e82ea65

an excerpt that implicates gazebo::rendering::Light::FillMsg, called by gazebo::gui::ModelListWidget::OnSetSelectedEntity:

2018-12-11 10:47:17.248610-0800 gzclient[14108:3462293] SecTaskLoadEntitlements failed error=22 cs_flags=20, pid=14108
2018-12-11 10:47:17.248693-0800 gzclient[14108:3462293] SecTaskCopyDebugDescription: gzclient-9.5.0[14108]/0#-1 LF=0
[Wrn] [GuiIface.cc:120] Failed to get QCocoaScreen for NSObject(0x0)
Process 14108 stopped
* thread #1, name = 'ZMQbg/1', queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x18)
    frame #0: 0x0000000101414495 libgazebo_rendering.9.dylib`gazebo::rendering::Light::FillMsg(gazebo::msgs::Light&) const + 21
libgazebo_rendering.9.dylib`gazebo::rendering::Light::FillMsg:
->  0x101414495 <+21>: movq   0x18(%r14), %rax
    0x101414499 <+25>: movq   0x20(%rax), %rsi
    0x10141449d <+29>: xorps  %xmm0, %xmm0
    0x1014144a0 <+32>: leaq   -0x40(%rbp), %rdx
Target 0: (gzclient) stopped.
(lldb) bt
* thread #1, name = 'ZMQbg/1', queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x18)
  * frame #0: 0x0000000101414495 libgazebo_rendering.9.dylib`gazebo::rendering::Light::FillMsg(gazebo::msgs::Light&) const + 21
    frame #1: 0x00000001007a154f libgazebo_gui.9.dylib`gazebo::gui::ModelListWidget::OnSetSelectedEntity(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 389

The bottle doesn't have debug symbols, so I'm building again from source to get a better backtrace.

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

Now in debug mode, the backtrace points at gazebo::gui::ModelListWidget::OnSetSelectedEntity at ModelListWidget.cc:291. It seems we don't check the light pointer before dereferencing it.

• https://gist.github.com/scpeters/0cdd75fdc72dd0007e1210e278961b32

[Wrn] [GuiIface.cc:120] Failed to get QCocoaScreen for NSObject(0x0)
Assertion failed: (px != 0), function operator->, file /usr/local/include/boost/smart_ptr/shared_ptr.hpp, line 734.
Process 34110 stopped
* thread #1, name = 'ZMQbg/1', queue = 'com.apple.main-thread', stop reason = signal SIGABRT
    frame #0: 0x00007fff65e7123e libsystem_kernel.dylib`__pthread_kill + 10
libsystem_kernel.dylib`__pthread_kill:
->  0x7fff65e7123e <+10>: jae    0x7fff65e71248            ; <+20>
    0x7fff65e71240 <+12>: movq   %rax, %rdi
    0x7fff65e71243 <+15>: jmp    0x7fff65e6b3b7            ; cerror_nocancel
    0x7fff65e71248 <+20>: retq   
Target 0: (gzclient) stopped.
(lldb) bt
* thread #1, name = 'ZMQbg/1', queue = 'com.apple.main-thread', stop reason = signal SIGABRT
  * frame #0: 0x00007fff65e7123e libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007fff65f27c1c libsystem_pthread.dylib`pthread_kill + 285
    frame #2: 0x00007fff65dda1c9 libsystem_c.dylib`abort + 127
    frame #3: 0x00007fff65da2868 libsystem_c.dylib`__assert_rtn + 320
    frame #4: 0x00000001008d7e99 libgazebo_gui.9.dylib`boost::shared_ptr<gazebo::rendering::Light>::operator->(this=0x00007ffeefbfb948) const at shared_ptr.hpp:734
    frame #5: 0x0000000100968533 libgazebo_gui.9.dylib`gazebo::gui::ModelListWidget::OnSetSelectedEntity(this=0x00000001180cb7b0, _name="sun", (null)="normal") at ModelListWidget.cc:291

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

The following patch fixes the seg-fault:

diff -r f641a83fe7a036af2bd4d473f55aec9536e29d63 gazebo/gui/ModelListWidget.cc
--- a/gazebo/gui/ModelListWidget.cc	Mon Dec 10 18:47:47 2018 +0000
+++ b/gazebo/gui/ModelListWidget.cc	Tue Dec 11 13:11:47 2018 -0800
@@ -288,7 +288,17 @@
         gui::get_active_camera()->GetScene()->LightByName(
             this->dataPtr->selectedEntityName);
 
-      light->FillMsg(this->dataPtr->lightMsg);
+      if (light)
+      {
+      	 light->FillMsg(this->dataPtr->lightMsg);
+      }
+      else
+      {
+        gzerr << "Unable to get Light ["
+              << this->dataPtr->selectedEntityName
+              << "]."
+              << std::endl;
+      }
       this->dataPtr->propTreeBrowser->clear();
       this->dataPtr->fillTypes.push_back("Light");
 

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

@iche033 discovered that minimizing the gzclient window and then restoring it causes rendering to turn on. We first tested with a laptop with retina display, and it was only rendering to 25% of the window, which we have seen before in #2070. I tested also with a mac mini, which does not have this issue.

So, there are two issues:

• minimize then restore window necessary for rendering to start
• 1/4 rendering on retina displays

[osrf-migration]

Original comment by Ian Chen (Bitbucket: Ian Chen, GitHub: iche033).

---

Actually on retina displays, it's rendering to the entire window but the camera orbit control mouse positions are scaled to 25% of the window. I have a fix for the camera control issue but have not figured out how to get the render window to start painting without the minimize + restore workaround

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

I just tested gazebo7 as well, and it has a blank screen as well. I'm inclined to leave this broken and only support gazebo8+ on mojave.

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

Also, minimize / restore doesn't work with gazebo7; it stays blank.

[osrf-migration]

Original comment by Ian Chen (Bitbucket: Ian Chen, GitHub: iche033).

---

I created pull request #3051 that seems to fix gazebo9 + Mojave + Qt 5.12

[osrf-migration]

Original comment by Ian Chen (Bitbucket: Ian Chen, GitHub: iche033).

---

• changed state from "new" to "resolved"

pull request #3051 merged.

Please re-open if issue persists

[osrf-migration]

Original comment by S Albert (Bitbucket: starthal).

---

@scpeters Thanks for the info about gazebo7. I upgraded to Mojave on my MacBook Pro 2015, uninstalled Homebrew entirely, and reinstalled Homebrew and gazebo7. It works fine, including rendering and correct scaling.

But I also attempted to do a fresh install on a new system (MacBook Pro 2018) that shipped with Mojave. That shows the blank screen you're describing (actually it's transparent, showing whatever's behind the window).

Is there any info I can give you about my working system that would be helpful? We are probably moving to gazebo9 soon, but this would be helpful in the short-term.

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

@starthal that sounds like a new issue; do you mind opening a new issue either here or at https://github.com/osrf/homebrew-simulation with more details and screenshots?