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 wr
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 t
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
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:
commit 5456171cbd9129402acfc6596d1cd7b742880324
Author: Andrew Poelstra
Date: Thu Aug 4 0
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.
>
> After I move components with arc on silk screen (like DIP-8 on attached
> board) from one side to another sometimes arcs (
On Fri, 19 Aug 2011 15:08:57 -0400
Dave McGuire 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 kno
-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 ann
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
Hi everyone,
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.
Best re
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-keyserv
2011/7/17 DJ Delorie :
>
>> 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=Hei
Hey folks. What's the preferred codebase for the fancy new GL stuff
in PCB? This is the last set of retrieval instructions that I have:
git clone git://repo.or.cz/geda-pcb/pcjc2.git
cd pcjc2
git checkout -t origin/local_customisation_no_pours
./autogen.sh
./configure --disable-doc --
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/Wm5IntrEllipse2Ellips
> 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
2011/7/16 DJ Delorie :
>
>> 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 pres
> 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
2011/7/16 DJ Delorie :
>
> 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 beein
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.
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.s
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/Documentati
2011/7/16 Karl Hammar :
> 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 ellips
Igor Lopez:
> 2011/7/16 Andrew Poelstra :
> > 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
> pro
2011/7/16 Andrew Poelstra :
> 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 met
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 calcu
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 calc
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 po
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 poi
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,
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
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
Igor:
> 2011/7/14 Karl Hammar :
> > 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
> 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
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 N
> 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 mailin
2011/7/14 Karl Hammar :
> 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:
>
>
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.
>
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, f
2011/7/15 Andrew Poelstra :
> 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 yo
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
2011/7/15 Andrew Poelstra :
> 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
>>
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 wrote:
> > > > Stretched arcs are a misfeature. Can they be deprecated?
> ...
> > The reason I bring this up is that the IsPointOnA
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
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
Andrew Poelstra:
> On Wed, Jul 13, 2011 at 01:01:34PM -0700, Colin D Bennett wrote:
> > Mark Rages 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 elli
2011/7/14 Andrew Poelstra :
> 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 wrote:
>>
>> > Stretched arcs are a misfeature. Can they be deprecated?
>> >
>> > Otherwise, they are just another object that cannot be rotated at
>>
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 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
On Wed, 13 Jul 2011 10:02:28 -0600
Mark Rages 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 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
Emai
On Wed, Jul 13, 2011 at 5:46 AM, Kai-Martin Knaak 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
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.
---<)kai
Peter,
Not sure if you are aware, but latest pcb with gl enabled
does not render stretched arcs properly. For example, a
pcb with
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
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 jum
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
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 tha
On Sat, 14 May 2011 10:59:57 +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?
Do you have t
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?
___
geda-user mailing l
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 ou
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 ou
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.
---<)kaim
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
th
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
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:
Â
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
>
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
� ori
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...@ca
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
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 c
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
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 cur
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
___
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 ha
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
>
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
On Wed, 2011-05-04 at 08:09 +1000, Stephen Ecob wrote:
> On Wed, May 4, 2011 at 7:37 AM, 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 HE
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 l
On Wed, May 4, 2011 at 7:37 AM, 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:
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
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 Hannov
PCB+GL has had a some love over the past few weeks, and it now supports:
Rendering background images (broken in the pcb+gl_experimental branch)
Live drawn animation whilst auto-routing
A progress bar showing progress during auto-routing
As always, testing and feedback is welcome.
I'm very close
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.
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-rep
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
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://
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
> >
> >
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
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 i
I sent a private email to Peter Clifton as I was (yet again) having
trouble finding the list message outlining his work, where to pull it,
and what branch to check out. 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
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, nvidi
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
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:
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
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
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
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
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_pour
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.
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
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 w
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 versio
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 updat
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
1 - 100 of 312 matches
Mail list logo
