CAD style rectangular mouse selection

[martinjankoehler]

Many CAD programs, including KiCad, offer two rectangular selection modes:

1. starting top/left, dragging towards right/down: selection as-is currently in Xschem (only stuff fully enclosed is selected)
2. starting bottom/right, dragging towards top/left: selection is also done for stuff that is partially intersected

[StefanSchippers]

I have committed a first implementation. I have also added dynamic selection of objects as soon as they are enclosed / intersected by the selection rectangle. They will be greyed out immediatley and not at the end.

Can you please also check the same (un)selection with the 'Alt' key pressed. This should unselect selected objects, and the same criteria for selection applies.

Notice: for now I am using the X direction only:

• If you start and move to the right, fully enclosed objects will be selected/unselected.
• If you start and move to the left, intersected objects will be selected/unselected.

This because I did not know what to do if user starts top/right or bottom/left. The criteria can be changed easily as long as it is consistent.

Thanks

[olisnr]

its working great! the driver-fix makes it flicker, but after releasing the mouse the selection is perfekt

[StefanSchippers]

@olisnr can you plase test latest xschem commit, I think the "driver fix" is now optimized and when doing area selects the selection no more flickers. I think after some extensive testing this drawing mode will become the default, leaving the "tiled fill mode" as an option for purists who value energy saving in addition to performance.

I expect some glitches so if you see one or some please let me know.

[olisnr]

the new "fix for GPUs with broken tilted fill" works calm now. i think this issue is solved and can be closed. the only thing that derange the screen is the slow refresh rate if You have many plots with data that needs to be updated at zooming. the solar_panel.sch example is very slow on a Intel Core i5-6200U HD Graphics 520 and 4k monitor. with out data its always fast.

[StefanSchippers]

If you want to do a test create a minimal xorg.conf that specifies Option "PageFlip" "false". On my Intel 620HD this speeds up everything by 5x or more. Of course verify if this not conflict with the desktop stuff.

Section "InputClass"
   Identifier   "Touchpad"
   Driver       "libinput"
   Option "Tapping" "true"
   Option "TappingButtonMap" "lmr"
EndSection

Section "Device"
     Identifier "intel"
     Driver           "intel"
     Option "PageFlip" "false"
EndSection

Section "Screen"
    Identifier  "Screen"
    Device      "intel"
EndSection

Section "ServerLayout"
    Identifier  "Layout"
    Screen      "Screen"
EndSection

[olisnr]

i will try, but my driver is "i915"

[olisnr]

i tested it on the X27o (i5-6200U HD Graphics 520), and it was really faster. i see rarely some strange flicker in chromium when loading web-pages and:

the Xschem menues are always on monitor 1, even if the program runs on monitor 2.

[StefanSchippers]

the Xschem menues are always on monitor 1, even if the program runs on monitor 2.

I think is yet another thing that has to do with the cinnamon desktop. May be if you comment out the PageFlip option things turn back right? Of course I can't see this happening. May be i should try to boot the cinnamon live image...

[StefanSchippers]

I have done the test on mint-cinnamon 21.2 , with pageflip false set and in the default configuration (no xorg.conf at all) and in both cases things are displayed correctly.

https://github.com/StefanSchippers/xschem/assets/69359491/733e404d-ac95-4867-a43d-62b402c53fd6

[olisnr]

now i deleted all but

Section "Device"
     Identifier "intel"
     Driver           "intel"
     Option "PageFlip" "false"
EndSection

in the /etc/X11/xorg.conf and its working all correct.

likely the Screen or ServerLayout made problems

[StefanSchippers]

Oh yes, this is possible. May be the desktop sets some variables or sends some commands (may be via xrandr) to the server, and then the least you specify the better it is.

Verify if there is no already some settings in /etc/X11/xorg.conf.d/ directory. Thanks for testing.

[olisnr]

there is an other update: i tested the /etc/X11/xorg.conf configuration with the mate-desktop, and it was working, but the the cinnamon-desktop crashes

[olisnr]

/etc/X11/xorg.conf.d/ is empty

[StefanSchippers]

Yes on an old samsung laptop with mint/cinnamon 21.2 I did the same test and if did not crash, but the desktop backround was corrupted, pointing to some memory area where it looks like cinnamon stores icons thumbnails, various cached images. Looks it uses free VRAM for caching images / textures for faster access. This will slow down other applications that need offscreen pixmaps (double buffering windows etc).

[olisnr]

if i understand this correct: other graphical SW uses some graphic-libraries like Qt that implement all this driver-error workaround?

[StefanSchippers]

I don't know, I think nobody ever cares to do things in an optimized way like I originally wanted to do. If a small piece of a window needs to be restored instead of carefully restoring only the damaged part modern toolkits throw the whole save buffer onto the window. This means if You have an oblique line from 0,0 to 1919,1079 instead of drawing an oblique line on top of it, painted with the save buffer, they throw the whole HD image into the window. 8MBytes of memory transfer instead of ~2500 bits. Just for the record I have saved into my xschem video tutorials section this interesting research I did on the broken driver issue. If you have a couple of minutes take a look. It is really surprising.

[olisnr]

yes, thats interesting, that many driver cant update horizontally. but i think, today anti-aliasing of lines and curves are standard, as example at postscript-fonts. and with anti-aliasing, this kind of removing the drawn line will be difficult. so may be today its best to let drawing do the GPU and copy the DMA and dont try to minimize the copied data, but to relieve the CPU. if the HW does to much work in the background, but the CPU dont have to or work it self, the SW will be faster even if the method is wasteful.

[olisnr]

for drawing lines You could use: https://en.wikipedia.org/wiki/NEC_%C2%B5PD7220 :)

[olisnr]

raster graphics is prodiagal anyway, compared with storage CRTs: https://www.youtube.com/watch?v=0_UDUSuxujg&ab_channel=MontyMcGraw

[olisnr]

are the texts and the lines drawn by the same library in Xschem?

[martinjankoehler]

Hey @StefanSchippers, thanks for adopting this! The selection preview is cool, but I might have found an issue.

Testing Report

Issue: selection preview not always updated

Steps to reproduce:

• while dragging, the wires enclosed are drawn grey (nice preview)
• EXPECTED: but when the user changes the selection (i.e. retracts towards the origin point of the rectangle), then the preview should be updated, and with full retraction nothing should be grey
• OBTAINED: "once it's grey, it stays grey"

The same is reproducable with the "mirrored" ALT-mode.

[StefanSchippers]

For now I have added a tcl variable that can be set in xschemrc: set incremental_select 0|1 if set to 0 the selection will be shown at end of area select. If set to 1 objects will be selected while moving, but as you said 'once it is grey it remains grey'.

Unselecting while retracting is complicated since xschem allows (using the Shift key) multiple area selections. While retracting on the 2nd or 3rd (or whatever else) area select some objects that are left outside the rectangle must be unselected. But there is for now no separate list of selected objects that were already selected before dragging (these should not be unselected) and the objects selected in current/last drag operation.

I will do the change later on as it will require more code to be put in place.

[olisnr]

set incremental_select 0 is perfect.