I am using xchem on macOS Ventura 13 3 1 The xserver is XQua

Question

I am using xchem on macOS Ventura 13 3 1 The xserver is XQuartz I encountered a very strange GUI behavior See the attached screenshot All the green lines and arrows etc disappear when the window is in focus They reappear when the window is not in focus but it is impossible to capture a screenshot to show that What could be the cause of this I compile xschem from source code and can help with debugging Thanks

Stefan Schippers · Answer

try to see if xquartz is running in true color mode and not in 8bit pseudocolor mode I don t have a Mac so I can t help more on this

Yuan Mei · Answer

I tried all color modes The problem remains Is it possible to change the style of those disappearing green objects in either source code or configuration It may give some insights Thanks

Yuan Mei · Answer

A little more observation after Toggle colorscheme Shift+O when the window is in focus the background is black and the green objects disappear when the window is not in focus the background turns white and all objects are visible

Stefan Schippers · Answer

I am sure this is a problem with XQuartz Xschem does absolutely nothing about colors when window is focused exposed unfocused I can not imagine the reason for this issue

Stefan Schippers · Answer

What is your xquartz version also remember to restart xquartz if you change color depth The only situation when I have seen in the past a similar behavior was with pseudocolor Xservers where since there were only 256 colors 8 bit color depth each application used its own colormap when in focus changing colors for all other applications This can never happen with truecolor visuals 16 24 32 bit per pixel where whatever color an application requests the server always returns the closest approximation Pseudocolor visuals are soo rarely used nowadays that most modern applications Gtk Qt simply do not work firefox is not useable in 256 color mode

Yuan Mei · Answer

XQuartz 2 8 5 xorg server 21 1 6 I made sure that it was restarted after color depth changed It is weird that no other application under XQuartz behaves like this I use at least `magic` `gtkwave` `gnuplot` etc

Stefan Schippers · Answer

Please try the following start xschem from a terminal this way `xterm d 3 l log` when xschem opens just quit xschem Then read the `log` file and find this line What depth is reported from xschem `Tcl AppInit screen depth 24`

Yuan Mei · Answer

```Tcl AppInit drawing window ID=0x6000bc Tcl AppInit top window ID=0x6000b6 Tcl AppInit done tkinit Tcl AppInit screen depth 24 Tcl AppInit done step b of xinit Tcl AppInit done step c of xinit build colors dim=0 dim bg=0 init color array color 000000``` As expected

Stefan Schippers · Answer

since `magic` is working can you see if `magic` and `xschem` are using the same graphic libraries specifically tcl tk I think on macOS you need to use `otool L path to xschem` and `otool L path to magic`

Stefan Schippers · Answer

from otool manpage ``` L Display the names and version numbers of the shared libraries that the object file uses ```

Yuan Mei · Answer

```$ otool L opt OpenICEDA lib magic tcl magicexec opt OpenICEDA lib magic tcl magicexec opt local lib libtk8 6 dylib compatibility version 8 6 0 current version 8 6 13 opt local lib libtcl8 6 dylib compatibility version 8 6 0 current version 8 6 13 opt local lib libz 1 dylib compatibility version 1 0 0 current version 1 2 13 opt local lib libX11 6 dylib compatibility version 11 0 0 current version 11 0 0 opt local lib libGL 1 dylib compatibility version 4 0 0 current version 4 0 0 opt local lib libGLU 1 dylib compatibility version 5 0 0 current version 5 1 0 usr lib libSystem B dylib compatibility version 1 0 0 current version 1319 0 0 opt local lib libcairo 2 dylib compatibility version 11709 0 0 current version 11709 0 0 opt local lib libfontconfig 1 dylib compatibility version 14 0 0 current version 14 0 0 opt local lib libfreetype 6 dylib compatibility version 25 0 0 current version 25 3 0 ```

Yuan Mei · Answer

