X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Tue, 8 May 2018 11:02:50 +0200 (CEST) X-X-Sender: igor2 AT igor2priv To: "michalwd1979 (michalwd1979 AT o2 DOT pl) [via geda-user AT delorie DOT com]" X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu" From: gedau AT igor2 DOT repo DOT hu Subject: Re: Odp: Re: [geda-user] Opengl PCB and mainline PCB - pcb-rnd aspects In-Reply-To: Message-ID: References: <647dca2ad89a4415ad980da6e5cdc701 AT grupawp DOT pl> <7da892c189bd49838d6ce6eb2c2628e4 AT grupawp DOT pl> <7e30777e38284644814271a68f2c2119 AT grupawp DOT pl> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-545642738-1525770170=:8169" Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-545642738-1525770170=:8169 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Hello Michael, On Tue, 8 May 2018, michalwd1979 (michalwd1979 AT o2 DOT pl) [via geda-user AT delori= e.com] wrote: > >Here it is from 21.5 to 22.7 with 22.1 average. Very similar to single lay= er >version.=C2=A0 Great, thanks! This means it is not the layer compositing that's slow. >One more notice: With my board loaded even moving a cursor causes instant >100% cpu load for a few seconds, with benchmark() it is the same. Mainline >or opengl pcb never causes high cpu usage even with furious panning or >rotating. While sometimes the movement is not super smooth, GUI is always >very responsive. This is not the case with pcb-rnd, here I have to wait fo= r >a menu to open after for example cursor movement. Also turning ON/OFF >"subcircuits" layer makes a huge difference - maybe we are looking in the >wrong place?? Thanks, that's the next we can look at. I don't think we are looking in the wrong place. Knowing how the rendering= =20 works, I have a list of tests to perform to see what's slow and what's not= =20 slow. It may be that we figure at the end that it was only a single thing= =20 that caused all slowness, or it may be that a combination of 4..5 things=20 took the time. We'll find only if we test them each. The subc bbox is a xor draw thing; so what's next on my list (see also the= =20 1024 resistors test) is checking if the number of xor drawn lines matter. Mouse cursor movement makes the crosshair move. The crosshair is xor-drawn= =20 too. If our gl xor draw mechanism is slow in general, that explains why=20 any pan or cursor move is slow. Another rather unfortunate thing that happens when you move the crosshair= =20 is a full screen redraw, because of the invalidations. It's how we=20 inherited the code from the 2011 version - it's on my list to fix, but=20 haven't got to fix it yet. Tomorrow morning I will prepare something for=20 turning off the crosshair so we can test that too. Then I also plan to have an object type based test. So a lot of tests to do before we get a clear picture. Regards, Igor2 --0-545642738-1525770170=:8169--