X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Content-Type: multipart/alternative; boundary="2XQLBHQXRCBSAFWOGJPHEnhgwp" MIME-Version: 1.0 User-Agent: GWP-Draft X-Originator: 78.11.203.93 X-FactoryStamp: H--- Date: Fri, 04 May 2018 14:36:57 +0200 X-Draft-Variant: reply X-Draft-Parentmailid: 035c23ca72344057609e6553 X-Draft-Contenttype: text/html Subject: =?UTF-8?Q?Odp=3A_Re=3A_=5Bgeda-user=5D_Opengl_PCB_and_mainline_PCB_-_pcb-rnd_aspects?= From: "michalwd1979 (michalwd1979 AT o2 DOT pl) [via geda-user AT delorie DOT com]" To: =?UTF-8?Q?geda-user=40delorie=2Ecom?= Message-ID: <7da892c189bd49838d6ce6eb2c2628e4@grupawp.pl> In-Reply-To: <> References: <647dca2ad89a4415ad980da6e5cdc701 AT grupawp DOT pl> X-WP-MailID: 1aa3210a025cd09764461f1c696d5ecd X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 0000010 [kQOE] 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 --2XQLBHQXRCBSAFWOGJPHEnhgwp Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Hello Igor, Thanks for reply. The features of pcb-rnd are impressive and = I really like the fast development of the branch. I remember back then when= we talked about opengl and I've tried to merge some of the rendering c= ode but my programming skills were good not enough, sorry... =C2=A0 I am= not sure if the problem is my >10 years old PC, my hardly tuned gentoo,= wrong compile options or just a bad luck, but I always had speed problems = with anything but Peter's opengl branch (recently mainline pcb become s= imilar in rendering speed). Today I've tried fresh compiled pcb-rnd 1.2= .8 with default: ./configure --prefix=3D/usr/local --buildin-hid_gtk2_gl -= -disable-hid_gtk2_gdk make Loading more complicated 4 layers board to pc= b-rnd makes working on it impossible. Moving cursor takes about 15s with cp= u load at 100%, zooming in/out is even slower. I know that my equipment is = nothing compared to current (even low-end) machines, but still - the same b= oard in mainline or opengl pcb moves/zooms in almost no time. If You want = me to perform more test with different configure options or want more data = about rest of the system, then let me know. Maybe I have something very wro= ng here. Best Regards, Michael Widlok Dnia 30 kwietnia 2018 19:33 mic= halwd1979 < gedau AT igor2 DOT repo DOT hu > napisa=C5=82(a): Hello Michael, = On Mon, 30 Apr 2018, michalwd1979 ( michalwd1979 AT o2 DOT pl ) [via geda-user= @delorie.com ] wrote: rendering. Some time ago I've tried to check if= it is possible to incorporate opengl code to pcb-rnd, but it turns out th= at it is out of my reach. We have a working opengl HID in pcb-rnd for mo= re than a year by now. If you mean incorporating more of Peter's 3d r= elated patches: in pcb-rnd we want to have a 2.5d editor, not a 3d editor,= so the 3d parts shouldn't be merged. Instead we have an openscad ex= port plugin that lets openscad do very nice 3d renders. Btw, merging any= thing forth and back between pcb-rnd and mainline became hard lately, beau= se around summer 2016 I decided to change project direction and really go = and fix our decade old bugs and desing problems, see below. This obviously= made the code diverge a lot. By the way I was comparing both versions an= d I found some differences (not sure if this is planned or not). With Pete= rs openGL version I can draw tracks on soldermask layer (create holes in s= oldermask), while with mainline pcb it is impossible. In pcb-rnd we went= on cleaning up the code and replaced most of the data model during the pa= st ~1 year. Thus we also have editable soldermask layer -- but not as a pa= tch or fix, but as a natural consequence of the new data model that doesn&= #39;t have special cases for the mask layer. And it's not in a branch,= but in production code, already tested on a number of fabbed boards, than= ks to our users. (The data model redesign solved a lot of our decade old = problems the same way, without adding more kludges on the existing kludges= . We have editable paste layer too, and footprints can contain any of thos= e edits: any object on any layer, including text on mask, polygon on paste= or arc on outline. Plus anything can become a "pad" and thermal w= orks on any shape - you don't need to draw tiny lines manually to conn= ect your smd pads to polygons any more. And polygons can clear other polyg= ons so you don't need to cheat with thick lines to draw a PSU. Oh, alm= ost forgot: we have padstacks, which can be used as pins or pads or vias, = and offer arbitrary convex polygon shapes, don't force you to have the= same pad shape on all layers. And padstacks support blind/buried vias.) = Regards, Igor2=0D --2XQLBHQXRCBSAFWOGJPHEnhgwp Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hello Igor,

