X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Tue, 30 Aug 2016 05:33:36 +0200 (CEST) X-X-Sender: igor2 AT igor2priv To: 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 cc: michalwd1979 AT o2 DOT pl Subject: [geda-user] Re: [pcb-rnd] opengl support (was: release 1.1.1) In-Reply-To: <53b7bc76fb144120bfa076ae7d6b63dc@gwp> Message-ID: References: <53b7bc76fb144120bfa076ae7d6b63dc AT gwp> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1247009930-1472526874=:7286" Content-ID: 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-1247009930-1472526874=:7286 Content-Type: TEXT/PLAIN; CHARSET=UTF-8; FORMAT=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: Hello Michael, On Mon, 29 Aug 2016, michalwd1979 wrote: >Dear Members & pcb-rnd Developers, > >While I've know that opengl and transparency was one of the reason that >Igor2 started pcb-rnd project I wonder if it is possible to get it back as= a >compile-time option. Now I'm using Peter's Clifton pcb-opengl version >(http://repo.or.cz/w/geda-pcb/pcjc2.git) with a few my=C2=A0 modifications= (very >simple modifications + a few plug-ins). I found that this version works >great on my old hardware, and I found that transparent layers & polygons + >3d trackball are functions that I use all the time. On the other side >pcb-rnd has some features that I really like to have.... True, one of the reasons I forked back then was to change the default=20 compilation setup, including opengl. Pcb-rnd has gone a long way since -=20 it's not a collection of random small changes, but has major improvements= =20 (about 1/3 of all code lines seen some change). Some related to opengl=20 long term: as Erich mentioned, the code is much more modular now. For example we can compile multiple GUI HIDs, static or dynamic linked,=20 and choose which one to use run-time. Thus there's no need to decide for=20 one or the other compile-time, thus the default setting we chose doesn't=20 "exclude" other settings. With the conf rewrite, which GUI to use on=20 startup is just configuration setting. (We also have a much better build=20 system that dynamically enables/disables options depending on what libs=20 are found on the system - we don't risk configuration failures if opengl=20 deps are not found.) In other words, we could have an opengl as a default-on plugin without=20 interfering with my (or anyone's) "gl doesn't work here" policy. That said, I still do not have: - any hardware+driver combo that'd run an opengl port at usable frame rate - any knowledge or experience with programming opengl - desire to change the above two (my time is limited too, and I can spend= =20 it better than learning opengl) This means opengl in pcb-rnd happens if someone volunteers to do it - or=20 at least do the porting of the GL part. > Do You know how >much work is needed to "mix" these 2 projects? Is it even possible to make= a >compile time option or the differences in the code are so large that such >thing would need a new project/fork? I can spend some time coding, but I'm >not a professional programmer, and I don't know pcb graphics - I want to >find out if it is even worth trying. The easiest path would be to revive the old opengl code in pcb-rnd and=20 then port your plugins: 1. The original code has the software render (gdk) and the opengl (gl)=20 code both as integral part of the gtk HID. We need to split the the gtk=20 HID into a gtk frame plugin that does the UI (gtk-common: menus, dialog=20 boxes, etc) and a drawing engine plugin that would have two=20 implementations (a gtk-gdk and a gtk-gl). The drawing engine plugin would= =20 depend on gtk-common. The user-visible plugin would be gtk-gdk and gtk-gl.= =20 This needs some scconfig backing (but we already have plugin-plugin=20 dependencies handled properly in svn HEAD). I can do this part, if somoene= =20 does the one in point 3. It looks like a few hours of effort. 2. Forward porting of the code; a lot of big infra has been changed or=20 entierly replaced in pcb-rnd so the gl code most likely doesn't even=20 compile anymore. Since I have all this in my head it'd probably take only= =20 a few hours for me to fix up the gl code to compile again. 3. Once the infra is ready to handle gtk-gl again, and once it compiles=20 again, starts the hard work: to make sure it works reasonably. This is=20 what I can't do at all. How much time it'd take is somewhat random: it=20 might work out-of-the-box after the above 2 points, or it may take days or= =20 weeks to get it working. May take some more time to merge post-fork=20 improvements on the gl code from mainline to pcb-rnd (I believe there was= =20 no trackball at the time of the fork). This is the part that needs a=20 volunteer. 4. Port your plugins - pcb-rnd is open to have a large collection of=20 plugins constantly maintained together with core, avoiding bitrotting. The= =20 modular layout and scconfig enables us to do this without having to worry= =20 about how many plugins we have. I can offer some help and time on this=20 too - having more plugins is always a good idea. In theory you could also try to take pcb-rnd improvements and port them to= =20 mainline (or forks/branches/spinoffs based on mainline) but because of=20 some infrastructural changes it probably requires much more effort, with=20 much less help from my side (I rather spend time on improving pcb-rnd=20 than improving mainline/branches). Regards, Igor2 --0-1247009930-1472526874=:7286--