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="2:SAEWJIARXUFCJSLPFEIN:nhgwp"
MIME-Version: 1.0
User-Agent: GWP-Draft
Date: Thu, 1 Sep 2016 09:53:13
Subject: =?UTF-8?Q?Odp=3A_=5Bgeda-user=5D_Re=3A_=5Bpcb-rnd=5D_opengl_support_=28was=3A_release_1=2E1=2E1=29?=
Message-ID: <79b7fcc8179f4d11ba5a5fa61e72e02f@gwp>
In-Reply-To: <alpine.DEB.2.00.1608300449140.7286@igor2priv>
References: <alpine DOT DEB DOT 2 DOT 00 DOT 1608300449140 DOT 7286 AT igor2priv> <alpine DOT DEB DOT 2 DOT 00 DOT 1608240609580 DOT 7286 AT igor2priv>  <53b7bc76fb144120bfa076ae7d6b63dc AT gwp>
Conversation-Id: c-165
From: "michalwd1979 (michalwd1979 AT o2 DOT pl) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: =?UTF-8?Q?geda-user=40delorie=2Ecom?= <geda-user AT delorie DOT com>
X-FactoryStamp: H---
X-Originator: 78.11.205.43
X-WP-MailID: 01773dc7fb4e43e10954f9519d5f705b
X-WP-AV: skaner antywirusowy poczty Nowej Poczty
X-WP-SPAM: NO 0000010 [wWNE]                               
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

--2:SAEWJIARXUFCJSLPFEIN:nhgwp
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

True, one of the reasons I forked back then was to change the default   com=
pilation setup, including opengl. Pcb-rnd has gone a long way since -   it&=
#39;s not a collection of random small changes, but has major improvements =
  (about 1/3 of all code lines seen some change). Some related to opengl   =
long term: as Erich mentioned, the code is much more modular now.   For exa=
mple we can compile multiple GUI HIDs, static or dynamic linked,   and choo=
se which one to use run-time. Thus there&#39;s no need to decide for   one =
or the other compile-time, thus the default setting we chose doesn&#39;t   =
&#34;exclude&#34; other settings. With the conf rewrite, which GUI to use o=
n   startup is just configuration setting. (We also have a much better buil=
d   system that dynamically enables/disables options depending on what libs=
   are found on the system - we don&#39;t risk configuration failures if op=
engl   deps are not found.)   In other words, we could have an opengl as a =
default-on plugin without   interfering with my (or anyone&#39;s) &#34;gl d=
oesn&#39;t work here&#34; policy.   That said, I still do not have:   - any=
 hardware+driver combo that&#39;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   it better than le=
arning opengl)   This means opengl in pcb-rnd happens if someone volunteers=
 to do it - or   at least do the porting of the GL part.   In fact the bigg=
est surprise for me was when I&#39;ve red that opengl setup (and possibly d=
ri) does not works for You. A few years ago there were problems with that, =
but now it works flawlessly - especially on older hardware. Anyway I will t=
ry dig into Peter&#39;s opengl pcb version to check how GL programming is c=
omplicated - completely new territory for me.   The easiest path would be t=
o revive the old opengl code in pcb-rnd and   then port your plugins:   1. =
The original code has the software render (gdk) and the opengl (gl)   code =
both as integral part of the gtk HID. We need to split the the gtk   HID in=
to a gtk frame plugin that does the UI (gtk-common: menus, dialog   boxes, =
etc) and a drawing engine plugin that would have two   implementations (a g=
tk-gdk and a gtk-gl). The drawing engine plugin would   depend on gtk-commo=
n. The user-visible plugin would be gtk-gdk and gtk-gl.   This needs some s=
cconfig backing (but we already have plugin-plugin   dependencies handled p=
roperly in svn HEAD). I can do this part, if somoene   does the one in poin=
t 3. It looks like a few hours of effort.   2. Forward porting of the code;=
 a lot of big infra has been changed or   entierly replaced in pcb-rnd so t=
he gl code most likely doesn&#39;t even   compile anymore. Since I have all=
 this in my head it&#39;d probably take only   a few hours for me to fix up=
 the gl code to compile again.   3. Once the infra is ready to handle gtk-g=
l again, and once it compiles   again, starts the hard work: to make sure i=
t works reasonably. This is   what I can&#39;t do at all. How much time it&=
#39;d take is somewhat random: it   might work out-of-the-box after the abo=
ve 2 points, or it may take days or   weeks to get it working. May take som=
e more time to merge post-fork   improvements on the gl code from mainline =
to pcb-rnd (I believe there was   no trackball at the time of the fork). Th=
is is the part that needs a   volunteer.   4. Port your plugins - pcb-rnd i=
s open to have a large collection of   plugins constantly maintained togeth=
er with core, avoiding bitrotting. The   modular layout and scconfig enable=
s us to do this without having to worry   about how many plugins we have. I=
 can offer some help and time on this   too - having more plugins is always=
 a good idea.   I will download pcb-rnd and check is I am able to understan=
d UI code and drawing engine. At the same time pcb-opengl drawing is better=
 then mainline (in my opinion), so I think it would be better to use it&#39=
;s code. Still it is a long way for me to, but I will try :-).=C2=A0 Thank =
You Igro2 and Erich for detailed answers.  Best Regards,  Michael Widlok=0D

