Some people report garbage in xschem while drawing stuff, for example while placing a wire. (see 1st picture) This is due to some Xorg drivers not correctly implementing tiled fills for all graphic primitives. In many cases a simple change in the

xorg.conf

file (disable

PageFlip

) will fix the issue (this is for Intel GPUs) . Basically this change disables acceleration on 2D primitives and the result could be also a 5x speed boost in some 2D operations, but most importantly correct operation. However if you are unable to do so (may be because the desktop environment uses a compositing window manager, so the OpenGL layer can not be avoided) Xschem has now an option to use a different window restoration technique that does not use this Tiled fill method.

View -> Fix for GPUs with broken tiled fill

. This alternative drawing method has now been optimized to be on par with the default drawing engine performance-wise. I will do some tests and eventually make this the default drawing method, since more and more "modern" desktop systems show this issue (I have never seen this for decades on SunOS, Solaris, IRIS and other serious machines). For the record: the frames per second i get with PageFlip enabled (buggy graphics) and disabled (correct behavior).

0_examples_top.sch: draw speed: 39.37281726944263 fps      0_examples_top.sch: draw speed: 101.58196987755987 fps
rom8k.sch: draw speed: 15.03341929108408 fps               rom8k.sch: draw speed: 53.33617792948957 fps
greycnt.sch: draw speed: 42.78672812742458 fps             greycnt.sch: draw speed: 244.9699503527567 fps
autozero_comp.sch: draw speed: 20.62211419289513 fps       autozero_comp.sch: draw speed: 106.63102820746133 fps
loading.sch: draw speed: 36.91994156803914 fps             loading.sch: draw speed: 279.4180653093158 fps
mos_power_ampli.sch: draw speed: 20.412398490843337 fps    mos_power_ampli.sch: draw speed: 50.99967870202418 fps
LCC_instances.sch: draw speed: 25.672117427688065 fps      LCC_instances.sch: draw speed: 153.87298298164808 fps
simulate_ff.sch: draw speed: 31.361267162453455 fps        simulate_ff.sch: draw speed: 398.77178290864134 fps

@Stefan Schippers this looks like the issue I’m seeing with chrome remote desktop that made the short cut keys for drawing basically useless. I’d use the tool bar icons but it was less than optimal. I’ll let you know if this change fixes all the issues.

@Mitch Bailey This looks to me more like an event reporting problem. When a keypress is generated the mouse position should be returned as well as the key. You can verify with this trivial one-liner tcl program:

schippes@asus:~$ wish
wish8.6 [~] bind . <KeyPress> { puts "Key: %K, mousex: %x, mousey: %y"}
wish8.6 [~] Key: a, mousex: 133, mousey: 107
Key: s, mousex: 146, mousey: 114
Key: space, mousex: 147, mousey: 123
Key: Escape, mousex: 145, mousey: 127
Key: g, mousex: 145, mousey: 127

Pressing a key while the pointer is inside the wish toplevel window should return the mouse coordinates relative to the wish window origin. The 0,0 point is in the upper left corner of the window and the Y axis increases downward. If you see strange coordinates (relative to the root window origin, for example) then there is not much the program can do, other than not using Keypress events with mouse coordinates. I know some remote connection tools have this issue, and should I have a chance to test one i could try a workaround for these broken X implementations.

@Stefan Schippers Looks like you’re right. No matter where the mouse is, I get the same result.

Key: c, mousex: -620, mousey: -378

Yes, something like this, although the

winfo pointerx [y]

reports the absolute position of the mouse, while I need the relative to window coordinates. But by using

winfo rootx [y]

that return the origin of the window in absolute (root) coordinates I can get the relative coordinate. This is now added in xschem, so if you are willing to check one day that would be great. You can do a

set fix_mouse_coord 1

in xschemrc to have this fix enabled or go in the

Options

menu (see image). If even the fix does not work may be some other mechanism to get the mouse coordinates in the window when a key is pressed needs to be done. All the boiler plate code is in place so this should now be straightforward.

Thanks @Stefan Schippers! Bindkeys are working as expected now.

@Stefan Schippers Thanks for the tip, definitely fixed drawing for me 😁 (other options wouldn't really be acceptable since they would lead to tearing in videos ...)

💪👍 Wow, Good. Thank you for testing. This is a proxy fix. I didn't have direct access for verifying.

Option "AccelMethod" "none"

might be better than disabling PageFlip.

@tnt this is probably overkill, as it disables everything. If you have a 3D app (where openGL does great job) it will slow down considerably.

Disabling Glamor doesn't disable OpenGL.

ok I have not much 3D stuff so i can't tell directly the effect