Re: gEDA-user: PCB+GL rebased to git HEAD (with nanometers) - bugwith arcs?
Andrew and Kai-Martin, I've saved the broken (with wrong Q42) board using pcb+gl_experimantal.stgit branch. No problems with with pcb+gl, but I did not try to open broken file there. Anyway I remember that there was a situation when one version (after some moving/dragging components) showed wrong and one right arcs on the same file. My fault that I forgot to check if the error is only on screen or in file also, sorry. Anyway now it is all over, thanks Andrew! Best regards, Michael Widlok Dnia 23 sierpnia 2011 4:57 Andrew Poelstra as...@sfu.ca napisał(a): On Mon, Aug 22, 2011 at 05:31:26PM -0700, Andrew Poelstra wrote: On Sat, Aug 20, 2011 at 01:57:08PM +0200, michalwd1979 wrote: Dear Peter, I'm using newest version of pcb opengl from git and I found strange behaviour with arcs. This was caused by my commit: Fixed by commit 7b590a61. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL rebased to git HEAD (with nanometers) - bug with arcs?
On Mon, Aug 22, 2011 at 05:31:26PM -0700, Andrew Poelstra wrote: On Sat, Aug 20, 2011 at 01:57:08PM +0200, michalwd1979 wrote: Dear Peter, I'm using newest version of pcb opengl from git and I found strange behaviour with arcs. This was caused by my commit: Fixed by commit 7b590a61. -- Andrew Poelstra Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net Web: http://www.wpsoftware.net/andrew/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL rebased to git HEAD (with nanometers) - bug with arcs?
Andrew Poelstra wrote: This happens with git HEAD as well, not just the GL fork. It even happens when configuring with --disable-gl. It's a pretty neat bug - if you deselect the object after switching its layer, you can move it without problem. It is only when hitting 'b' and moving the object in one action that problems arise. For some reason I can't reproduce this. I tried to move the components while selected, just after I switched its layer with [b] in any combination I could think of. However, I see the circle in Q42 of test.pcb consistently shown the wrong way. This wrong arc shows up in gerbv, too. So it does not seem to be a just a glitch of the display on the canvas. ---)kaimartin(--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de - not happy with moderation of geda-user mailinglist ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL rebased to git HEAD (with nanometers)
On 08/19/2011 12:18 PM, Peter Clifton wrote: My PCB+GL branches are now rebased against git HEAD, with all the excellent work from Andrew Poelstra on the internal unit conversion to nanometers. Please test and let me know if you find any bugs. I've given it cursory testing, but haven't actually used it much myself yet. Hey Peter! Thank you for all of your excellent work. If I may make a suggestion...For those of us who don't access the repository regularly, and don't live and breathe git (I'm an SVN guy), it might be helpful to put a quickie command line (or two) in these sorts of announcements to tell us how to actually get that code. I'm sorry for being an idiot about it, and I'm a long-time developer myself so I'm generally pretty comfortable with this stuff, but I don't do git and don't even remember where the PCB repository is these days. I'm sure there are others in this situation who would also jump at the chance to try the latest code. Thanks, -Dave -- Dave McGuire Port Charlotte, FL ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL rebased to git HEAD (with nanometers)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dave McGuire wrote: If I may make a suggestion...For those of us who don't access the repository regularly, and don't live and breathe git (I'm an SVN guy), it might be helpful to put a quickie command line (or two) in these sorts of announcements to tell us how to actually get that code. Peters blog contains a howto for his git repo: http://pcjc2.blogspot.com/2011/02/pcbgl-repository-instructions.html - ---)kaimartin(--- - -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de - - not happy with moderation of geda-user mailinglist -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk5OwlsACgkQZ+Hj7ZLnhr/ruQCZAdKhqwZH4OVgv9I+Ew8NYbX0 xoMAn1ydOUz83pGGm/U/mm1Q4kSQ6zqz =yhvD -END PGP SIGNATURE- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL rebased to git HEAD (with nanometers)
On Fri, 19 Aug 2011 15:08:57 -0400 Dave McGuire mcgu...@neurotica.com wrote: On 08/19/2011 12:18 PM, Peter Clifton wrote: My PCB+GL branches are now rebased against git HEAD, with all the excellent work from Andrew Poelstra on the internal unit conversion to nanometers. Please test and let me know if you find any bugs. I've given it cursory testing, but haven't actually used it much myself yet. Hey Peter! Thank you for all of your excellent work. If I may make a suggestion...For those of us who don't access the repository regularly, and don't live and breathe git (I'm an SVN guy), it might be helpful to put a quickie command line (or two) in these sorts of announcements to tell us how to actually get that code. Peter Clifton's PCB+GL repository instructions: http://pcjc2.blogspot.com/2011/02/pcbgl-repository-instructions.html. Personally, I use Bazaar with the bzr-git plugin to access all the gEDA git repositories. That way I don't have to learn git's command scheme... :) For me, using bzr-git, the commands look like: 1. bzr git-import git://repo.or.cz/geda-pcb/pcjc2.git 2. bzr checkout --lightweight pcjc2.git/refs/heads/pcb+gl work-gl 3. cd work-gl ./autogen.sh ./configure make I think it's simpler than the native git commands, but maybe that's just me. Regards, Colin ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
2011/7/17 DJ Delorie d...@delorie.com: What is the transform between the numbers in the .pcb file and the actual representation on the board? Angle first, then stretch. There must be something more to it. Attached are two hand edited drawings where the first one has no stretching, e.g Radius=Width=Height The second one is the same drawing but with two of the arcs stretched. Notate that both start and end points have moved. Another point is that I cant find them, e.g Ctrl+R gives no hit. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user stretched-arc-1.pcb Description: application/pcb-layout stretched-arc-2.pcb Description: application/pcb-layout ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB GL stuff
Dave McGuire wrote: Hey folks. What's the preferred codebase for the fancy new GL stuff in PCB? git clone git://git.gpleda.org/pcb.git Yes, it is (almost) all in the main repository now! :-) ---)kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 not happy with moderation of geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
Igor Lopez: 2011/7/16 Andrew Poelstra as...@sfu.ca: There is a fairly informative discussion of this problem on SO: http://stackoverflow.com/questions/2945337/how-to-detect-if-an-ellipse-intersectscollides-with-a-circle I had a look and found one algebraic solution close to the one I have proposed. The correct methods given there generally require root-solvers, Why is the algebraic solution not correct? Because of false assumptions about the inner and outer arcs, see below. Since we rarely care about the exact distance, only is it between 0 and Radius it is probable that we could use a bisection method with very few iterations to get an answer. I am convinced we do not need any iterations or equation solvers. We just need to check with the transformed point coordinates in the equations for the two arcs where one is the inner arc and the other is the outer arc where the point radius has been subtrcacted respectively added to the arc lenghts(width, height). If the point intersects the equation for the inner arc is = 0 and the equation for the outer arc is = 0 and since it is not a complete ellipse one need to check that the angle between point and arc centerpoint is within the arcs limiting angles which is not to difficult if the limiting angles are known. You are assuming that the two arcs are ellipses, which they are not. E.g. if you draw an ellipse with a thick pen, the inner space will look more like an almond than an ellipse. Take an ellipse with a = 5 and b = 4, and add a thickness = 1 to the perimeter. The point Pb = (xb,yb) = (3, 16/5) = (3, 3.2) is on the ellipse. Go out 1 (thickness) from that point in the normal direction (see e.g. [1]), i.e. along the line y - 16/5 = mn * (x - 3), mn = a*a*yb / (b*b*xb) = (25*16/5) / (16*3) = 5/3 you will come to the point Pt = (xt, yt) = (3+3/k, 16/5 + 5/k) ~= (3.51, 4.06) where k = sqrt(34), 5.83 k 5.84 Now, check if Pt lies on the ellipse: x^2/at^2 + y^2/bt^2 = 1, where at = a+1 = 6, bt = b+1 = 5 (3+3/k)^2 / 36 + (16/5+5/k)^2 / 25 ~= 1.0016 1 i.e. the new arc is not an ellipse. /// If this error is small enougth to ignore, fine, but what error do we tolerate? Regards, /Karl Hammar [1] http://de.wikipedia.org/wiki/Ellipse#Normalengleichung_.28kartesische_Koordinaten.29 --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
2011/7/16 Karl Hammar k...@aspodata.se: Because of false assumptions about the inner and outer arcs, see below. Ahhaaa, I stand corrected, assumptions is never ever good and it should have been obvious when making the thickness large, e.g if as large as the short axis it would generate a inner 'not ellipse' with short axis equal to 0. Sorry for my noise, I only did some simple checks with small thickness and did not go all the way. If this error is small enougth to ignore, fine, but what error do we tolerate? Regards, /Karl Hammar [1] http://de.wikipedia.org/wiki/Ellipse#Normalengleichung_.28kartesische_Koordinaten.29 --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
On Sat, 2011-07-16 at 00:18 -0700, Andrew Poelstra wrote: There is a fairly informative discussion of this problem on SO: http://stackoverflow.com/questions/2945337/how-to-detect-if-an-ellipse-intersectscollides-with-a-circle Or you may look at http://www.geometrictools.com/Documentation/Documentation.html http://www.geometrictools.com/Documentation/DistanceEllipse2Ellipse2.pdf ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
My quick take on this: Do the math based on a zero-thickness arc, then offset the resulting distance by the arc half-thickness. I think this is more in line with how we *draw* the arcs. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
Stefan Salewski: http://www.geometrictools.com/Documentation/DistanceEllipse2Ellipse2.pdf It seems a little too general and it is a 35MB download [1]. Their code seems to be in LibMathematics/Intersection/Wm5IntrEllipse2Ellipse2.cpp and at a quick glance it seems to be a lot of calculations. Do you have any experience about their library ? Regards, /Karl Hammar [1] http://www.geometrictools.com/Downloads/WildMagic5p5.zip --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
2011/7/16 DJ Delorie d...@delorie.com: My quick take on this: Do the math based on a zero-thickness arc, then offset the resulting distance by the arc half-thickness. I think this is more in line with how we *draw* the arcs. I have not yet investigated on how the arcs are draw nor how they are beeing stretched. For the moment I have given up on the algebraic solution but will do some more investigations even if it is fruitless. It would be good if someone could tell me how the arc parameters are created and how they are used. For the moment I have not found a way to stretch them and if the rule is to use data in the .pcb file as true source even if the limiting angles are wrong for the (unknown how the have been created) stretched arc one need to understand the interpretation of the attributes DJ's stretched arc example had different height,width in the file but a ctrl+R did not reflect this. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
It would be good if someone could tell me how the arc parameters are created and how they are used. Edit the *.pcb file manually. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
2011/7/16 DJ Delorie d...@delorie.com: It would be good if someone could tell me how the arc parameters are created and how they are used. Edit the *.pcb file manually. OK, but that means I need to understand how the drawing mechanism interprets ther numbers. Currently with the stretched arcs you presented the 45 deg Delta in the file is not what is drawn. What is the transform between the numbers in the .pcb file and the actual representation on the board? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
What is the transform between the numbers in the .pcb file and the actual representation on the board? Angle first, then stretch. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
On Sat, 2011-07-16 at 19:16 +0200, Karl Hammar wrote: Stefan Salewski: http://www.geometrictools.com/Documentation/DistanceEllipse2Ellipse2.pdf It seems a little too general and it is a 35MB download [1]. Their code seems to be in LibMathematics/Intersection/Wm5IntrEllipse2Ellipse2.cpp and at a quick glance it seems to be a lot of calculations. Do you have any experience about their library ? Regards, /Karl Hammar I am using their solution for Distance point to line segment, it is fine. Many other sources, as the mathematica site, confuses it with the simpler solution for an infinite line. But I was in need for distance to finite line segment -- and I was not smart enough to find that simple solution myself. Of course math for ellipses is more difficult, but I think the www.geometrictools.com page is really nice, I have bookmarked it. But I have not looked at their ellipses code. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
Andrew Poelstra: On Thu, Jul 14, 2011 at 08:29:53PM +0200, Karl Hammar wrote: ... Why not just give a warning if width and height is not equal, saying that we don't really support ellipses for the moment, and be done with it. I could, I suppose, but as you mentioned in another post, there are muddled physical units. As that is what I am trying to fix, I need to make changes anyway. Ok. It would be nice if we could at least support the featureset of our file format, while I'm at it. I found in [1]: Given an ellipse: x^2 / a^2 + y^2 / b^2 = 1 where a = greater semiaxis b = lesser semiaxis a = b 0 e = sqrt( a^2 + b^2 ) = linear excentricity = focalpoint semidistance epsilon = e / a = numerical excentricity The equation of the normal to the ellipse: y - y1 = mn * (x - x1), where mn = (a*a * y1) / (b*b * x1) the point on the ellipse = (x1, y1) point on normal = (x, y) The length of the normal (to where it crosses the x-axis): n = b * sqrt(a*a*a*a - e*e * x1*x1) / (a*a) The length of the subnormal (as above but along the x-axis): sn = abs( b*b * x1 / (a*a) ) Hope that it helps. We're here if you need more help. Regards, /Karl Hammar [1] Mathematische formeln Dipl.-Ing. Hans-Jochen Bartsch Veb Fachbuschverlag Leipzig 1974 --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
Ethan Swint: On 07/14/2011 11:23 PM, Andrew Poelstra wrote: ... To do either one analytically looks like a 4th order equation must be solved. So I am looking for cheap iterative solutions, or approximations, instead. If the point is within the arc's bounding box, transform the point's global coordinates into the arc's local (x: major axis, y: minor axis) coordinates. Ack. Then the distance calculation is a no-brainer. Could you then show us the formula please ? Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
I am using the polar form of the ellipse given at: http://en.wikipedia.org/wiki/Ellipse#Polar_form_relative_to_center with theta the angle of the point we are checking. (Those cos and sin calculations are easy, just delta-x/len and delta-y/len.) With that I can calculate the distance from the point to an ellipse. Restricting this to an ellipse /segment/ is tricky, since as DJ pointed out, these are not real elliptical arcs, but stretched arcs, so the limiting angles do not correspond directly to actual angles. Adding explicit checks for distance from endpoints would give us an almost-correct solution. There are still pathologies I can think of with arcs whose thickness (or thickness + search radius) is greater than the minor axis, though.. -- Andrew Poelstra Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net Web: http://www.wpsoftware.net/andrew/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
Andrew Poelstra: I am using the polar form of the ellipse given at: http://en.wikipedia.org/wiki/Ellipse#Polar_form_relative_to_center with theta the angle of the point we are checking. (Those cos and sin calculations are easy, just delta-x/len and delta-y/len.) With that I can calculate the distance from the point to an ellipse. The shortest line from (x,y) to the ellipse goes through the normal to the ellipses perimeter. The normal does not generally go through the middlepoint of the ellipse. It crosses the line between the center and the nearest focal point. What you get with the above polar calculation is a little bigger value than the true distance, but it could serve as a first aproximation. You could take the minimum of the polar form through the center and through the focus, to get a better value. How accurate an value do we need, would minimum of ±5% and ±0.1mm be ok ? Restricting this to an ellipse /segment/ is tricky, since as DJ pointed out, these are not real elliptical arcs, but stretched arcs, so the limiting angles do not correspond directly to actual angles. ... Isn't that a bug to be fixed instead? Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
On Fri, Jul 15, 2011 at 09:45:42PM +0200, Karl Hammar wrote: Andrew Poelstra: I am using the polar form of the ellipse given at: http://en.wikipedia.org/wiki/Ellipse#Polar_form_relative_to_center with theta the angle of the point we are checking. (Those cos and sin calculations are easy, just delta-x/len and delta-y/len.) With that I can calculate the distance from the point to an ellipse. The shortest line from (x,y) to the ellipse goes through the normal to the ellipses perimeter. Ohh... of course. Darn. The normal does not generally go through the middlepoint of the ellipse. It crosses the line between the center and the nearest focal point. What you get with the above polar calculation is a little bigger value than the true distance, but it could serve as a first aproximation. You could take the minimum of the polar form through the center and through the focus, to get a better value. How accurate an value do we need, would minimum of ±5% and ±0.1mm be ok ? I suspect that determining an error bound on my method would be just as difficult (mathematically) as finding a different method. There is a fairly informative discussion of this problem on SO: http://stackoverflow.com/questions/2945337/how-to-detect-if-an-ellipse-intersectscollides-with-a-circle The correct methods given there generally require root-solvers, and I don't think we have one right now. We could throw one together or introduce a dependency on, say, the GNU Scientific Library. Since we rarely care about the exact distance, only is it between 0 and Radius it is probable that we could use a bisection method with very few iterations to get an answer. Restricting this to an ellipse /segment/ is tricky, since as DJ pointed out, these are not real elliptical arcs, but stretched arcs, so the limiting angles do not correspond directly to actual angles. ... Isn't that a bug to be fixed instead? It's a design flaw, but fixing it would break existing designs. -- Andrew Poelstra Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net Web: http://www.wpsoftware.net/andrew/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
2011/7/16 Andrew Poelstra as...@sfu.ca: There is a fairly informative discussion of this problem on SO: http://stackoverflow.com/questions/2945337/how-to-detect-if-an-ellipse-intersectscollides-with-a-circle I had a look and found one algebraic solution close to the one I have proposed. The correct methods given there generally require root-solvers, Why is the algebraic solution not correct? Since we rarely care about the exact distance, only is it between 0 and Radius it is probable that we could use a bisection method with very few iterations to get an answer. I am convinced we do not need any iterations or equation solvers. We just need to check with the transformed point coordinates in the equations for the two arcs where one is the inner arc and the other is the outer arc where the point radius has been subtrcacted respectively added to the arc lenghts(width, height). If the point intersects the equation for the inner arc is = 0 and the equation for the outer arc is = 0 and since it is not a complete ellipse one need to check that the angle between point and arc centerpoint is within the arcs limiting angles which is not to difficult if the limiting angles are known. Restricting this to an ellipse /segment/ is tricky, since as DJ pointed out, these are not real elliptical arcs, but stretched arcs, so the limiting angles do not correspond directly to actual angles. This is the true problem, if the limiting angles are not know then the problem is unsolvable but I assume there is a way of finding what the real limiting angles are. I have not looked into how they become stretched but there must be a systematic way the stretch transforms the arc. Isn't that a bug to be fixed instead? It's a design flaw, but fixing it would break existing designs. Well, one could still keep the (wrong when stretched) limiting angles and add new paramters to the struct for real angles. Now I also assume from looking at DJ's stretched arc that the axis length along the not stretched direction must also be recalculated. I'll be back. -- Andrew Poelstra Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net Web: http://www.wpsoftware.net/andrew/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
2011/7/14 Andrew Poelstra as...@sfu.ca: On Wed, Jul 13, 2011 at 01:01:34PM -0700, Colin D Bennett wrote: On Wed, 13 Jul 2011 10:02:28 -0600 Mark Rages markra...@gmail.com wrote: Stretched arcs are a misfeature. Can they be deprecated? Otherwise, they are just another object that cannot be rotated at arbitrary angles. There is no inherent reason elliptical arcs cannot be rotated arbitrarily. Any restriction on such rotation is simply due to implementation faults in pcb. The reason I bring this up is that the IsPointOnArc() in search.c assumes a circular arc right now. (Distance from elliptical arc segment is quite a tricky computational problem.) You can see this problem by drawing an stretched arc and trying to select and move it. Being a math major and all, you'd think I could fix this, but it eludes me... Good page: http://www.maa.org/joma/Volume8/Kalman/General.html CCW rotation through angle alpha will give the following equation Eq1 : 1 - A*x² - B*x*y - C*y² = 0 where A = cos(alpha)²/a²+sin(alpha)²/b² B = 2*cos(alpha)*sin(alpha)*(1/a²-1/b²) C = sin(alpha)²/a²+cos(alpha)²/b² and a is half axis length along x in non rotated state and b is half axis length along y in non rotated state. The ellipse should have the attributes, x centerpoint y centerpoint a half Axis length along X when non rotated b half Axix length along y when non rotaded alpha Rotation angle (in ccw direction) maybe even the A,B and C so they are only calculated once. Check if point px,py is on rotaded elliptic arc: 1) Translate point to use ellipse center as origin, Px = px-x Py = py-y 2) Insert Px, Py in Eq1 lval equal 0 - point is exactly on arc lval above zero - point is inside arc lval below zero - point is outside arc ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
I had a quick look at the routine and must say that I did not grasp the code.
It is probably due to some heavy optimizations.
My approach had been more in the line of:
// Assumption done on ArcType in that the StartAngle attribute is the
// arcs CCW rotation with zero meaning that attribute Width is along X
// and attribute Height is along Y
bool IsPointOnArc (float X, float Y, float Radius, ArcTypePtr Arc)
// Point is defined as a circle loctaed at X,Y with radius Radius
{
double pdx, pdx2, pdy, pdy2, cosAlpha, sinAlpha, al2, as2, bl2, bs2;
double Al, As, Bl, Bs, Cl, Cs; // Should be part of ARC struct and
updated accordingly.
double resSmall, resLarge;
// Translate point coordinates to local arc origin
pdx = X - Arc-X;
pdx2 = pdx*pdx;
pdy = Y - Arc-Y;
pdy2 = pdy*pdy;
// This could have been optimized if Al, As, Bl, Bs, Cl and Cs was
part of the Arc and only
// updated when needed, e.g at creation of ARC or modification of ARC.
// Note to myself, since the larger and smaller ellipses is a
function of the Radius it will not
// work unless the ARC had a memory with respect to which radius
have been used earlier, e.g let
// the ARC worry about how/when to calculate these values.
// Note this whole procedure is based on the equation governing a
rotated ellipse, see:
// http://www.maa.org/joma/Volume8/Kalman/General.html
// Here we calculate the two boundary ellipses, one on the inside
(As, Bs, Cs) and one on the outside
// (Al, Bl, Cl) where the geometry is given by the ellipse Height,
Width and its thickness.
// The radius of the point is added to the boundary in order to use
the point coordinates
// in the equations.
// Generally the eq is: 1-Ax²+Bx*y+C*x²= 0 and a given points
coordinates will result in the lVal
//0 for inside the ellipse,
// = 0 for on the ellipse
//0 for outside the ellipse
cosAlpha=cos(Arc-StartAngle*M_PI/180);
sinAlpha=sin(Arc-StartAngle*M_PI/180);
al2 =
1/((Arc-Width+Arc-Thickness/2+Radius)*(Arc-Width+Arc-Thickness/2+Radius));
bl2 =
1/((Arc-Height+Arc-Thickness/2+Radius)*(Arc-Height+Arc-Thickness/2+Radius));
as2 =
1/((Arc-Width-Arc-Thickness/2-Radius)*(Arc-Width-Arc-Thickness/2-Radius));
bs2 =
1/((Arc-Height-Arc-Thickness/2-Radius)*(Arc-Height-Arc-Thickness/2-Radius));
Al = cosAlpha*cosAlpha*al2+sinAlpha*sinAlpha*bl2;
Bl = -2*cosAlpha*sinAlpha*(al2-bl2);
Cl = sinAlpha*sinAlpha*al2+cosAlpha*cosAlpha*bl2;
As = cosAlpha*cosAlpha*as2+sinAlpha*sinAlpha*bs2;
Bs = -2*cosAlpha*sinAlpha*(as2-bs2);
Cs = sinAlpha*sinAlpha*as2+cosAlpha*cosAlpha*bs2;
resSmall = 1-As*pdx2-Bs*pdx*pdy-Cs*pdy2;
resLarge = 1-Al*pdx2-Bl*pdx*pdy-Cl*pdy2;
// For point to be on arc - outside the small ellipse and inside
the large ellipse
if((resSmall=0) (resLarge=0))
return (true);
else
return (false);
}
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
On Thu, Jul 14, 2011 at 08:50:10AM +0200, Igor Lopez wrote: Check if point px,py is on rotaded elliptic arc: 1) Translate point to use ellipse center as origin, Px = px-x Py = py-y 2) Insert Px, Py in Eq1 lval equal 0 - point is exactly on arc lval above zero - point is inside arc lval below zero - point is outside arc The problem here is that the elliptical arc has nonzero thickness (usually, if it is a drawn solder arc). So I actually need to see if the point is /within a certain radius/ of the arc. For that I need the distance from the point to the arc, or to draw a circle around the point and check if that intersects the arc. To do either one analytically looks like a 4th order equation must be solved. So I am looking for cheap iterative solutions, or approximations, instead. -- Andrew Poelstra Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net Web: http://www.wpsoftware.net/andrew/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
On Thu, Jul 14, 2011 at 01:24:45PM +0200, Karl Hammar wrote: Andrew Poelstra: On Wed, Jul 13, 2011 at 01:01:34PM -0700, Colin D Bennett wrote: Mark Rages markra...@gmail.com wrote: Stretched arcs are a misfeature. Can they be deprecated? ... The reason I bring this up is that the IsPointOnArc() in search.c assumes a circular arc right now. (Distance from elliptical arc segment is quite a tricky computational problem.) There is some (physical) dimesion awkwardnesses going on in this routine: I am trying to avoid square units entirely and just use the Distance() function from misc.c instead. Maybe the function call is too expensive, but testing will tell us that. Certainly I see no reason that squaring should be cheaper than sqrt, which is the tradeoff made all over the code. In addition to the unit awkwardness, I am also trying to clear up the micro-optimizations that assume a specific architecture and ancient compiler. -- Andrew Poelstra Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net Web: http://www.wpsoftware.net/andrew/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
2011/7/15 Andrew Poelstra as...@sfu.ca: On Thu, Jul 14, 2011 at 08:50:10AM +0200, Igor Lopez wrote: Check if point px,py is on rotaded elliptic arc: 1) Translate point to use ellipse center as origin, Px = px-x Py = py-y 2) Insert Px, Py in Eq1 lval equal 0 - point is exactly on arc lval above zero - point is inside arc lval below zero - point is outside arc The problem here is that the elliptical arc has nonzero thickness (usually, if it is a drawn solder arc). So I actually need to see if the point is /within a certain radius/ of the arc. For that I need the distance from the point to the arc, or to draw a circle around the point and check if that intersects the arc. That is why I proposed two equations, one for the inner arc and one for the outer arc. Add resp Subtract half the arc thickness in the expression for the equations parameters and if the point has a radius one needs to add resp subtract that as well. With this approach it is rather simple to check if the point intersects the arc by evaluating the left side values of both equations. The point will intersect if the left hand value for the small arc is below or equal to zero and if the left hand value for the larger arc is above or equal to zero. It is an order of magnitude more difficult if the point is not a circle. I will have a look at the code for arc intersecting with another arc but I guess it will be rather more complicted. To do either one analytically looks like a 4th order equation must be solved. So I am looking for cheap iterative solutions, or approximations, instead. -- Andrew Poelstra Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net Web: http://www.wpsoftware.net/andrew/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
On Thu, Jul 14, 2011 at 03:48:24PM +0200, Igor Lopez wrote: I had a quick look at the routine and must say that I did not grasp the code. It is probably due to some heavy optimizations. Heavy optimizations, perhap, but also because it is wrong. If you have a full ellipse, then Width and Height are exactly what they sound like -- the full length from one side of the ellipse to the other. There is no way right now to rotate the ellipse, so alpha from the site you cited is always 0. However, an arc is only a SEGMENT of the ellipse. The segment starts at startAngle degrees and continuse for deltaAngle degrees counterclockwise. Your code assumes we have a full ellipse to intersect with. -- Andrew Poelstra Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net Web: http://www.wpsoftware.net/andrew/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
2011/7/15 Andrew Poelstra as...@sfu.ca: On Thu, Jul 14, 2011 at 03:48:24PM +0200, Igor Lopez wrote: I had a quick look at the routine and must say that I did not grasp the code. It is probably due to some heavy optimizations. Heavy optimizations, perhap, but also because it is wrong. If you have a full ellipse, then Width and Height are exactly what they sound like -- the full length from one side of the ellipse to the other. There is no way right now to rotate the ellipse, so alpha from the site you cited is always 0. However, an arc is only a SEGMENT of the ellipse. The segment starts at startAngle degrees and continuse for deltaAngle degrees counterclockwise. Your code assumes we have a full ellipse to intersect with. Ok now I understand. This means that the requirement for intersecting needs to be expanded to check that the angle from arc centerpoint to the point is within the arc segment as well. The end edges is a little bit tricky due to the rounded corner from the point radius but a simplification can be made by reducing the startAngle and increasing the deltaAngle as function of point radius and arc height, width. The equations must still hold independent if it is just a section of the ellipse. No need for an iterative or aproximate solution when point is a circle. It becomes very easy if the point has no extension, e.g radius = 0. In my equations I do have taken into account rotated arcs. -- Andrew Poelstra Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net Web: http://www.wpsoftware.net/andrew/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
Looking at pcb.pdf, page 64, section 8.8.1 Arc... Andrew Poelstra: ... If you have a full ellipse, then Width and Height are exactly what they sound like -- the full length from one side of the ellipse to the other. The file format specifies it as: Width Height The width and height, from the center to the edge. ... Are you saying that the parser etc. is doubling it? There is no way right now to rotate the ellipse, so alpha from the site you cited is always 0. ... And there is no way to specify a slanted ellipse in the file format either, so if we really want ellipses, the file format is incomplete and should be changed. Why not just give a warning if width and height is not equal, saying that we don't really support ellipses for the moment, and be done with it. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
On Thu, Jul 14, 2011 at 08:29:53PM +0200, Karl Hammar wrote: Looking at pcb.pdf, page 64, section 8.8.1 Arc... Andrew Poelstra: ... If you have a full ellipse, then Width and Height are exactly what they sound like -- the full length from one side of the ellipse to the other. The file format specifies it as: Width Height The width and height, from the center to the edge. ... Are you saying that the parser etc. is doubling it? Oh, my bad! I had checked manually what it did yesterday, and misremembered the behavior. You are right, Width and Height are the distance from the center to the edge. There is no way right now to rotate the ellipse, so alpha from the site you cited is always 0. ... And there is no way to specify a slanted ellipse in the file format either, so if we really want ellipses, the file format is incomplete and should be changed. Why not just give a warning if width and height is not equal, saying that we don't really support ellipses for the moment, and be done with it. I could, I suppose, but as you mentioned in another post, there are muddled physical units. As that is what I am trying to fix, I need to make changes anyway. It would be nice if we could at least support the featureset of our file format, while I'm at it. -- Andrew Poelstra Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net Web: http://www.wpsoftware.net/andrew/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
2011/7/14 Karl Hammar k...@aspodata.se: Looking at pcb.pdf, page 64, section 8.8.1 Arc... Andrew Poelstra: ... If you have a full ellipse, then Width and Height are exactly what they sound like -- the full length from one side of the ellipse to the other. The file format specifies it as: Width Height The width and height, from the center to the edge. ... Are you saying that the parser etc. is doubling it? There is no way right now to rotate the ellipse, so alpha from the site you cited is always 0. ... And there is no way to specify a slanted ellipse in the file format either, so if we really want ellipses, the file format is incomplete and should be changed. Why not just give a warning if width and height is not equal, saying that we don't really support ellipses for the moment, and be done with it. Sorry for the noise. According to the manual ( I just checked) Arc is just a quarter circle even though it is overspecified in terms of parameters. Ellipses are not mentioned. I just liked the challenge with rotated ellipses especially checking for intersection between them. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
According to the manual ( I just checked) Arc is just a quarter circle even though it is overspecified in terms of parameters. Ellipses are not mentioned. Technically, what we have is *not* an ellipse - it's a stretched arc. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
On Jul 14, 2011, at 12:00 PM, DJ Delorie wrote: Technically, what we have is *not* an ellipse - it's a stretched arc. ? The linear stretching transformation (x', y') = (a*x, b*y) applied to a circle yields an ellipse whose axes are parallel to the coordinate axes. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
The linear stretching transformation (x', y') = (a*x, b*y) applied to a circle yields an ellipse whose axes are parallel to the coordinate axes. Yes, *unless* you're including the start/end angles in that transformation, instead of applying them afterwards. http://www.delorie.com/pcb/tmp/stretched-arc.pcb This shows two 45-degree Arcs. One has width==height, the other does not. Note that the end angle on the stretched arc is 45, but the arc does not end at the 45 degree marker. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
Igor: 2011/7/14 Karl Hammar k...@aspodata.se: Looking at pcb.pdf, page 64, section 8.8.1 Arc... ... And there is no way to specify a slanted ellipse in the file format either, so if we really want ellipses, the file format is incomplete and should be changed. Why not just give a warning if width and height is not equal, saying that we don't really support ellipses for the moment, and be done with it. ... I just liked the challenge with rotated ellipses especially checking for intersection between them. Well, one could add a int slant = 0; // TODO: add support for rotated ellipses and start debugging. Or why not add full support for slantet/rotated ellipses. It would affect documentation (file format), gui, src/search.c and possible other places. In your code, you translate to ellipse center, why not rotate so the ellipse is with the foci on the x-axis, wouldn't that make the calc. easier? You already have the a/b ((semi-)width/height above) and the slant (or what should we call the ellipse rotation), so it is only the test point (X,Y) we are rotating, and the ellipse would then be in the normal form (simpler to visualize), one could also mirror the system so X and Y 0: x^2/a^2 + y^2/b^2 = 1, a = b 0 with foci at (0,c) and (0,-c) where c = sqrt(a^2 - b^2) One could possible use: . a normal to the ellipse bisects the rays from the foci . if P = (x,y) is on the perimeter, x 0, y 0 F = (0,c) a focus Q = (a/e, y), where e = c/a, y = the y of P then PF / PQ = e, PF = length P to F, dito. PQ /// And while we are at it, shouldn't we use a sane geometry where positive y's are up and zero angle is alinged with positive x-axis... Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
On Jul 14, 2011, at 1:09 PM, DJ Delorie wrote: The linear stretching transformation (x', y') = (a*x, b*y) applied to a circle yields an ellipse whose axes are parallel to the coordinate axes. Yes, *unless* you're including the start/end angles in that transformation, instead of applying them afterwards. http://www.delorie.com/pcb/tmp/stretched-arc.pcb This shows two 45-degree Arcs. One has width==height, the other does not. Note that the end angle on the stretched arc is 45, but the arc does not end at the 45 degree marker. Linear stretching doesn't generally preserve angles. Still, the result of stretching a circle is an ellipse. Indeed, the more general statement that stretching an ellipse *in any direction* yields an ellipse is true. Since stretching does not preserve angles, the operation of selecting an arc from an ellipse by angle does not commute with stretching. Thus, your example. This is closely related to math that confused the great genius Johannes Kepler for quite a while. We're still somewhat burdened by artifacts of his path to understanding: look up eccentric anomaly sometime. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
On 07/14/2011 11:23 PM, Andrew Poelstra wrote: On Thu, Jul 14, 2011 at 08:50:10AM +0200, Igor Lopez wrote: Check if point px,py is on rotaded elliptic arc: 1) Translate point to use ellipse center as origin, Px = px-x Py = py-y 2) Insert Px, Py in Eq1 lval equal 0 - point is exactly on arc lval above zero - point is inside arc lval below zero - point is outside arc The problem here is that the elliptical arc has nonzero thickness (usually, if it is a drawn solder arc). So I actually need to see if the point is /within a certain radius/ of the arc. For that I need the distance from the point to the arc, or to draw a circle around the point and check if that intersects the arc. To do either one analytically looks like a 4th order equation must be solved. So I am looking for cheap iterative solutions, or approximations, instead. If the point is within the arc's bounding box, transform the point's global coordinates into the arc's local (x: major axis, y: minor axis) coordinates. Then the distance calculation is a no-brainer. -Ethan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
Andrew Poelstra wrote: Arc[18 15 10 15 5 2000 90 90 clearline] will show the arc as a quarter-circle with GL enabled, even though it is actually taller than it is wide. confirm. PCB v20100929-2 as delivered by debian renders the stretched arc correctly. ---)kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 not happy with moderation of geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
On Wed, Jul 13, 2011 at 5:46 AM, Kai-Martin Knaak k...@familieknaak.de wrote: Andrew Poelstra wrote: Arc[18 15 10 15 5 2000 90 90 clearline] will show the arc as a quarter-circle with GL enabled, even though it is actually taller than it is wide. confirm. PCB v20100929-2 as delivered by debian renders the stretched arc correctly. Stretched arcs are a misfeature. Can they be deprecated? Otherwise, they are just another object that cannot be rotated at arbitrary angles. Regards, Mark markrages@gmail -- Mark Rages, Engineer Midwest Telecine LLC markra...@midwesttelecine.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
On Wed, Jul 13, 2011 at 10:02:28AM -0600, Mark Rages wrote: Stretched arcs are a misfeature. Can they be deprecated? Why are they a misfeature? Otherwise, they are just another object that cannot be rotated at arbitrary angles. That's a separate problem. -- Andrew Poelstra Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net Web: http://www.wpsoftware.net/andrew/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
On Wed, 13 Jul 2011 10:02:28 -0600 Mark Rages markra...@gmail.com wrote: Stretched arcs are a misfeature. Can they be deprecated? Otherwise, they are just another object that cannot be rotated at arbitrary angles. There is no inherent reason elliptical arcs cannot be rotated arbitrarily. Any restriction on such rotation is simply due to implementation faults in pcb. Regards, Colin ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb GL can't render stretched arcs
On Wed, Jul 13, 2011 at 01:01:34PM -0700, Colin D Bennett wrote: On Wed, 13 Jul 2011 10:02:28 -0600 Mark Rages markra...@gmail.com wrote: Stretched arcs are a misfeature. Can they be deprecated? Otherwise, they are just another object that cannot be rotated at arbitrary angles. There is no inherent reason elliptical arcs cannot be rotated arbitrarily. Any restriction on such rotation is simply due to implementation faults in pcb. The reason I bring this up is that the IsPointOnArc() in search.c assumes a circular arc right now. (Distance from elliptical arc segment is quite a tricky computational problem.) You can see this problem by drawing an stretched arc and trying to select and move it. Being a math major and all, you'd think I could fix this, but it eludes me... -- Andrew Poelstra Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net Web: http://www.wpsoftware.net/andrew/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB GL Memory leak
On Sat, 14 May 2011 10:59:57 +0100 Thomas Oldbury toldb...@gmail.com wrote: After using PCB+gl for more than an hour or so on a basic 4-layer board, it is using nearly 3.5 GB of memory, slowing the system to a crawl and forcing it to page a lot of data. Is anyone else experiencing this issue? Do you have this issue with PCB compiled with --disable-gl ? Levente -- Levente Kovacs http://levente.logonex.eu ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB GL Memory leak
I didn't have it from the last git, but I haven't compiled the PCB+gl branch without gl yet. On 14 May 2011 15:43, Levente Kovacs [1]leventel...@gmail.com wrote: On Sat, 14 May 2011 10:59:57 +0100 Thomas Oldbury [2]toldb...@gmail.com wrote: After using PCB+gl for more than an hour or so on a basic 4-layer board, it is using nearly 3.5 GB of memory, slowing the system to a crawl and forcing it to page a lot of data. Is anyone else experiencing this issue? Do you have this issue with PCB compiled with --disable-gl ? Levente -- Levente Kovacs [3]http://levente.logonex.eu ___ geda-user mailing list [4]geda-user@moria.seul.org [5]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:leventel...@gmail.com 2. mailto:toldb...@gmail.com 3. http://levente.logonex.eu/ 4. mailto:geda-user@moria.seul.org 5. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB GL Memory leak
On Sat, 2011-05-14 at 10:59 +0100, Thomas Oldbury wrote: After using PCB+gl for more than an hour or so on a basic 4-layer board, it is using nearly 3.5 GB of memory, slowing the system to a crawl and forcing it to page a lot of data. Is anyone else experiencing this issue? It is the PCB process which is swallowing the data? (Confirm with top, gnome-system-monitor or your favourite resource tracking utility). Check with xrestop how much X11 resources pcb is consuming. I've not seen this myself (at least not recently), but it is possible that I've not shut down a graphics context or something properly. It could also be a driver issue. What graphics card and driver do you use? (Can be determined quite accurately if you post output from glxinfo and a copy of your /var/log/Xorg.0.log) Regards, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB GL Memory leak
On Sat, 2011-05-14 at 23:53 +0100, Thomas Oldbury wrote: The pcb process under System Monitor shows usage. It seems to allocate it in large blocks of ~100MB at a time and never lets go of these. Are you working on a particularly complex board? I've tried git HEAD PCB and nothing jumps out at me in terms of memory leaks. I note your 2D xorg driver is a little old at 2.9.1, current is now 2.15.0 I recall there were some problems in the past with graphics resources not being freed correctly (might have been kernel related too), so if you are consistently seeing a leak with simple boards, upgrading your kernel and driver stack might well fix it. FWIW, when I last had this problem last, the system monitor applet (the one which draws little graphs in your gnome-panel), the memory usage was coloured as cache, rather than resident memory. The bug caused the system to start swapping when it ran out of memory, despite it thinking that the memory was cached data, and as such could have been dropped. If you have the performance monitoring applet (I forget the exact name), it would be worth tracking which colour the memory climb in PCB's usage is - either the colour for active memory usage, or cached pages. (I'm happy to try and reproduce leaks if you can give me good instructions to do so, ideally with an example board we can both use). HOWEVER: PCB keeps a lot of undo data. On a highly complex 8 layer board test-case I have, I can easily get to 300M resident just loading the board, with bumps of say 20Meg for every power plane deleted and recreated. Obviously this isn't ideal, but it could possibly explain where your memory usage is going. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb+gl minor polygons glitch
On Wed, 2011-05-11 at 22:39 +0100, Thomas Oldbury wrote: On my ThinkPad X201, I am encountering a minor issue with PCB+GL... Not a show stopper, but a bit annoying. I notice that when I move the cursor, occasionally a random triangle extending from the middle of the board to the outer edge will be highlighted. I'm using Ubuntu 10.10 and the GPU is an Intel of some sort, not sure exactly which one. There seems to be no definite pattern... is this a confirmed bug with PCB+GL or just a glitch with my laptop/software combination? It would be worth re-fetching again now, and checking if this still occurs with the latest fixes I've applied. It is just possible that the incorrect state I had set which resulted in missing crosshair attached objects caused a problem. Could you send me the contents of the output of the command: glxinfo and a copy of your /var/log/Xorg.0.log This is to identify exactly what graphics card and driver you are using. I have certainly heard (and seen) reports of a similar sounding artefact from one other Intel GPU based machine. I don't see it here on mine, but I'd love to get to the bottom of it. Since I can get physical access to the other laptop this was reported on, if you could send a video to confirm we're looking at the same kind of bug, I might be able to do some tracing and debug work here - perhaps enough to send the Intel driver developers a clueful bug report to get their driver fixed (assuming it is a driver issue). Best wishes, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb+gl
Thomas Oldbury wrote: I've heard a lot about this pcb+gl and I like it... and it turns out I fetched my git a few days from the enabling of it, so I think I missed the bus for it... The single, largest impact of of pcb+gl is transparency. IIRC, this is only showing with rat lines at the current state of patches in PCB-head. Maybe, you got the bus but did not notice ;-) ---)kaimartin(--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb+gl
Nope... rat lines are solid. I checked thisversion out around 2nd May. On 11 May 2011 17:27, Kai-Martin Knaak [1]kn...@iqo.uni-hannover.de wrote: Thomas Oldbury wrote: I've heard a lot about this pcb+gl and I like it... and it turns out I fetched my git a few days from the enabling of it, so I think I missed the bus for it... The single, largest impact of of pcb+gl is transparency. IIRC, this is only showing with rat lines at the current state of patches in PCB-head. Maybe, you got the bus but did not notice ;-) ---)kaimartin(--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover [2]http://www.iqo.uni-hannover.de GPG key: [3]http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list [4]geda-user@moria.seul.org [5]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:kn...@iqo.uni-hannover.de 2. http://www.iqo.uni-hannover.de/ 3. http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get 4. mailto:geda-user@moria.seul.org 5. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb+gl
On Wed, May 11, 2011 at 04:51:21PM +0100, Thomas Oldbury wrote: I've heard a lot about this pcb+gl and I like it... and it turns out I fetched my git a few days from the enabling of it, so I think I missed the bus for it... So, how do I enable it for the latest git? Is there a compile-time flag? Thanks, Tom You might need to rerun ./configure; GL is now the default so you need to give it --disable-gl to suppress it. If it complains that you need to install the opengl libraries you know that you've got it :) -- Andrew Poelstra Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net Web: http://www.wpsoftware.net/andrew/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb+gl
On Wed, 2011-05-11 at 16:51 +0100, Thomas Oldbury wrote: I've heard a lot about this pcb+gl and I like it... and it turns out I fetched my git a few days from the enabling of it, so I think I missed the bus for it... In git HEAD, there is some GL support. What I've always called pcb+gl is a feature branch I've been maintaining separately from the main PCB git repository. The aim is to merge it all to upstream git HEAD eventually!. To get the most speed and fancyness (including the more translucent thin-draw polygons), check out PCB from here: git clone git://repo.or.cz/geda-pcb/pcjc2.git git checkout -b pcb+gl_experimental origin/pcb+gl_experimental (If your card can cope with it, the pcb+gl_experimental branch has better rendering speed and a few extra bits and pieces). Otherwise, the default checkout should be the pcb+gl branch. As others have said, just run ./configure and GL should be enabled as the default. You might need to install your distro's libgtkglext-dev package before it will build. Best wishes, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb+gl
I'm getting this problem when trying to run the last command: thomas@thinkpadone:~/pcb2$ git checkout -b pcb+gl_experimental origin/pcb+gl_experimental fatal: Not a git repository (or any of the parent directories): .git Any ideas? On 11 May 2011 18:41, Peter Clifton [1]pc...@cam.ac.uk wrote: On Wed, 2011-05-11 at 16:51 +0100, Thomas Oldbury wrote: I've heard a lot about this pcb+gl and I like it... and it turns out I fetched my git a few days from the enabling of it, so I think I missed the bus for it... In git HEAD, there is some GL support. What I've always called pcb+gl is a feature branch I've been maintaining separately from the main PCB git repository. The aim is to merge it all to upstream git HEAD eventually!. To get the most speed and fancyness (including the more translucent thin-draw polygons), check out PCB from here: git clone git://[2]repo.or.cz/geda-pcb/pcjc2.git git checkout -b pcb+gl_experimental origin/pcb+gl_experimental (If your card can cope with it, the pcb+gl_experimental branch has better rendering speed and a few extra bits and pieces). Otherwise, the default checkout should be the pcb+gl branch. As others have said, just run ./configure and GL should be enabled as the default. You might need to install your distro's libgtkglext-dev package before it will build. Best wishes, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list [3]geda-user@moria.seul.org [4]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:pc...@cam.ac.uk 2. http://repo.or.cz/geda-pcb/pcjc2.git 3. mailto:geda-user@moria.seul.org 4. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb+gl
Did the clone succeed? Did you cd into the cloned repo? On Wed, May 11, 2011 at 12:53 PM, Thomas Oldbury [1]toldb...@gmail.com wrote: � I'm getting this problem when trying to run the last command: � thomas@thinkpadone:~/pcb2$ git checkout -b pcb+gl_experimental � origin/pcb+gl_experimental � fatal: Not a git repository (or any of the parent directories): .git � Any ideas? � On 11 May 2011 18:41, Peter Clifton [1][2]pc...@cam.ac.uk wrote: � On Wed, 2011-05-11 at 16:51 +0100, Thomas Oldbury wrote: � I've heard a lot about this pcb+gl and I like it... and it turns out � I � � � fetched my git a few days from the enabling of it, so I think I � missed � � � the bus for it... � � In git HEAD, there is some GL support. What I've always called � � pcb+gl is a feature branch I've been maintaining separately from � � the � � main PCB git repository. � � The aim is to merge it all to upstream git HEAD eventually!. � � To get the most speed and fancyness (including the more translucent � � thin-draw polygons), check out PCB from here: � � git clone git://[2][3]repo.or.cz/geda-pcb/pcjc2.git � � git checkout -b pcb+gl_experimental origin/pcb+gl_experimental � � (If your card can cope with it, the pcb+gl_experimental branch has � � better rendering speed and a few extra bits and pieces). � � Otherwise, the default checkout should be the pcb+gl branch. � � As others have said, just run ./configure and GL should be enabled � � as � � the default. You might need to install your distro's libgtkglext-dev � � package before it will build. � � Best wishes, � � -- � � Peter Clifton � � Electrical Engineering Division, � � Engineering Department, � � University of Cambridge, � � 9, JJ Thomson Avenue, � � Cambridge � � CB3 0FA � � Tel: +44 (0)7729 980173 - (No signal in the lab!) � � Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) � � ___ � � geda-user mailing list � � [3][4]geda-user@moria.seul.org � � [4][5]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References � 1. mailto:[6]pc...@cam.ac.uk � 2. [7]http://repo.or.cz/geda-pcb/pcjc2.git � 3. mailto:[8]geda-user@moria.seul.org � 4. [9]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list [10]geda-user@moria.seul.org [11]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:toldb...@gmail.com 2. mailto:pc...@cam.ac.uk 3. http://repo.or.cz/geda-pcb/pcjc2.git 4. mailto:geda-user@moria.seul.org 5. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user 6. mailto:pc...@cam.ac.uk 7. http://repo.or.cz/geda-pcb/pcjc2.git 8. mailto:geda-user@moria.seul.org 9. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user 10. mailto:geda-user@moria.seul.org 11. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb+gl
On Wed, 2011-05-11 at 20:53 +0100, Thomas Oldbury wrote: I'm getting this problem when trying to run the last command: thomas@thinkpadone:~/pcb2$ git checkout -b pcb+gl_experimental origin/pcb+gl_experimental fatal: Not a git repository (or any of the parent directories): .git Any ideas? Sorry (Russell is right), I forgot to tell you to cd pcjc2 or whatever directory the repository cloned into. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb+gl
Ah, problem solved... needed to cd into the directory. On 11 May 2011 21:31, Russell Dill [1]russ.d...@asu.edu wrote: Did the clone succeed? Did you cd into the cloned repo? On Wed, May 11, 2011 at 12:53 PM, Thomas Oldbury [1][2]toldb...@gmail.com wrote:  I'm getting this problem when trying to run the last command:  thomas@thinkpadone:~/pcb2$ git checkout -b pcb+gl_experimental  origin/pcb+gl_experimental  fatal: Not a git repository (or any of the parent directories): .git  Any ideas?  On 11 May 2011 18:41, Peter Clifton [1][2][3]pc...@cam.ac.uk wrote:  On Wed, 2011-05-11 at 16:51 +0100, Thomas Oldbury wrote:  I've heard a lot about this pcb+gl and I like it... and it turns out  I    fetched my git a few days from the enabling of it, so I think I  missed    the bus for it...   In git HEAD, there is some GL support. What I've always called   pcb+gl is a feature branch I've been maintaining separately from   the   main PCB git repository.   The aim is to merge it all to upstream git HEAD eventually!.   To get the most speed and fancyness (including the more translucent   thin-draw polygons), check out PCB from here:   git clone git://[2][3][4]repo.or.cz/geda-pcb/pcjc2.git   git checkout -b pcb+gl_experimental origin/pcb+gl_experimental   (If your card can cope with it, the pcb+gl_experimental branch has   better rendering speed and a few extra bits and pieces).   Otherwise, the default checkout should be the pcb+gl branch.   As others have said, just run ./configure and GL should be enabled   as   the default. You might need to install your distro's libgtkglext-dev   package before it will build.   Best wishes,   --   Peter Clifton   Electrical Engineering Division,   Engineering Department,   University of Cambridge,   9, JJ Thomson Avenue,   Cambridge   CB3 0FA   Tel: +44 (0)7729 980173 - (No signal in the lab!)   Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)   ___   geda-user mailing list   [3][4][5]geda-user@moria.seul.org   [4][5][6]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References  1. mailto:[6][7]pc...@cam.ac.uk  2. [7][8]http://repo.or.cz/geda-pcb/pcjc2.git  3. mailto:[8][9]geda-user@moria.seul.org  4. [9][10]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list [10][11]geda-user@moria.seul.org [11][12]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:[13]toldb...@gmail.com 2. mailto:[14]pc...@cam.ac.uk 3. [15]http://repo.or.cz/geda-pcb/pcjc2.git 4. mailto:[16]geda-user@moria.seul.org 5. [17]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user 6. mailto:[18]pc...@cam.ac.uk 7. [19]http://repo.or.cz/geda-pcb/pcjc2.git 8. mailto:[20]geda-user@moria.seul.org 9. [21]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user 10. mailto:[22]geda-user@moria.seul.org 11. [23]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list [24]geda-user@moria.seul.org [25]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:russ.d...@asu.edu 2. mailto:toldb...@gmail.com 3. mailto:pc...@cam.ac.uk 4. http://repo.or.cz/geda-pcb/pcjc2.git 5. mailto:geda-user@moria.seul.org 6. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user 7. mailto:pc...@cam.ac.uk 8. http://repo.or.cz/geda-pcb/pcjc2.git 9. mailto:geda-user@moria.seul.org 10. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user 11. mailto:geda-user@moria.seul.org 12. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user 13. mailto:toldb...@gmail.com 14. mailto:pc...@cam.ac.uk 15. http://repo.or.cz/geda-pcb/pcjc2.git 16. mailto:geda-user@moria.seul.org 17. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user 18. mailto:pc...@cam.ac.uk 19. http://repo.or.cz/geda-pcb/pcjc2.git 20. mailto:geda-user@moria.seul.org 21. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user 22. mailto:geda-user@moria.seul.org 23. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user 24. mailto:geda-user@moria.seul.org 25.
Re: gEDA-user: pcb+gl
It works. Thanks! :) On 11 May 2011 21:51, Thomas Oldbury [1]toldb...@gmail.com wrote: Ah, problem solved... needed to cd into the directory. On 11 May 2011 21:31, Russell Dill [2]russ.d...@asu.edu wrote: Did the clone succeed? Did you cd into the cloned repo? On Wed, May 11, 2011 at 12:53 PM, Thomas Oldbury [1][3]toldb...@gmail.com wrote:  I'm getting this problem when trying to run the last command:  thomas@thinkpadone:~/pcb2$ git checkout -b pcb+gl_experimental  origin/pcb+gl_experimental  fatal: Not a git repository (or any of the parent directories): .git  Any ideas?  On 11 May 2011 18:41, Peter Clifton [1][2][4]pc...@cam.ac.uk wrote:  On Wed, 2011-05-11 at 16:51 +0100, Thomas Oldbury wrote:  I've heard a lot about this pcb+gl and I like it... and it turns out  I    fetched my git a few days from the enabling of it, so I think I  missed    the bus for it...   In git HEAD, there is some GL support. What I've always called   pcb+gl is a feature branch I've been maintaining separately from   the   main PCB git repository.   The aim is to merge it all to upstream git HEAD eventually!.   To get the most speed and fancyness (including the more translucent   thin-draw polygons), check out PCB from here:   git clone git://[2][3][5]repo.or.cz/geda-pcb/pcjc2.git   git checkout -b pcb+gl_experimental origin/pcb+gl_experimental   (If your card can cope with it, the pcb+gl_experimental branch has   better rendering speed and a few extra bits and pieces).   Otherwise, the default checkout should be the pcb+gl branch.   As others have said, just run ./configure and GL should be enabled   as   the default. You might need to install your distro's libgtkglext-dev   package before it will build.   Best wishes,   --   Peter Clifton   Electrical Engineering Division,   Engineering Department,   University of Cambridge,   9, JJ Thomson Avenue,   Cambridge   CB3 0FA   Tel: +44 (0)7729 980173 - (No signal in the lab!)   Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)   ___   geda-user mailing list   [3][4][6]geda-user@moria.seul.org   [4][5][7]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References  1. mailto:[6][8]pc...@cam.ac.uk  2. [7][9]http://repo.or.cz/geda-pcb/pcjc2.git  3. mailto:[8][10]geda-user@moria.seul.org  4. [9][11]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list [10][12]geda-user@moria.seul.org [11][13]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:[14]toldb...@gmail.com 2. mailto:[15]pc...@cam.ac.uk 3. [16]http://repo.or.cz/geda-pcb/pcjc2.git 4. mailto:[17]geda-user@moria.seul.org 5. [18]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user 6. mailto:[19]pc...@cam.ac.uk 7. [20]http://repo.or.cz/geda-pcb/pcjc2.git 8. mailto:[21]geda-user@moria.seul.org 9. [22]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user 10. mailto:[23]geda-user@moria.seul.org 11. [24]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list [25]geda-user@moria.seul.org [26]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:toldb...@gmail.com 2. mailto:russ.d...@asu.edu 3. mailto:toldb...@gmail.com 4. mailto:pc...@cam.ac.uk 5. http://repo.or.cz/geda-pcb/pcjc2.git 6. mailto:geda-user@moria.seul.org 7. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user 8. mailto:pc...@cam.ac.uk 9. http://repo.or.cz/geda-pcb/pcjc2.git 10. mailto:geda-user@moria.seul.org 11. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user 12. mailto:geda-user@moria.seul.org 13. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user 14. mailto:toldb...@gmail.com 15. mailto:pc...@cam.ac.uk 16. http://repo.or.cz/geda-pcb/pcjc2.git 17. mailto:geda-user@moria.seul.org 18. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user 19. mailto:pc...@cam.ac.uk 20. http://repo.or.cz/geda-pcb/pcjc2.git 21. mailto:geda-user@moria.seul.org 22. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user 23. mailto:geda-user@moria.seul.org 24. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user 25. mailto:geda-user@moria.seul.org 26. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___
Re: gEDA-user: pcb+gl minor polygons glitch
Thomas Oldbury wrote: is this a confirmed bug with PCB+GL or just a glitch with my laptop/software combination? I haven't seen this on my desktops, yet. They have ATI cards plugged in, driven by radeon and fglrx. From a hardware point of view they are pretty far from your set-up. ---)kaimartin(--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb+gl minor polygons glitch
On Wed, 2011-05-11 at 22:39 +0100, Thomas Oldbury wrote: On my ThinkPad X201, I am encountering a minor issue with PCB+GL... Not a show stopper, but a bit annoying. I notice that when I move the cursor, occasionally a random triangle extending from the middle of the board to the outer edge will be highlighted. I'm using Ubuntu 10.10 and the GPU is an Intel of some sort, not sure exactly which one. There seems to be no definite pattern... is this a confirmed bug with PCB+GL or just a glitch with my laptop/software combination? It might be a driver issue. I use Intel GM45 hardware myself, have confirmed excellent performance on a couple of GeForce cards, but have also heard reports of visual artaefacts on some Intel machines - possibly due to driver problems. If you have a digital camera which can record video, can you send a short clip of the problem occuring to me? (I presume it may be difficult to screen-shot, but give that a try too). -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL - now with background image rendering support!
On Tue, May 03, 2011 at 10:37:01PM +0100, Peter Clifton wrote: On Tue, 2011-05-03 at 19:46 +0200, Kai-Martin Knaak wrote: Peter Clifton wrote: I'm very close to being able to push the basic 2D portions of PCB+GL into git HEAD. I feel like a supporter at the course of a marathon race: Go, Peter. Go! Ok, spurred on by that encouragement, I've tidied up and pushed the first couple of PCB+GL patches to git HEAD. git HEAD PCB will now render using OpenGL by default with a GTK HID build. If that doesn't work for you, build with ./configure --disable-gl Great. Anyway the current gtk drawing code would have failed with gtk3, but it seems that even the GL code will run into trouble: - GdkDrawable and GdkPixmap have been eliminated, you have to use Cairo whether you like it or not - expose-event has disappeared, it is now called draw, and it has differen parameters - I hope that gtkglext will still work, but what do I know? Ok, I'm an archaic lesstif user. Regards, Gabriel ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL - now with background image rendering support!
On Wed, 2011-05-04 at 09:21 +0200, Gabriel Paubert wrote: Great. Anyway the current gtk drawing code would have failed with gtk3, but it seems that even the GL code will run into trouble: - GdkDrawable and GdkPixmap have been eliminated, you have to use Cairo whether you like it or not - expose-event has disappeared, it is now called draw, and it has differen parameters - I hope that gtkglext will still work, but what do I know? Unknown.. but I expect it will be ported eventually. GTK 3.0 will be a problem for both the gEDA and PCB code bases, but given our adoption rate of new versions of things.. I don't expect it will be a pressing concern for some years yet. We'll have to have caught up by the time distros stop shipping support for GTK2.0 though. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL - now with background image rendering support!
On Wed, May 04, 2011 at 12:14:16PM +0100, Peter Clifton wrote: On Wed, 2011-05-04 at 09:21 +0200, Gabriel Paubert wrote: Great. Anyway the current gtk drawing code would have failed with gtk3, but it seems that even the GL code will run into trouble: - GdkDrawable and GdkPixmap have been eliminated, you have to use Cairo whether you like it or not - expose-event has disappeared, it is now called draw, and it has differen parameters - I hope that gtkglext will still work, but what do I know? Unknown.. but I expect it will be ported eventually. GTK 3.0 will be a problem for both the gEDA and PCB code bases, but given our adoption rate of new versions of things.. I don't expect it will be a pressing concern for some years yet. We'll have to have caught up by the time distros stop shipping support for GTK2.0 though. I have no doubt that distros will ship gtk2.0 for a long time, at least Debian only dropped gtk1.2 with Lenny, a few months ago. Regards, Gabriel ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL - now with background image rendering support!
Peter Clifton wrote: I'm very close to being able to push the basic 2D portions of PCB+GL into git HEAD. I feel like a supporter at the course of a marathon race: Go, Peter. Go! ---)kaimartin(--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL - now with background image rendering support!
On Tue, 2011-05-03 at 19:46 +0200, Kai-Martin Knaak wrote: Peter Clifton wrote: I'm very close to being able to push the basic 2D portions of PCB+GL into git HEAD. I feel like a supporter at the course of a marathon race: Go, Peter. Go! Ok, spurred on by that encouragement, I've tidied up and pushed the first couple of PCB+GL patches to git HEAD. git HEAD PCB will now render using OpenGL by default with a GTK HID build. If that doesn't work for you, build with ./configure --disable-gl -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL - now with background image rendering support!
On Wed, May 4, 2011 at 7:37 AM, Peter Clifton pc...@cam.ac.uk wrote: On Tue, 2011-05-03 at 19:46 +0200, Kai-Martin Knaak wrote: Peter Clifton wrote: I'm very close to being able to push the basic 2D portions of PCB+GL into git HEAD. I feel like a supporter at the course of a marathon race: Go, Peter. Go! Ok, spurred on by that encouragement, I've tidied up and pushed the first couple of PCB+GL patches to git HEAD. git HEAD PCB will now render using OpenGL by default with a GTK HID Excellent, opening the champagne now! ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL - now with background image rendering support!
OpenGL and schematic import all in one place, this is going to be great! Thank you. My homepage. [1]http://sites.google.com/site/matthewsager/home References 1. http://sites.google.com/site/matthewsager/home ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL - now with background image rendering support!
On Wed, 2011-05-04 at 08:09 +1000, Stephen Ecob wrote: On Wed, May 4, 2011 at 7:37 AM, Peter Clifton pc...@cam.ac.uk wrote: On Tue, 2011-05-03 at 19:46 +0200, Kai-Martin Knaak wrote: Peter Clifton wrote: I'm very close to being able to push the basic 2D portions of PCB+GL into git HEAD. I feel like a supporter at the course of a marathon race: Go, Peter. Go! Ok, spurred on by that encouragement, I've tidied up and pushed the first couple of PCB+GL patches to git HEAD. git HEAD PCB will now render using OpenGL by default with a GTK HID Excellent, opening the champagne now! Its not all there yet.. none of the transparency or 3D, and not yet all of the various speed-ups in the branch. It is certainly a start though! -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL instructions
On Feb 21 2011, Kai-Martin Knaak wrote: Ethan Swint wrote: I was expecting just to get back git clone -o pcjc2 git://repo.or.cz/geda-pcb/pcjc2.git or some such, but in response Peter has posted what looks to be an excellent guide to his blog at http://pcjc2.blogspot.com/2011/02/pcbgl-repository-instructions.html Is it just me, or is anyone else also having a speed issue with Peters blog? Scrolling takes about two seconds to jump by a screen... (My browser is epiphany, the default with debian) Sarah helped me pick the background image when I was trying to encourage her to set up a blog of her own. I might have to change it back, as it causes performance issues in older Epiphany versions. Firefox doesn't have any issues with it, but I prefer Epiphany myself, so may change it. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL instructions
On Feb 21 2011, Ethan Swint wrote: Fairly slow scrolling on Firefox 3.6.13 on Fedora, but it seems faster in the sections without images. I looked at a few of the images and they all seem to be 150kB, even though they are pretty small pixel-wise. Much slower scrolling than other web sites. I think its the background which kills it, but I'll admit to having not done a great deal of optimising of the images I uploaded. I pulled them straight into blogger from my camera (or screen-captures), so they can end up fairly slow. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL instructions
Ethan Swint wrote: I was expecting just to get back git clone -o pcjc2 git://repo.or.cz/geda-pcb/pcjc2.git or some such, but in response Peter has posted what looks to be an excellent guide to his blog at http://pcjc2.blogspot.com/2011/02/pcbgl-repository-instructions.html Is it just me, or is anyone else also having a speed issue with Peters blog? Scrolling takes about two seconds to jump by a screen... (My browser is epiphany, the default with debian) ---)kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL instructions
On 02/20/2011 09:32 PM, Kai-Martin Knaak wrote: Ethan Swint wrote: I was expecting just to get back git clone -o pcjc2 git://repo.or.cz/geda-pcb/pcjc2.git or some such, but in response Peter has posted what looks to be an excellent guide to his blog at http://pcjc2.blogspot.com/2011/02/pcbgl-repository-instructions.html Is it just me, or is anyone else also having a speed issue with Peters blog? Scrolling takes about two seconds to jump by a screen... (My browser is epiphany, the default with debian) ---)kaimartin(--- Fairly slow scrolling on Firefox 3.6.13 on Fedora, but it seems faster in the sections without images. I looked at a few of the images and they all seem to be 150kB, even though they are pretty small pixel-wise. Much slower scrolling than other web sites. -Ethan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL instructions
On Mon, 2011-02-21 at 03:32 +0100, Kai-Martin Knaak wrote: Ethan Swint wrote: I was expecting just to get back git clone -o pcjc2 git://repo.or.cz/geda-pcb/pcjc2.git or some such, but in response Peter has posted what looks to be an excellent guide to his blog at http://pcjc2.blogspot.com/2011/02/pcbgl-repository-instructions.html Is it just me, or is anyone else also having a speed issue with Peters blog? Scrolling takes about two seconds to jump by a screen... (My browser is epiphany, the default with debian) I can confirm with firefox(gecko) 3.6.12 and midori(webkit). I think it's something related to the background. Full CPU usage for the wait time. Best Regards, Felipe. -- Felipe De la Puente Christen MSN/GTalk : fdelapue...@gmail.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL instructions
Safari and Firefox, on OS X is quite fast, nice smooth scrolling. Steve On Sun, Feb 20, 2011 at 6:59 PM, Felipe De la Puente Christen fdelapue...@gmail.com wrote: On Mon, 2011-02-21 at 03:32 +0100, Kai-Martin Knaak wrote: Ethan Swint wrote: I was expecting just to get back git clone -o pcjc2 git://repo.or.cz/geda-pcb/pcjc2.git or some such, but in response Peter has posted what looks to be an excellent guide to his blog at http://pcjc2.blogspot.com/2011/02/pcbgl-repository-instructions.html Is it just me, or is anyone else also having a speed issue with Peters blog? Scrolling takes about two seconds to jump by a screen... (My browser is epiphany, the default with debian) I can confirm with firefox(gecko) 3.6.12 and midori(webkit). I think it's something related to the background. Full CPU usage for the wait time. Best Regards, Felipe. -- Felipe De la Puente Christen MSN/GTalk : fdelapue...@gmail.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL - Stable (eventually...)
On Fri, 2010-11-26 at 13:00 +, Peter Clifton wrote: On Fri, 2010-11-26 at 12:13 +0100, Kai-Martin Knaak wrote: Peter Clifton wrote: Ok. I recloned(*) compiled and benchmarked my pidpeltier layout with full polygons and with poly_thin_draw. Hardware is my day job desktop, nvidia quadro, closed source driver. current HEAD: full poly: 15 FPS thin draw: 25 FPS version 20091103 as it is distributed in debian/squeeze full poly: 31 FPS thin draw: 25 FPS Yes, the 20091103 version is faster with full polygons. Did you have any further insight on this slowdown issue? I've been off email for a little while (quota full, disastrous HDD + OS upgrade - during which (amongst other problems!), I blew up one HDD caddy and my laptop's optical drive gave up - permanently after I tried to manually tweak the laser powers!) You'll probably know how nasty CD drive laser power adjustments are, and that it was a desperate thing to try. I think I tweaked them more than I imagined, and have now lost the ability to get back to where I started.. The drive does different things depending on how I set the power, but I've not got it working again! Still, at £20 for a Sony / Optiarc replacement, it wasn't such a disaster, just a setback. Why I buy Sony though, I don't know (other than the original OEM drive was Optiarc), as I generally detest Sony hardware. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL - Stable (eventually...)
Peter Clifton wrote: So.. please fetch git HEAD PCB and play with things. Ok. I recloned(*) compiled and benchmarked my pidpeltier layout with full polygons and with poly_thin_draw. Hardware is my day job desktop, nvidia quadro, closed source driver. current HEAD: full poly: 15 FPS thin draw: 25 FPS version 20091103 as it is distributed in debian/squeeze full poly: 31 FPS thin draw: 25 FPS Yes, the 20091103 version is faster with full polygons. Also tried the same set of benchmark tests with other layouts. Thin draw poly is always at a comparable speed. Full poly mode is faster with the 2009 gtk version. For current pcb HEAD full polygon mode is significantly slower. For some boards only half the FPS. Others achieve 2/3 the frames of thin draw. ---)kaimartin(---(needs to do some real solderiung now...) (*): Still not comfortable with the git commands. How do I make absolutely sure to have the correct branch activated? -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL - Stable (eventually...)
Peter Clifton wrote: I wonder if I'm holding onto a resource of which the card only has a limited supply. Did this happen with the before_pours branch, or just the local_customisation_no_pours one? With before_pours. Something changed over night: Now I can run two instances of pcb-GL just fine. But if I load a third one, everything gets really sluggish. This happens with both before_pours and with no_pours. This was reproducible. Maybe, yesterday some graphics card resources were in use elsewhere. ---)kaimartin(--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL - Stable (eventually...)
On Fri, 2010-11-26 at 01:56 +0100, kai-martin knaak wrote: I tried multiple glxgears with closed source nvidia driver on my day job desktop and with the free radeon on my private desktop. Result: The FPS are roughly proportional to 1/n with n beeing the the number of instances. Looks like glxgears instances symmetrically share available resources. With pcb-GL I loose two orders of magnitude for two instances. You are right, with nvidia-drivers-260.19.21 and kernel 2.6.36 I get now about 1070 fps for one instance fullscreen, and for two instances, each occupying half of the screen, 500 fps each. But with two instances still only one of my two cores are working. This is for an 5 years old nvidia card. I think some years ago with older drivers the result for multiple instances was much worse, but I can not check to be sure, sorry. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL - Stable (eventually...)
On Fri, 2010-11-26 at 12:13 +0100, Kai-Martin Knaak wrote: Peter Clifton wrote: Ok. I recloned(*) compiled and benchmarked my pidpeltier layout with full polygons and with poly_thin_draw. Hardware is my day job desktop, nvidia quadro, closed source driver. current HEAD: full poly: 15 FPS thin draw: 25 FPS version 20091103 as it is distributed in debian/squeeze full poly: 31 FPS thin draw: 25 FPS Yes, the 20091103 version is faster with full polygons. I'd been developing polygon_speedup with the PCB+GL hid in mind, and that does not use the polgon dicer. (It uses a much faster algorithm to split the polygons up for rendering - although one perhaps not as suited for gerber output). I'm a little surprised that the frame-rate during benchmarking is affected though, as there ought to be a NoHoles cache. Try this. git fetch git checkout -b test_before_polygon_speedup 323a0c52f7dfdaae51fd7ead87373b3dac90be14 (And build that to compare). This should test whether it is my last committed changes polygon_speedup which slowed things down. If it was.. I'll have to take a look. When I built git HEAD PCB before I merged that code, I did notice how glacially slow the rendering was. It is just possible that some other changes since the 20091103 version have caused a performance regression. Not that I'm shouting too loudly, as it might well have been me which caused them ;) There have been 259 commits since 20091103 to today's git HEAD. Lots of regression potential. Might be any of these?: commit 7dc2d854f3e58680577b2bb71cd68b2b769e3025 Author: Peter Clifton pc...@cam.ac.uk Date: Thu Nov 12 23:54:07 2009 + hid/common: Clip no-holes polygon pieces before calling fill_contour This avoids integer overflow in some HIDs (GTK, Lesstif?) when drawing at high zoom level. Such overflow would lead to incorrectly drawn polygons. It is possible that a similar bug could effect thin-drawn polygons, but that has not manifested its-self so far. If we were to clip these in the future, we need to be careful to extend the clip region slightly off-screen, so the outlines are not drawn. Ideally we would clip these vertices using a Sutherland-Hodgman clipping algorithm, then we could simply discard edges which are clipped completely. commit ede7157be717b4cd22e1e51b6045a2ea5f28de26 Author: Peter Clifton pc...@cam.ac.uk Date: Fri Nov 13 01:14:08 2009 + hid/common: Control update of NoHoles cache based on clip region If at least 50% of the bounding box of a polygon is within the clip region, compute the whole NoHoles polygon and cache it for later rendering. If less of the polygon is within the clip region, just compute what we need to draw the piece we've been asked for. commit bbe5aa52e540171a08f905e38468623a0d3f2e1c Author: Peter Clifton pc...@cam.ac.uk Date: Mon May 10 17:40:15 2010 +0100 Fix poly_ContourInContour() test not to return TRUE for touching contours ... (This fix is required for correctness) commit 3d0a8bd1dae0816d364a774bf9b958faf2983ec7 Author: Peter Clifton pc...@cam.ac.uk Date: Tue May 11 15:55:37 2010 +0100 Speed up poly_ContourInContour() test by computing interior point ... (Attempt to mitigate performance impact of previous patch) commit af2f50d4fb838de13dfbb5243e2114c66fefba7b Author: Peter Clifton pc...@cam.ac.uk Date: Wed Jun 2 21:09:51 2010 +0100 Fix node_label() function to work with self-intersection (*): Still not comfortable with the git commands. How do I make absolutely sure to have the correct branch activated? If you do git log, you can confirm with me the git SHA1 of the commit you built from. gitk will show you the commit history graphically, if that helps. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL - Stable (eventually...)
On Fri, 2010-11-26 at 12:13 +0100, Kai-Martin Knaak wrote: Peter Clifton wrote: So.. please fetch git HEAD PCB and play with things. current HEAD: full poly: 15 FPS thin draw: 25 FPS version 20091103 as it is distributed in debian/squeeze full poly: 31 FPS thin draw: 25 FPS Yes, the 20091103 version is faster with full polygons. My favourite demo.pcb, has git HEAD @ 2.9fps, with 20091103 also @ 2.9fps. No change. I'll try yours... pidpeltier.pcb, has git HEAD @ 4.9, 5.5, 5.2 fps with 20091103 also @ 5.0, 5.4, 5.4 fps. I wonder if there is something different about the debian packages? Can you try building from the release tag in git? git checkout pcb-20091103-RELEASE (After your done, switch back to whatever branch you want: git branch (lists branches) git checkout branch_name Alternatively, let me know how you were testing. For consistency, I maximised to full screen and re-adjusted the view with the v key to fit the whole board on the screen. This is cheating slightly I guess, as it guarantees the NoHoles polygons for the whole board will be cached (in later versions), so benchmark will just be testing the rendering routines, and not really polygon computation. Best regards, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL Testers (please test)
kai-martin knaak wrote: I set up a git repository of pidpeltier and made it available via gitweb: http://bibo.iqo.uni-hannover.de/gitweb/?p=PIDpeltier.git;a=tree No cloning yet, because I forgot to set the export-option of the git-daemon. But access via http with the link above should work. The layout of Phasendetektor-Atlas has a similar size, but with four copper layers: http://bibo.iqo.uni-hannover.de/gitweb/?p=Phasendetektor-Atlas.git;a=tree cloning should work now: git clone git://bibo.iqo.uni-hannover.de/git/PIDpeltier and git clone git://bibo.iqo.uni-hannover.de/git/Phasendetektor-Atlas ---)kaimartin(--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL - Stable (eventually...)
Stefan Salewski wrote: If I start PCB-GL twice, both of them get very slow. benchmark() returns 0.2 FPS. I have seen that behavior for glxgears with closed source nvidia driver too. For one instance processor load was only 50% for dual core AMD64, so my first guess was getting good speed for two instances. But result was very slow if started twice. I tried multiple glxgears with closed source nvidia driver on my day job desktop and with the free radeon on my private desktop. Result: The FPS are roughly proportional to 1/n with n beeing the the number of instances. Looks like glxgears instances symmetrically share available resources. With pcb-GL I loose two orders of magnitude for two instances. ---)kaimartin(--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL - Stable (eventually...)
Kai-Martin Knaak wrote: On my fairly recent desktops(*) your openGL branch is consistently faster than HEAD. One exception: If I start PCB-GL twice, both of them get very slow. benchmark() returns 0.2 FPS. Shut down of one of the instances immediately rectifies the situation. Note: This is on my day-job desktop with nvidia quadro card, driven by closed source nvidia driver. I just tried at home with ATI HD4670 driven by radeon. With this set-up two pcb-GL instances do not seem to affect each other much. They don't care about glxgears either. ---)kaimartin(--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL - Stable (eventually...)
On Fri, 2010-11-26 at 01:56 +0100, kai-martin knaak wrote: With pcb-GL I loose two orders of magnitude for two instances. I wonder if I'm holding onto a resource of which the card only has a limited supply. Did this happen with the before_pours branch, or just the local_customisation_no_pours one? -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL - Stable (eventually...)
On Tue, 2010-11-23 at 23:37 +, Peter Clifton wrote: Hi geda-users, Kai-Martin, Since I know some people have expressed an interest in why PCB+GL hasn't hit stable yet, I realised earlier that there was another step which is necessary... (besides cleaning up the hacks I made on top of the code I took from cairo). The polygon_speedup branch on which the GL code sits might seem unrelated, but in fact there are changes in that branch which are relied upon when rendering polygons. The polygon_speedup branch should mostly be a success, but I'm fairly sure it does increase CPU cycles for some operations. I've not had a chance to test it very scientifically, and I'm hesitant to push it to git HEAD without having at least made a few checks to see that it isn't penalising too many general cases. Ok, so I've not done any significant benchmarking, but I've read through the commits, attempted to convince myself I've not left any stupid debug code, and written a few more detailed commit messages for the series. There are a couple of commits I'm not as happy with left in my own branch, but I've pushed the ones which are most solid. I did have to almost completely re-write one commit, as I had lazily used some rather convenient glib APIs in the core. I was very tempted just to make configure.ac check for glib unconditionally and push! So.. please fetch git HEAD PCB and play with things. It ought to be a lot faster for boards with really complex polygons. For really simple things it may have a slight impact due to extra processing overhead. Please let me know if you find any cases with noticeable speed (OR ANY BEHAVIOURAL) regressions. Obviously no speed regressions are desirable, but as usual there are trade-offs involved. Gerber export might be slower in some complex cases, for example. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL - Stable (eventually...)
Peter Clifton wrote: The polygon_speedup branch should mostly be a success, but I'm fairly sure it does increase CPU cycles for some operations. I've not had a chance to test it very scientifically, and I'm hesitant to push it to git HEAD without having at least made a few checks to see that it isn't penalising too many general cases. Is there anything us testers can check or test? If necessary I could re-write the polygon rendering routines to NOT rely on the fact the polygon_speedup branch creates a spatial datastructure of all the contours within a polygon. If it is just about polygons, I'd say Go ahead and push!. On my fairly recent desktops(*) your openGL branch is consistently faster than HEAD. On machines with less CPU and graphics muscles I would disable polygons during manual routing, anyway. So slightly increasing the CPU load for polygons won't affect the work-flow in an environment with weak hardware too much. On the other hand, the huge usability improvement due to transparent tracks helps in such an environment, too. By the way: Do you you intend to keep the very nice see-thru feature in thin-draw-poly mode? If so, there should be an additional menu item to explicitly disable any polygon calculation. I used to work-around the lack of such a menu item by moving the polygons to dedicated layers and put the layers in special layer groups. This is really a crutch which should not be necessary. ---)kaimartin(--- (*) one of them is three and a half years old, now. The other received an update to double core AMD a few weeks ago. -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL - Stable (eventually...)
Kai-Martin Knaak wrote: On my fairly recent desktops(*) your openGL branch is consistently faster than HEAD. One exception: If I start PCB-GL twice, both of them get very slow. benchmark() returns 0.2 FPS. Shut down of one of the instances immediately rectifies the situation. Maybe some kind of race condition? ---)kaimartin(--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL - Stable (eventually...)
On Wed, 2010-11-24 at 22:05 +0100, Kai-Martin Knaak wrote: Peter Clifton wrote: The polygon_speedup branch should mostly be a success, but I'm fairly sure it does increase CPU cycles for some operations. I've not had a chance to test it very scientifically, and I'm hesitant to push it to git HEAD without having at least made a few checks to see that it isn't penalising too many general cases. Is there anything us testers can check or test? Any bugs present in the codebase which are not in git HEAD would be interesting to know about. [snip] By the way: Do you you intend to keep the very nice see-thru feature in thin-draw-poly mode? Definitely - although possibly with a toggle. I wanted to make much more of the rendering customisable eventually, but didn't get to it yet. If so, there should be an additional menu item to explicitly disable any polygon calculation. I used to work-around the lack of such a menu item by moving the polygons to dedicated layers and put the layers in special layer groups. This is really a crutch which should not be necessary. It isn't a completely easy thing to do, but possible. It would probably be necessary for pours support on big boards, as some of the computations there are more expensive than on normal polygons. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL - Stable (eventually...)
On Wed, 2010-11-24 at 22:59 +0100, Kai-Martin Knaak wrote: Kai-Martin Knaak wrote: On my fairly recent desktops(*) your openGL branch is consistently faster than HEAD. One exception: If I start PCB-GL twice, both of them get very slow. benchmark() returns 0.2 FPS. Shut down of one of the instances immediately rectifies the situation. Maybe some kind of race condition? Does PCB slow down if you run a second GL client, such as glxgears? (Either first / second?) It may be that your GL drivers don't like sharing the hardware between multiple clients. DRI2 support is really what is needed IIRC, and that is not _all_ that old. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL - Stable (eventually...)
On Wed, 2010-11-24 at 22:59 +0100, Kai-Martin Knaak wrote: Kai-Martin Knaak wrote: On my fairly recent desktops(*) your openGL branch is consistently faster than HEAD. One exception: If I start PCB-GL twice, both of them get very slow. benchmark() returns 0.2 FPS. Shut down of one of the instances immediately rectifies the situation. Maybe some kind of race condition? I have seen that behavior for glxgears with closed source nvidia driver too. For one instance processor load was only 50% for dual core AMD64, so my first guess was getting good speed for two instances. But result was very slow if started twice. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL Testers (please test)
Hi Peter. Bad news from the local_customisation_no_pours branch: I switched to the open source radeon driver rather than the closed fglrx for my ATI HD4670 card. With this driver X freezes on start-up of the no_pours version of pcb. The screen does not change anymore except for a slowly updated mouse cursor. Since there is no keyboard input, I could not enter a text console and had to do a reboot with the power switch. I tried a fresh clone/compile/install but results are the same. Since most likely everything except for X is still working, I might be able to log in via ssh and peek around (Have to move hardware in place, first). Is there anything I might look for, so you get a chance to know what happened? ---)kaimartin(--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL Testers (please test)
On Thu, 2010-11-25 at 04:05 +0100, kai-martin knaak wrote: Hi Peter. Bad news from the local_customisation_no_pours branch: I switched to the open source radeon driver rather than the closed fglrx for my ATI HD4670 card. With this driver X freezes on start-up of the no_pours version of pcb. The screen does not change anymore except for a slowly updated mouse cursor. Since there is no keyboard input, I could not enter a text console and had to do a reboot with the power switch. I tried a fresh clone/compile/install but results are the same. Since most likely everything except for X is still working, I might be able to log in via ssh and peek around (Have to move hardware in place, first). Is there anything I might look for, so you get a chance to know what happened? Any errors at the bottom of dmesg Any errors at the bottom of /var/log/Xorg.0.log (.old) if restarted if you're running remotely, you can sudo gdb /usr/bin/X `pidof X` and grab a backtrace with bt, although its been a while since I did that myself, so I'm not quite sure if I described the process of attaching right. It might actually suffice to do: sudo gdb --pid `pidof X` Then bt, ENTER. Do it a few times.. does the trace location change, or stay the same? There may also be ways and means to debug by passing options to the GL driver, but I don't know any specifics for Radeon. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL resistor p0rn
Hi, I compiled the latest version of FreeCAD and OpenCASCADE on my machine (with NVidia 8600 195.36.15, Debian 5.0.6). The compile worked reasonable and FreeCAD starts, but when I try to model something, e.g. cut a sphere out of a cube or chamfer and fillet the cube the screen-output is rubbish. Otherwise your general path appears reasonable to me. As it's only free as in beer, I don't fully suggest it, but gCAD3D seems to produce stable results - How about forging the script in a way to have the 3D-CAD program select the model it likes and really emit only XYRS, the footprint and ev. provide a table that correlates the footprint with a (choice of) 3D-model(s)? BTW. gCAD3D can read/write IGES, STEP and it's own documented ascii-format. Matthew Wilkins wrote: If it was me, I think I'd make a script for some 3D modelling package like FreeCAD to generate a 3D model using PCB's XY place file output. The process would be: 1. make FreeCAD 3D models for each of the components 2. generate an XY place file, board outline file and drill file in PCB 3. run a python script in FreeCAD that generates a model of the board based on the outline gerber file. Make holes using data from the drill file. 4. Run a script that makes an assembly by placing components based on the XY place file. At this point you should have a 3D model of the board, right in a 3D CAD program that can be used to model enclosures and other parts. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL resistor p0rn
Matthew Wilkins wrote: 1. make FreeCAD 3D models for each of the components 2. generate an XY place file, board outline file and drill file in PCB 3. run a python script in FreeCAD that generates a model of the board based on the outline gerber file. Make holes using data from the drill file. 4. Run a script that makes an assembly by placing components based on the XY place file. This is exactly, what I had in mind, when I opened the subject A different approach to 3D modeling :-) At this point you should have a 3D model of the board, right in a 3D CAD program that can be used to model enclosures and other parts. And a path to create high quality rendered images or even animations with blender. Imagine a low-level flight through your populated board... ---)kaimartin(--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL resistor p0rn
On 11/19/10 12:21 PM, Peter Clifton wrote: http://www2.eng.cam.ac.uk/~pcjc2/geda/pcb+gl_3d/pcb+gl_3d_packages_mockup3.png http://www2.eng.cam.ac.uk/~pcjc2/geda/pcb+gl_3d/pcb+gl_3d_packages_mockup4.png Perhaps pixel shaders and bump mapping is a little overkill for a few resistors, but it has kept me amused for a while. I'm working on a VRML importer at the moment, as this will give us access to models people have created for KiCad. (And hopefully the converse too, when PCB+GL+3D lands and users start creating models). WOW that is gorgeous! -Dave -- Dave McGuire Port Charlotte, FL ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL resistor p0rn
On 11/21/2010 11:49 AM, Dave McGuire wrote: Perhaps pixel shaders and bump mapping is a little overkill for a few resistors, but it has kept me amused for a while. Looks fab! Will actually be useful. Why not have processors churn for us? Overkill? There are so many ways to kill the problem of not-fully-designed circuits...and enclosures... How could one have overkill? The more ammo the better! Thanks, John ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL resistor p0rn
John Griessen wrote: How could one have overkill? Inefficient use of developer cycles. Traditionally, the most valuable resource open source projects. ---)kaimartin(--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL resistor p0rn
On Sun, 2010-11-21 at 22:45 +0100, kai-martin knaak wrote: John Griessen wrote: How could one have overkill? Inefficient use of developer cycles. Traditionally, the most valuable resource open source projects. Developers having fun are happy developers, and might even find time for some more boring work. I've almost been tempted to set myself the goal of merging the PCB+GL (non-3D) bits this week ;) -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB+GL resistor p0rn
If it was me, I think I'd make a script for some 3D modelling package like FreeCAD to generate a 3D model using PCB's XY place file output. The process would be: 1. make FreeCAD 3D models for each of the components 2. generate an XY place file, board outline file and drill file in PCB 3. run a python script in FreeCAD that generates a model of the board based on the outline gerber file. Make holes using data from the drill file. 4. Run a script that makes an assembly by placing components based on the XY place file. At this point you should have a 3D model of the board, right in a 3D CAD program that can be used to model enclosures and other parts. - Original Message From: John Griessen j...@ecosensory.com To: gEDA user mailing list geda-user@moria.seul.org Sent: Sun, November 21, 2010 1:29:38 PM Subject: Re: gEDA-user: PCB+GL resistor p0rn On 11/21/2010 11:49 AM, Dave McGuire wrote: Perhaps pixel shaders and bump mapping is a little overkill for a few resistors, but it has kept me amused for a while. Looks fab! Will actually be useful. Why not have processors churn for us? Overkill? There are so many ways to kill the problem of not-fully-designed circuits...and enclosures... How could one have overkill? The more ammo the better! Thanks, John ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