Thanks for reply. The features of pcb-rnd are impressive= and I really like the fast development of the branch. I remember back then= when we talked about opengl and I've tried to merge some of the rendering = code but my programming skills were good not enough, sorry...  
I am not sure if the problem is my >10 years old PC, my hardly tuned g= entoo, wrong compile options or just a bad luck, but I always had speed pro= blems with anything but Peter's opengl branch (recently mainline pcb become= similar in rendering speed). Today I've tried fresh compiled pcb-rnd 1.2.8= with default:
./configure --prefix=3D/usr/local --buildin-hid_gtk2_gl -= -disable-hid_gtk2_gdk
make

Loading more complicated 4 layers boar= d to pcb-rnd makes working on it impossible. Moving cursor takes about 15s = with cpu load at 100%, zooming in/out is even slower. I know that my equipm= ent is nothing compared to current (even low-end) machines, but still - the= same board in mainline or opengl pcb moves/zooms in almost no time.
If = You want me to perform more test with different configure options or want m= ore data about rest of the system, then let me know. Maybe I have something= very wrong here.

Best Regards,
Michael Widlok


Dnia 30 kwietnia 2018 19:33 michalwd1979 <= ;gedau AT igor2 DOT repo DOT hu> napisa= =C5=82(a):

Hel= lo Michael,

On Mon, 30 Apr 2018, michalwd1979 = (michalwd1979 AT o2 DOT pl) [via geda-user AT delorie DOT com] wrote:

rendering. Some time ag= o I've tried to check if it is possible to
incorporate opengl= code to pcb-rnd, but it turns out that it is out of my
reach= .

We have a working opengl HID in= pcb-rnd for more than a year by now.

If you m= ean incorporating more of Peter's 3d related patches: in pcb-rnd
<= div>we want to have a 2.5d editor, not a 3d editor, so the 3d parts shouldn= 't
be merged.

Instead we have an= openscad export plugin that lets openscad do very nice
3d re= nders.

Btw, merging anything forth and back be= tween pcb-rnd and mainline became
hard lately, beause around = summer 2016 I decided to change project
direction and really = go and fix our decade old bugs and desing problems,
see below= . This obviously made the code diverge a lot.

By the way I was comparing both versions and = I found some differences (not
sure if this is planned or not)= . With Peters openGL version I can draw
tracks on soldermask = layer (create holes in soldermask), while with mainline
pcb i= t is impossible.

In pcb-rnd we we= nt on cleaning up the code and replaced most of the data
mode= l during the past ~1 year. Thus we also have editable soldermask layer
<= /div>
-- but not as a patch or fix, but as a natural consequence of the= new data
model that doesn't have special cases for the mask = layer. And it's not in
a branch, but in production code, alre= ady tested on a number of fabbed
boards, thanks to our users.=

(The data model redesign solved a lot of our = decade old problems the same
way, without adding more kludges= on the existing kludges. We have editable
paste layer too, a= nd footprints can contain any of those edits: any object
on a= ny layer, including text on mask, polygon on paste or arc on outline.
Plus anything can become a "pad" and thermal works on any shape - = you
don't need to draw tiny lines manually to connect your sm= d pads to
polygons any more. And polygons can clear other pol= ygons so you don't need
to cheat with thick lines to draw a P= SU. Oh, almost forgot: we have
padstacks, which can be used a= s pins or pads or vias, and offer arbitrary
convex polygon sh= apes, don't force you to have the same pad shape on all
layer= s. And padstacks support blind/buried vias.)

R= egards,

Igor2

--2XQLBHQXRCBSAFWOGJPHEnhgwp--