https://open-source-silicon.dev
Join Slack
I am using xchem on macOS Ventura 13.3.1. The xserver is XQuartz. I encountered a very strange GUI...
# xschem
y
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
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
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
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
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
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
Copy code
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
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:
Copy code
-L     Display the names and version numbers of the shared libraries that the object file uses.
y
Copy code
$ 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)
Copy code
$ 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
Can you please try xschem with menu option 
View->No XCopyArea drawing model
selected?
y
The behavior remains the same.
s
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
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.
IMG_1691.MOV
s
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
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
@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
xlogo behaves correctly. No disappearance.
s
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
Xlib graphics no longer disappears.
s
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
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
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
Copy code
otool -L /opt/OpenICEDA/lib/magic/tcl/tclmagic.so
shows the same cairo lib as xschem does.
y
tclmagic.so
links to the same 
/opt/local/lib/libcairo.2.dylib
but 
magic -d CAIRO
gives me segmentation error.
s
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
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
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
(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
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
@Tim Edwards Here's the debugger output on 
magicexec
when launched with 
-d CAIRO
Copy code
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
@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.
y
The strange behavior related to cairo is no longer there. Just compiled xschem with the latest packages provided by macports and XQuartz.
11 Views
Open in Slack
PreviousNext
Powered by

What is Linen?

Linen is a search-engine friendly community platform. We offer integrations with existing Slack/Discord communities and make those conversations Google-searchable.

Powered by