```$ otool L opt OpenICEDA bin xschem opt OpenICEDA bin xschem usr lib libSystem B dylib compatibility version 1 0 0 current version 1319 0 0 opt local lib libjpeg 8 dylib compatibility version 8 0 0 current version 8 2 2 opt local lib libcairo 2 dylib compatibility version 11709 0 0 current version 11709 0 0 opt local lib libX11 6 dylib compatibility version 11 0 0 current version 11 0 0 opt local lib libxcb 1 dylib compatibility version 3 0 0 current version 3 0 0 opt local lib libxcb render 0 dylib compatibility version 1 0 0 current version 1 0 0 opt local lib libX11 xcb 1 dylib compatibility version 2 0 0 current version 2 0 0 opt local lib libXpm 4 dylib compatibility version 16 0 0 current version 16 0 0 opt local lib libtcl8 6 dylib compatibility version 8 6 0 current version 8 6 13 opt local lib libtk8 6 dylib compatibility version 8 6 0 current version 8 6 13 ```

Yuan Mei · Answer

They are using the same X11 tcl and tk libs

Stefan Schippers · Answer

Can you please try xschem with menu option `View gt No XCopyArea drawing model` selected

Yuan Mei · Answer

The behavior remains the same

Stefan Schippers · Answer

Can you record a short video of a small portion of the desktop with xschem window showing the focus problem keep it short just to see what happens

Yuan Mei · Answer

This is interesting When I use QuickTime Player to record the screen although I can see with my own eyes that the green lines show up and disappear no line is ever shown in the recorded video

Yuan Mei · Answer

Here is a video shot with cellphone Notice the mouse pointer moves in and out of the window

Stefan Schippers · Answer

Very strange When window is focused all direct Xlib graphics mostly lines rectangles disappears Text and images drawn with Cairo remain visible Try to put the mouse in the window and press the w key this starts placement of a new wire segment then move the mouse pointer somewhere else and click the left button Do you see something

Yuan Mei · Answer

No not when the mouse is in the window When mouse moves out of the window and all other lines show up the newly drawn line across the window to the edge shows up as well

Stefan Schippers · Answer

< Tim Edwards> Have you ever seen a similar weird behavior I have no idea why this happens

Stefan Schippers · Answer

< Yuan Mei> so the issue is when window is focused all Xlib graphics is invisible Stuff drawn with Cairo xschem uses the Cairo lib for text and images remains visible

Stefan Schippers · Answer

Can you test if the same happens with a trivial xlogo application

Yuan Mei · Answer

xlogo behaves correctly No disappearance

Stefan Schippers · Answer

Can you please edit the file `config h` in xschem top directory commenting out the `HAS CAIRO` definition and rebuild xschem with ` sudo make install` ` define HAS CAIRO 1 ` Note comment out do not set to 0

Yuan Mei · Answer

Xlib graphics no longer disappears

Stefan Schippers · Answer

Ok so there is a problem with ` opt local lib libcairo 2 dylib` that xschem uses for antialiased text and image rendering Building xschem without `Cairo` makes xschem use its own internal vector font this is how it uses to work on older machines SunOS Solaris Irix that do not have these modern libs Unfortunately without Cairo you will see only a grey rectangle border in place of images but everything works including graphs You should investigate the problem of the cairo library may be an update rebuild is necessary

Yuan Mei · Answer

I get cairo through `macports` <https ports macports org port cairo > It is the latest I ll try debugging that another time But compiling without cairo at least gives me an immediately usable xschem Thanks

Stefan Schippers · Answer

You can try `magic d CAIRO` and see if everything works there `d CAIRO` tells magic to use the cairo You can also check if ```otool L opt OpenICEDA lib magic tcl tclmagic so``` shows the same cairo lib as xschem does

Yuan Mei · Answer

`tclmagic so` links to the same ` opt local lib libcairo 2 dylib` but `magic d CAIRO` gives me segmentation error

Stefan Schippers · Answer

To my best guess it looks like the cairo library renders directly on MacOS quartz graphics and not on the X11 Xquartz emulation Since xschem and also magic use X11 the cairo library should also use X11 I see similar issues posted for the opposite reason cairo trying to use X11 while users want Quartz for example <https github com conda conda issues 3573> but i can t do experiments I have no Mac

