Mail Archives: geda-user/2016/08/29/23:22:53
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: <alpine DOT DEB DOT 2 DOT 00 DOT 1608300514521 DOT 7286 AT igor2priv>
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--
- Raw text -