Xquartz 2.7 5 software#
On the left pane of the Preferences dialog, expand IDL and select Graphics, and then on the right choose the "Default rendering method for object graphics" setting for Software (1)). If it is not possible for you to upgrade to the latest version of XQuartz or the problem persists even after upgrading XQuartz, other workarounds for this problem include: 1.) Configure IDL to use Software Rendering or 2.) Downgrade to XQuartz 2.7.1.ġ.) Configure IDL to use Software Rendering.Ī.) You can change your IDL preference to use Software rendering via the IDL Workbench Preferences dialog. XQuartz can be obtained from the web site location: The problem described above may be resolved by upgrading to the latest compatible stable release version of XQuartz (v2.7.4 at the time this article was written). Invalid memory access of location 0x1 rip=0x10f1fa3f4 % IDLGRSRCDEST::DRAW: Unable to acquire device context. % IDLGRSRCDEST::DRAW: Failure to acquire window rendering context. You can determine your version of XQuartz by launching XQuartz and then selecting the menu item "X11 > About X11".īelow are examples of reported error messages also associated with this problem.
Xquartz 2.7 5 mac os x#
It may also affect ENVI/IDL on Mac OS X 10.7 or 10.6 when using XQuartz 2.7.2 or earlier.) (Also, we have not confirmed, but it may be possible that this problem can affect IDL 8.1 and 8.0. IDL object graphics (including the IDL 8 function graphics and other routines using object graphics features) used in ENVI 5.0 and IDL 8.2 can fail and even cause ENVI or the IDL Workbench to freeze or crash, when using IDL hardware rendering, Mac OS X 10.8 (Mountain Lion) and XQuartz version 2.7.2. However, customers have reported being able to successfully use these versions of ENVI and IDL on their Mac OS X 10.8 systems. Which solves the issue of querying background color for every label drawn with XFT fonts.PROBLEM DESCRIPTION Note that ENVI 5.0 and IDL 8.2 are not officially supported on Mac OS X 10.8 (Mountain Lion).
Xquartz 2.7 5 download#
On normal X Servers, if running locally, it will not be a huge gain, but on XQuartz, it will make a big difference.įinally, if you use Motif with XFT, you can download the latest Motif version from SourceforgeĪnd apply the fix described in this bug report:
This will help the performance in any Xt based toolkit. And worked fine on older versions of MacOS.įirst, in your own software, try to minimize the use of Xlib calls, which cause round trips: XSync, XInternAtom, XGetWindowAttributes, XQuery* (XQuer圜olor, XQueryBestCursor, XQueryBestSize. Since we can't fix the MacOS, we need "fix" our software and avoid the slow functions, which work just fine on other systems. These would normally also slow down the response of X clients if you use SSH network access, but in this case, it also happens for programs, which run locally. All the Xlib calls which require round trip have become very slow after El Capitan. The underlying problem is in XQuartz and how it interacts with Mac graphical subsystem. If your IDL Widgets use Motif and XFT (antialiased fonts), then I have a solution, which can help speeding it up. But it breaks all of the color setups in my program.Īll suggestions and questions are appreciated! The only way that can speed up the response now is to force set the output to 256 colors. I tried to debug on myself, so I found the following link shares similar issue with me. I tried to downgrading my xQuartz to 2.7.9, the problem was not resolved. I tried to both run the program with SSH and locally, the response rates seem very similar. I don't think the problem is related to SSH. Unfortunately, I can't remember which version of the xQuartz I used. With proper internet connection, it also worked fine. I used to have the same program SSH'd to OS X Mavericks before upgrading. I have the same program running on a Red Hat Enterprise Linux Workstation 6.6.
I am not sure if this happens to every IDL users, but after upgrading to macOS Sierra and xQuartz 2.7.11, the response rate of my IDL widgets becomes unacceptably slow.
0 kommentar(er)