Yuan Mei · Answer

I can compile a minimal set of cairo demos <https gitlab com cairo cairo demos tree master X11> which links to all the above mentioned libraries and renders to XQuartz and they work fine I don t think `libcairo 2 dylib` is the clear culprit here

Stefan Schippers · Answer

May be the crash of magic is also an issue on my system magic d CAIRO works fine

Stefan Schippers · Answer

May be the problem is when an application tries to mix Xlib graphics and cairo graphics on the same window pixmap Xschem draws lines and shapes on an offscreen pixmap cairo draws on a surface that is linked to the same pixmap then the pixmap data is copied to the window The pixmap is used to restore the window when a redraw is needed

Stefan Schippers · Answer

I tried to do all graphic operation in xschem with cairo in the past but line rectangle polygon drawing in Cairo was way slower than Xlib so i was really disappointed

Tim Edwards · Answer

1 < Stefan Schippers> No I haven t encountered that problem before but reading through the thread I agree that the issue is almost certainly that objects are being rendered into different buffers 2 < Yuan Mei> I would really like to know where magic crashed which can be done by running gdb on magicexec which is an exectuable 3 < Stefan Schippers> Over time the Cairo graphics library has been able to make more better use of video hardware so it may be a lot better now than your early experience with it

Stefan Schippers · Answer

Thank you < Tim Edwards> It is funny that when the window is unfocused everything shows fine may be just because the two separate buffers are overlayed by some compositor i don t know and when window is focused only the cairo stuff is visible

Yuan Mei · Answer

