Re: gEDA-user: PCB+GL -> Stable (eventually...)

[Peter Clifton <pcjc2@xxxxxxxxx>]

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 <pcjc2@xxxxxxxxx>
Date:   Thu Nov 12 23:54:07 2009 +0000

    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 <pcjc2@xxxxxxxxx>
Date:   Fri Nov 13 01:14:08 2009 +0000

    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 <pcjc2@xxxxxxxxx>
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 <pcjc2@xxxxxxxxx>
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 <pcjc2@xxxxxxxxx>
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@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user