https://open-source-silicon.dev logo
Title
y

Yuan Mei

04/08/2023, 3:11 AM
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.
s

Stefan Schippers

04/08/2023, 5:06 PM
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.
y

Yuan Mei

04/08/2023, 5:29 PM
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.
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.
s

Stefan Schippers

04/09/2023, 8:24 AM
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.
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).
y

Yuan Mei

04/09/2023, 8:41 AM
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.
s

Stefan Schippers

04/09/2023, 8:45 AM
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
y

Yuan Mei

04/09/2023, 8:48 AM
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.
s

Stefan Schippers

04/09/2023, 9:11 AM
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
,
from otool manpage:
-L     Display the names and version numbers of the shared libraries that the object file uses.
y

Yuan Mei

04/09/2023, 9:25 AM
$ 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)
$ 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)
They are using the same X11, tcl, and tk libs.
s

Stefan Schippers

04/09/2023, 9:29 AM
Can you please try xschem with menu option
View->No XCopyArea drawing model
selected?
y

Yuan Mei

04/09/2023, 9:31 AM
The behavior remains the same.
s

Stefan Schippers

04/09/2023, 9:33 AM
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
y

Yuan Mei

04/09/2023, 9:44 AM
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.
Here is a video shot with cellphone. Notice the mouse pointer moves in and out of the window.
s

Stefan Schippers

04/09/2023, 10:02 AM
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?
y

Yuan Mei

04/09/2023, 10:04 AM
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.
s

Stefan Schippers

04/09/2023, 10:05 AM
@Tim Edwards Have you ever seen a similar weird behavior? I have no idea why this happens.
@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.
Can you test if the same happens with a trivial xlogo application?
y

Yuan Mei

04/09/2023, 10:10 AM
xlogo behaves correctly. No disappearance.
s

Stefan Schippers

04/09/2023, 10:14 AM
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
y

Yuan Mei

04/09/2023, 10:20 AM
Xlib graphics no longer disappears.
s

Stefan Schippers

04/09/2023, 10:27 AM
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...
y

Yuan Mei

04/09/2023, 10:34 AM
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!
s

Stefan Schippers

04/09/2023, 10:48 AM
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.
y

Yuan Mei

04/09/2023, 11:01 AM
tclmagic.so
links to the same
/opt/local/lib/libcairo.2.dylib
but
magic -d CAIRO
gives me segmentation error.
s

Stefan Schippers

04/09/2023, 11:11 AM
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).
y

Yuan Mei

04/09/2023, 11:21 AM
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.
s

Stefan Schippers

04/09/2023, 11:32 AM
May be, the crash of magic is also an issue, on my system magic -d CAIRO works fine.
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.
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.
t

Tim Edwards

04/09/2023, 2:22 PM
(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.
s

Stefan Schippers

04/09/2023, 2:40 PM
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
y

Yuan Mei

04/09/2023, 9:06 PM
@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 !\"#$%&'()*+,-./0123456789:;<=>?@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 !\"#$%&'()*+,-./0123456789:;<=>?@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 !\"#$%&'()*+,-./0123456789:;<=>?@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->r_xbot;
   275 	    start.p_y = area->r_ytop - 1;
   276 	    tile = plane->pl_hint;
-> 277 	    GOTOPOINT(tile, &start);
   278 	
   279 	    /* Each iteration visits another tile on the LHS of the search area */
   280 	    while (TOP(tile) > area->r_ybot)
Target 0: (magicexec) stopped.
(lldb)
t

Tim Edwards

04/10/2023, 12:59 PM
@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.