< Tim Edwards> Here s the debugger output on `magicexec` when launched with ` d CAIRO` ```lldb tcltk magicexec d CAIRO lldb target create tcltk magicexec Current executable set to opt OpenICEDA src magic tcltk magicexec arm64 lldb settings set target run args d CAIRO lldb run Process 50623 launched opt OpenICEDA src magic tcltk magicexec arm64 Use openwrapper to create a new GUI based layout window Use closewrapper to remove a new GUI based layout window Magic 8 3 revision 388 Compiled on Mon Mar 27 21 48 15 PDT 2023 Starting magic under Tcl interpreter Using the terminal as the console Processing system magicrc file New windows will not have a title caption New windows will not have scroll bars New windows will not have a border Process 50623 stopped thread 1 queue = com apple main thread stop reason = EXC BAD ACCESS code=1 address=0x2c frame 0 0x0000000102b2e438 tclmagic dylib`DBPaintPlane0 plane=0x0000600000c0c330 area=error summary string parsing error resultTbl= U00000003 U00000001 U00000002 U00000003 U00000005 U00000005 U00000006 a b t n v f r U0000000e U0000000f U00000010 U00000011 U00000012 U00000013 U00000014 U00000015 U00000016 U00000017 U00000018 U00000019 U0000001a U0000001b U0000001c U0000001d U0000001e U0000001f $ amp + 0123456789 lt = gt ABCDEFGHIJKLMNOPQRSTUVWXYZ ^ `abcdefghijklmnopqrstuvwxyz | ~ U0000007f x80 x81 x82 x83 x84 x85 x86 x87 x88 x89 x8a x8b x8c x8d x8e x8f x90 x91 x92 x93 x94 x95 x96 x97 x98 x99 x9a x9b x9c x9d x9e x9f xa0 xa1 xa2 xa3 xa4 xa5 xa6 xa7 xa8 xa9 xaa xab xac xad xae xaf xb0 xb1 xb2 xb3 xb4 xb5 xb6 xb7 xb8 xb9 xba xbb xbc xbd xbe xbf xc0 xc1 xc2 xc3 xc4 xc5 xc6 xc7 xc8 xc9 xca xcb xcc xcd xce xcf xd0 xd1 xd2 xd3 xd4 xd5 xd6 xd7 xd8 xd9 xda xdb xdc xdd xde xdf xe0 xe1 xe2 xe3 xe4 xe5 xe6 xe7 xe8 xe9 xea xeb xec xed xee xef xf0 xf1 xf2 xf3 xf4 xf5 xf6 xf7 xf8 xf9 xfa xfb xfc xfd xfe xff U00000004 U00000001 U00000002 U00000005 U00000004 U00000005 U00000006 a b t n v f r U0000000e U0000000f U00000010 U00000011 U00000012 U00000013 U00000014 U00000015 U00000016 U00000017 U00000018 U00000019 U0000001a U0000001b U0000001c U0000001d U0000001e U0000001f $ amp + 0123456789 lt = gt ABCDEFGHIJKLMNOPQRSTUVWXYZ ^ `abcdefghijklmnopqrstuvwxyz | ~ U0000007f x80 x81 x82 x83 x84 x85 x86 x87 x88 x89 x8a x8b x8c x8d x8e x8f x90 x91 x92 x93 x94 x95 x96 x97 x98 x99 x9a x9b x9c x9d x9e x9f xa0 xa1 xa2 xa3 xa4 xa5 xa6 xa7 xa8 xa9 xaa xab xac xad xae xaf xb0 xb1 xb2 xb3 xb4 xb5 xb6 xb7 xb8 xb9 xba xbb xbc xbd xbe xbf xc0 xc1 xc2 xc3 xc4 xc5 xc6 xc7 xc8 xc9 xca xcb xcc xcd xce xcf xd0 xd1 xd2 xd3 xd4 xd5 xd6 xd7 xd8 xd9 xda xdb xdc xdd xde xdf xe0 xe1 xe2 xe3 xe4 xe5 xe6 xe7 xe8 xe9 xea xeb xec xed xee xef xf0 xf1 xf2 xf3 xf4 xf5 xf6 xf7 xf8 xf9 xfa xfb xfc xfd xfe xff U00000005 U00000001 U00000002 U00000005 U00000005 U00000005 U00000006 a b t n v f r U0000000e U0000000f U00000010 U00000011 U00000012 U00000013 U00000014 U00000015 U00000016 U00000017 U00000018 U00000019 U0000001a U0000001b U0000001c U0000001d U0000001e U0000001f $ amp + 0123456789 lt = gt ABCDEFGHIJKLMNOPQRSTUVWXYZ ^ `abcdefghijklmnopqrstuvwxyz | ~ U0000007f x80 x81 x82 x83 x84 x85 x86 x87 x88 x89 x8a x8b x8c x8d x8e x8f x90 x91 x92 x93 x94 x95 x96 x97 x98 x99 x9a x9b x9c x9d x9e x9f xa0 xa1 xa2 xa3 xa4 xa5 xa6 xa7 xa8 xa9 xaa xab xac xad xae xaf xb0 xb1 xb2 xb3 xb4 xb5 xb6 xb7 xb8 xb9 xba xbb xbc xbd xbe xbf xc0 xc1 xc2 xc3 xc4 xc5 xc6 xc7 xc8 xc9 xca xcb xcc xcd xce xcf xd0 xd1 xd2 xd3 xd4 xd5 xd6 xd7 xd8 xd9 xda xdb xdc xdd xde xdf xe0 xe1 xe2 xe3 xe4 xe5 xe6 xe7 xe8 xe9 xea xeb xec xed xee xef xf0 xf1 xf2 xf3 xf4 xf5 xf6 xf7 xf8 xf9 xfa xfb xfc xfd xfe xff undo=0x0000000000000000 method= 0 at DBpaint c 277 5 274 start p x = area gt r xbot 275 start p y = area gt r ytop 1 276 tile = plane gt pl hint gt 277 GOTOPOINT tile amp start 278 279 Each iteration visits another tile on the LHS of the search area 280 while TOP tile gt area gt r ybot Target 0 magicexec stopped lldb ```

Tim Edwards · Answer

< Yuan Mei> Unfortunately that s not too helpful since an error on `GOTOPOINT` means that the corner stitched tile database got corrupted which would have happened some unknown time earlier Running `valgrind` on `magicexec` might or might not catch the problem when it occurs