--2:SAEWJIARXUFCJSLPFEIN:nhgwp
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div><br></div><div class=3D"nh_extra"><blockquote class=3D"nh_quote" style=
=3D"border-left: 2px solid #999; padding-left: 8px; margin: 0;"><div id=3D"=
gwp83ffb26e"><div>True, one of the reasons I forked back then was to change=
 the default <br></div><div>compilation setup, including opengl. Pcb-rnd ha=
s gone a long way since - <br></div><div>it's not a collection of random sm=
all changes, but has major improvements <br></div><div>(about 1/3 of all co=
de lines seen some change). Some related to opengl <br></div><div>long term=
: as Erich mentioned, the code is much more modular now.<br></div><div><br>=
</div><div>For example we can compile multiple GUI HIDs, static or dynamic =
linked, <br></div><div>and choose which one to use run-time. Thus there's n=
o need to decide for <br></div><div>one or the other compile-time, thus the=
 default setting we chose doesn't <br></div><div>"exclude" other settings. =
With the conf rewrite, which GUI to use on <br></div><div>startup is just c=
onfiguration setting. (We also have a much better build <br></div><div>syst=
em that dynamically enables/disables options depending on what libs <br></d=
iv><div>are found on the system - we don't risk configuration failures if o=
pengl <br></div><div>deps are not found.)<br></div><div><br></div><div>In o=
ther words, we could have an opengl as a default-on plugin without <br></di=
v><div>interfering with my (or anyone's) "gl doesn't work here" policy.<br>=
</div><div><br></div><div>That said, I still do not have:<br></div><div><br=
></div><div>- any hardware+driver combo that'd run an opengl port at usable=
 frame rate<br></div><div><br></div><div>- any knowledge or experience with=
 programming opengl<br></div><div><br></div><div>- desire to change the abo=
ve two (my time is limited too, and I can spend <br></div><div>it better th=
an learning opengl)<br></div><div><br></div><div>This means opengl in pcb-r=
nd happens if someone volunteers to do it - or <br></div><div>at least do t=
he porting of the GL part.<br></div></div></blockquote></div><div><br></div=
><div>In fact the biggest surprise for me was when I've red that opengl set=
up (and possibly dri) does not works for You. A few years ago there were pr=
oblems with that, but now it works flawlessly - especially on older hardwar=
e. Anyway I will try dig into Peter's opengl pcb version to check how GL pr=
ogramming is complicated - completely new territory for me.<br></div><div><=
br></div><div class=3D"nh_extra"><blockquote class=3D"nh_quote" style=3D"bo=
rder-left: 2px solid #999; padding-left: 8px; margin: 0;"><div id=3D"gwp83f=
fb26e"><div>The easiest path would be to revive the old opengl code in pcb-=
rnd and <br></div><div>then port your plugins:<br></div><div><br></div><div=
>1. The original code has the software render (gdk) and the opengl (gl) <br=
></div><div>code both as integral part of the gtk HID. We need to split the=
 the gtk <br></div><div>HID into a gtk frame plugin that does the UI (gtk-c=
ommon: menus, dialog <br></div><div>boxes, etc) and a drawing engine plugin=
 that would have two <br></div><div>implementations (a gtk-gdk and a gtk-gl=
). The drawing engine plugin would <br></div><div>depend on gtk-common. The=
 user-visible plugin would be gtk-gdk and gtk-gl. <br></div><div>This needs=
 some scconfig backing (but we already have plugin-plugin <br></div><div>de=
pendencies handled properly in svn HEAD). I can do this part, if somoene <b=
r></div><div>does the one in point 3. It looks like a few hours of effort.<=
br></div><div><br></div><div>2. Forward porting of the code; a lot of big i=
nfra has been changed or <br></div><div>entierly replaced in pcb-rnd so the=
 gl code most likely doesn't even <br></div><div>compile anymore. Since I h=
ave all this in my head it'd probably take only <br></div><div>a few hours =
for me to fix up the gl code to compile again.<br></div><div><br></div><div=
>3. Once the infra is ready to handle gtk-gl again, and once it compiles <b=
r></div><div>again, starts the hard work: to make sure it works reasonably.=
 This is <br></div><div>what I can't do at all. How much time it'd take is =
somewhat random: it <br></div><div>might work out-of-the-box after the abov=
e 2 points, or it may take days or <br></div><div>weeks to get it working. =
May take some more time to merge post-fork <br></div><div>improvements on t=
he gl code from mainline to pcb-rnd (I believe there was <br></div><div>no =
trackball at the time of the fork). This is the part that needs a <br></div=
><div>volunteer.<br></div><div><br></div><div>4. Port your plugins - pcb-rn=
d is open to have a large collection of <br></div><div>plugins constantly m=
aintained together with core, avoiding bitrotting. The <br></div><div>modul=
ar layout and scconfig enables us to do this without having to worry <br></=
div><div>about how many plugins we have. I can offer some help and time on =
this <br></div><div>too - having more plugins is always a good idea.<br></d=
iv></div></blockquote></div><div><br></div><div>I will download pcb-rnd and=
 check is I am able to understand UI code and drawing engine. At the same t=
ime pcb-opengl drawing is better then mainline (in my opinion), so I think =
it would be better to use it's code. Still it is a long way for me to, but =
I will try :-).&nbsp; Thank You Igro2 and Erich for detailed answers.<br></=
div><div>Best Regards,<br></div><div>Michael Widlok<br></div><div><br></div=
><div><br></div>
--2:SAEWJIARXUFCJSLPFEIN:nhgwp--