XXX: ON REFLECTION, THIS "FIX" IS BOGUS... Fix bug in polygon contour generation

Incorrect contours were emitted in some cases when snap-rounding of vertices to
the integer grid cause coincident shared vertices from the same polygon to meet
at a cross-connected vertex.

The geometry required to create this situation is tricky, but could be provoked
in certain conditions by exactly touching line clearance polygons. (Due to
subtle rounding errors in the clearance polygons don't always meet exactly).

Distilling a simpler test case, the following polygons (on layer A and B)
should be united to reproduce the bug. (NB: The A POLYAREA has two contours
which touch at a single point):

  Layer(1 "A")
  (
    Polygon("")
    (
      [51.0000mm 18.0000mm] [51.0000mm 12.0000mm] [140.0000mm 12.0000mm  ] [144.0000mm 18.0000mm]
    )
    Polygon("")
    (
      [51.0000mm 6.0000mm] [144.0000mm 6.0000mm] [140.0000mm 12.0000mm] [51.0000mm 11.99996mm]
    )
  )
  Layer(2 "B")
  (
    Polygon("clearpoly")
    (
      [139.0000mm 5.0000mm] [145.0000mm 5.0000mm] [145.0000mm 19.0000mm] [139.0000mm 19.0000mm]
    )
  )

In this case the two contours of the 'A' polygon each have an edge that is
horizontal (or very close to horizontal), and meet at a single point inside
the 'B' polygon contour. Due to rounding onto the integer grid, both lines
intersect the B contour at the same point, leaving two coincident edge
fragments belonging to the A contour meeting at that one vertex on the B
contour.

In the above example, operation ordering conspires to insert the two identical
A edges into the CVC list for the common intersection point on the B contour,
in an incorrect order. (They are sorted by pseudo-angles, which are identical
in this case). The reversed order of these paired edges then upsets contour
labeling in node_label().

This commit fixes node_label() to look for and skip pairs of identically angled
edges from the same polygon when iterating around the CVC list. (We can
determine the INSIDE/OUTSIDE status when we find the next, non-paired edge from
the other polygon).

Introduce macros for traversing between edges and nodes in a specified direction

This greatly simplifies the code, at the cost of the traversal direction being
slightly less explicit.

polygon1.c: Refactor poly_Copy0 to use poly_Create(), rather than open-coding

This ensures all polygon initialisation happens in a common place

polygon1.c: Fix unitialised output polygon upon when hitting allocation failure

This was a bug present in the poly_Boolean() routine. We need to set the output
polygon to NULL if we are going to return early on memory failure. This was
noticed during general review after observing problems due to our copy routines
incorrectly returning FALSE when copying a NULL polygon.

Fix return codes from poly_Copy* functions when coping NULL input polygons

Copying a NULL polygon results in a NULL return polygon. This is not an error,
so be sure to return TRUE for success, otherwise we can abort boolean
later processing incorrectly, such as in poly_Boolean and poly_BooleanFree

polygon1.c: Remove now unused memory allocation macro MemGet

polyon1.c: Rework InsCntr to re-use poly_Create() rather than open-coding

This allows us to ensure common initialisation is performed in poly_Create().

This commit removes the single case where the memory allocation macro MemGet
was called, which will be removed in a later commit.

Make poly_Copy1 a static function internal to polygon1.c

polygon.c: Refactor NoHolesPolygonDicer to call poly_Copy0 rather than poly_Copy1

poly_Copy1 is much more of an internal function to polygon1.c, and this is its
only external caller. Replace this occurance with poly_Copy0, which is intended
to be the public API.

Attempt to fix bad rtree usage in polygon code

We need to delete the rtree entry before updating any bounds, otherwise
bad things might happen (and certainly, with NDEBUG undefined, we may
get asserts firing in rtree.c)

To avoid computational expense deleting and removing from the rtree in
the general case (where we wouldn't expect bounds to change), a new
test function has been added which determines whether the contour bounds
will be updated or not.

Try applying Martin's upstream patch (or similar)... and see how that looks with our new macros

Rename v->e and e->v to clairfy edge vs. vertex usage

polygon1.c: Rename rule and v_rule to j_rule for consistency

Rename VNODE data elements back

Add macros to access ->next and ->prev of vertices / edges to aid clarity of code function

Rename NODE_LABEL and LABEL_NODE to reflect that they operate on edges

Fix poly contours (?)

XXX: Thermals are not fixed up after frac_circle() changes
 V2: Leave all but LinePoly using the old frac_circle(), new frac_circle2() fixes LinePoly
     (also use frac_circle2() in CirclePoly to avoid adding a repeat vertex)

polygon.c: For some reason, the range computation in frac_circle appears to be wrong

Remove S_Rule remenants from polygon1.c

These "start" rules are not required, as we can use the "jump" rules instead.

Partial fix for broken polygon contour generation

The fix in commit 29258d77731c3a34b3335f3b3657fb549d449c71 for problems
with single point touching A and B polygons was incorrect and can lead
to broken output.

This can be seen in the following test-case from Dave McGuire:

  Element["" "" "" "unknown" 1325.00mil 1070.00mil -175.00mil -105.00mil 0 100 ""]
  (
    Pad[-85.00mil -39.00mil -79.00mil -39.00mil 34.00mil 30.00mil 40.00mil "2" "2" "square"]
  )

  Layer(1 "component")
  (
    Line[1245.00mil 1030.00mil 1195.00mil 1030.00mil 12.00mil 20.00mil "clearline"]
    Polygon("clearpoly")
    (
      [5.00mil 5.00mil] [4195.00mil 5.00mil] [4195.00mil 2695.00mil] [5.00mil 2695.00mil]
    )
  )

The problem occurs in the Collect() routine. In the above example, the first
point tested on the 'A' polygon is not part of the output contour, but IS a
vertex where the A and B touch. As a result, the (buggy) code then flips
directly to the 'B' poylgon without checking that it belongs in the output
contour, resulting in incorrect vertices being inserted into the output.

What we should do (at least a sufficient fix) is walk ("Collect") the intersected
'B' polygon contours explicitly. This commit implements that change.

Refactor poly_CreateNode() to take a pre-created VNODE structure, not a Vector

This helps to keep consitency with other functions adding vertices to a
contour and will be useful when additional data is added to the VNODE
structure. (Meaning it can be set the same way in all cases).

polygon.c: Add option to include drills holes (from vias / pins) in the board outline

V2: Fixup board_outline_poly() to subtract vias / pins even if no outline was found

hid/gtk (GL): Add hacky code to render outline of board, and mask cutout geometry

32bit: Fix GL HID zoom out, due to over-shooting Coord data-type

Nasty NASTY hack this, but it gets me working again.

Play with locked object rendering

(HACK HACK HACK HACK HACK)

Did I mention this was a hacky pile of rubbish code.. the main point of
the exercise is to determine whether the usability is better or not.

More rubberbanding algorithm tweaks

First attempts at improved rubberbanding logic

Introduce hacky code to switch cursor when over a line we might drag

Tidy up rubberband.c

drc: HACK HACK HACK

Fix to ParseGroupString()

Revert "Just make a black background."

This reverts commit cf6c95ade3be149a5a8659bd13a80eedc4092fd2.

Disable texturing the board's soldermask

Add a load more hacky models for test rendering

Add a demonstration model for rendering ACY series resistors

Play with some lighting effects (SLOW!!!)
Play with shaders and lighting goodness

Oops, nasty hack due to unknown code changes on merge. Left merge comments commented out for now.

Just make a black background.

Re-write ghid_set_layer() for some reason (can't recall why!)

Win32: Fix build for win32

hidgl: Attempt at fixing ORTHO view

Play with perspective

NB: Edit to hidgl.c:

+#if 0
+  glPushAttrib (GL_CURRENT_BIT);
+  glColor4f (1., 1., 1., 1.);
+  glDrawArrays (GL_LINE_STRIP, 0, priv->buffer.vertex_count);
+  glPopAttrib ();
+#endif

Is probably bogus. (Leftover debug?)

Draw polygons in a more intelligent order

A sub-compositing stencil bit "S" is used to avoid overlapping polygons.

PASS 1a. Draw all non holed "SOLID" polygons which don't clear other
         geometry.

PASS 1b. Draw all "SOLID" polygons with holes.
         --
         In addition to "S", A second stencil bit, "H" is required for
         each of these polygons. Both are masked against. After each
         polygon drawn, a new "S" stencil bit is required.

PASS 2.  Mask out all clearance holes from other geometry.
         --
         As this is a polygon ONLY layer being subcomposited, this masking
         can be done directly on the "S" bit-plane.

PASS 3a. Draw all polygons which only feature clearance holes
PASS 3b. Draw all polygons which have user-defined holes.
         --
         In addition to "S", a second stencil bit, "H" is required for
         each of these polygons. Both are masked against. After each
         polygon drawn, a new "S" stencil bit is required.

NB: In this version. PASS 2 and 3 are carried out concurrently, although
    for boards with heavily overlapping polygons, it may be faster to
    mask out clearance for everything at once.

V2: We have to force a new stencil bit for each piece of a "fullpoly" polygon
as a hole in the first POLYAREA should not prevent a second POLYAREA of the
same polygon being drawn inside that hole. In this regard, we need to treat
"fullpoly" polygons as if they contained user holes.

Try a new, different sized VBO buffer for each upload.

Cache polygon contour tri-strip tesselations (HACK: IN THE CORE!)

This is a bit of a KLUDGE really, we should not push data
into the core like this.

Play with GLSL shader for rendering line caps and circles

And of course.. typically, a million other little fixes:

 - Primitive rendering object changed from GL_TRIANGLES to GL_TRIANGLE_STRIP
 - Cache of tristrip data per contour (HACK: in the core)
 - Rendering using mapped VBOs rather than just arrays
 - Updated layer depth code, so we render with "z" in world coordinates
 - Space navigator joystick support fixes against later kernels

Bugs:
 - Layer depths will be wrong for reversed layer group numbering
 - Pixel shader ought to be switched off for polygon fill?
 - hidgl_draw_rect stubbed out (for benchmarking)
 - Draw Element mark stubbed out (for benchmarking)
 - Draw crosshair stubbed out (for benchmarking)
 - Draw crosshair not updated to render in world coordinates

Notes:
 - Apparently it can be better to do glVertexPointer last (so we do):
    From: http://sdickinson.com/wordpress/?p=122
    ""
    Make sure you put glVertexPointer at the end as there is a lot of work that
    goes on behind the scenes with it, and if it's set at the start, it has to
    do all that work for each gl*Pointer call, rather than once at the end.
    ""

 - We set up the array pointers before calling glEnableClientState():
    I'm not sure, but if we do this the other way around, it might cause
    the driver to hang onto our old buffers longer, or perform state setup,
    only to have to discard that work shortly after.

 - DARN: Seems that using VBOs is not a win, even on Intel 965:
    Certainly seems to fail miserably (v. low FPS) on my NVidia card.

    On Intel, sysprof shows a huge amount of time spent clflushing
    buffers, or copying to the graphics card (uncached).

    Set to use glBufferSubData by default for now.

hid/gtk (GL): I think the polygon renderer works in mask mode now

Put back layer opacity to its old behaviour

The exact details of this setting aren't right yet,
so revert them so I can build a release.

PCB+GL: Fix GL headers for Win32

hid/common/hidgl: Debug out of context rendering

Hack to avoid GL calls when we're out of context

Add cache for board-outline

This adds a cache of the board outline, to improve rendering speed
when plotting the board with an outline.

The cache is invalidated when the "outline" or "route" layer is
updated. We catch this by bodging the ClearFromPolygon() routine,
which is called for almost all layer geometry changes which might
affect us.

XXX: We really need to add a nicer place to be notified of board
layer changes!

Board outline polygon generation

FIXME: Make this work with the GL masking polygon drawing routines, rather
       than relying on the dicer.

Add routines to render just a single contour

Use them rather than the GLU tessellator

BORAST: Fixup to only draw the passed POLYAREA, not walk the linked list of POLYAREA and draw them all!

borast: Win32: Comment #define in borast-compiler-private.h

Fix borast not to build for non-GL enabled builds

Bentley-Ottann test implementation

Code from cairo - intersection routines stripped out

XXX: Appears to be some breakage in demo.pcb (See top LHS component layer polygons)

Silly space navigator interface to allow funky views

Draw pin / pad names first, so they don't get masked by the pad

Since we use stencil masking to ensure we don't redraw an area
multiple times, confusingly, we need to draw the text first to
ensure it isn't occluded by the pad its-self.

HACK:

We probably draw the names multiple times - as we still use the
common draw.c code which assumes it can draw labels on top of
the pads.

gtk/gl: Play with layer translucency

Add support for drawing objects from the soldermask layer

Fixup code to determine whether we draw pins/vias on a given layer

The net change of this patch is that we consider whether to draw pins/vias
for each layer within the layer group. Previously, if we encoundered a layer
named "outline" or "route" within the layer group, all _subsequent_ layers
within that group would not have their pins/vias rendered.

As ordering of the layers within the group should not be important like this,
change behaviour to apply test on a per-layer basis.

draw_funcs.c: Don't draw pins/vias in layer for non GUI exporters

The non-gui paths render pins and vias with draw_ppv, so no need to
also render them for each layer.

Add HID_DRAW * parameters to various Draw*() function called from the GTK hid

Fixup gtkhid-gl to build

Major re-write to drawing routines

FIXME: FULLY OF NASTY API HACKS TO draw.c

Notes from squashed patches:
  Pin and via hole cores are drawn in the appropriate colour
  Playing with stack rendering order
  Fix mask display in 3D (Allow both side masks to display at once)
  Fix rendering depths for silk and mask layers
  Fixup depth for layers and element marks
  Move more rendering to world coordinates
  Fix get_coords function
  Re-write parts of the PCB+GL set_layer function
  Fix layer on/off rendering after commit 9768e060fad7bc3dfc366da76ea1db8154005018
  Only assign stencil planes where sub-compositing is required - that is, not the far-side, mask, rat or switched off layers.
  Pass an explicit graphics context to DrawAttached and DrawMark

TMP FIXES

DRAW_FUNCS: Attempt at different render order for PCB+GL

Fixup gtkhid-gl.c to accomodate depth being set per hidgl context

Shiny 3D eye-candy

Experiments in progress - don't expect this to work yet!

Squashed:
  Fix grid extents in 3D view

Crasy test

Fix indentation in one place (avoids spurious gcc warning)

Tidy up range check in misc.c

For consistnecy with other range checks involving max_copper_layer, and to
drive home the fact we are checking for exceeding max_copper_layer + 2.
NB: The +2 relates to the bottom silk and top-silk layers, whose numbers
are used to denote the bottom and top layer groups respectively.

re-write:
  layer > max_copper_layer + 1

to become:
  layer >= max_copper_layer + 2

Fixup some bugs from the added soldermask layers

(TODO: Finish this fixup and merge it down into the relevant patches)

draw.c: Opencode the mask layer object drawing functions

Calling DrawLayer() did not render using the correct graphics context / colors.
NB: We're still using the "wrong" GC, but we now avoid selecting inappropriate
colors which prevent (say) PS export working correctly for mask layer objects.

Add support for a two soldermask layers, defining regions of removed mask

File-format wise, these work similarly to how silk layers are supported now:

Layer (1 to n "[NAME]")            # "ordinary" design layers
Layer (n+1 "silk")                 # bottom side silk
Layer (n+2 "silk")                 # top side silk
Layer (n+3 "bottom soldermask")    # bottom side soldermask
Layer (n+4 "top soldermask")       # top side soldermask

Avoid hard-coding the number of extra layers in use (for 2x silkscreen)

We will shorty add support for soldermask layers, so this will need changing

NOTE....... IF THE parse_y.y patch in the stg series before this gets
dropped, there is one more case where + 2 needs to be replaced with EXTRA_LAYERS

find.c: The User varaible needs to die...

Reduce its usage to where absolutely necessary... oh, what a surprise,
another variable passing state down into add_object_to_list ()

Add the drc flag as a parameter

Ok, this is nasty.. I'm obscuring setting of the global varaible... be careful!

Add the bloat as a parameter

Ok, this is nasty.. I'm obscuring setting of the global varaible... be careful!

find.c: Refactor some common sequences into a helper function

parse_y.y: Try to avoid two shift/reduce and reduce/reduce warnings

TODO: Check this matches up against our expected behavior.

Removing the parsedata section ("I think") has no effect, as elements
hit the alternative | element clause within parsepcb.

HOWEVER... I need to check whether there is any other valid syntax
inside an element file, or any backwards compatibility with old formats
which we may miss with the loss of parsedata.

Play with grid snapping heuristics a little

Require the pointer to be inside the bounding box of a pin / pad / via before snapping.
This makse it MUCH easier to place vias in a regular grid spaced at the PCB grid spacing.

Add hysteresis to grid-snapping

Remove graphics pointer from HID structure

Pass a HID_DRAW * instance to hid_expose_callback() rather than a HID * pointer

Drawing should eventually be independent of the HID

Fixup draw.c not to special case based on HID name, use flags instead

hidgl: Provide more explicit management of rendering instances

Provide an (hidgl_instance *) pointer which is used to refer to a hidgl
instance when caling hidgl_* APIs that are instance, but not hidGC specific.

Various hidgl APIs now take the hidgl_instance as a parameter, or in the case
of hidgl_new_instance(), return a new instance.

Graphics APIs which previously had a hidGC parameter remain the same, as the
hidglGC structure now contains a link to the hidgl instance which created it.

This change paves the way to potentially having multiple hidgl instances active
simultaneously, and removes various global variables (such as "buffer" and
"global_depth") which were previously accessible to allow the gtk-gl HID to
draw using the hidgl internals.

The gtk-gl HID_DRAW graphics API now subclasses the hidgl HID_DRAW API, so the
gtk-gl HID can access the (non-private) gtk_gc->hidgl_gc.* fields.

TEMP: Fixup fallout from nogui change

*** Might be nicer to just implement a no-op end_layer function for each HID_DRAW?

Move some fields from the HID* structure to HID_DRAW* and HID_DRAW_CLASS*

The parameters gui, poly_before, poly_after only effect rendering, so
belong in either the HID_DRAW_CLASS or HID_DRAW instance structure.

The set_layer() and end_layer() APIs also belong in the HID_DRAW_CLASS

We leave a copy of the "gui" flag in the HID structure, as main.c uses
this to count up each type of exporter.

XXX: THIS BREAKS SOME EXPORERS WHICH RELY ON THE NO-OP end_layer function
previously initialised in common_nogui_init()

main.c: Initialise crosshair unconditionally

Since we no longer generate graphics contexts from InitCrosshair(),
there is no need to check gui->gui before calling it.

Make HID_DRAW * an instance of the HID_DRAW class, not the API vfunc table

This allows us to store per-instance parameters in a clean structure.

Use calling wrappers rather than accessing HID_DRAW* vfunc tables directly

Add calling wrappers for HID_DRAW virtual functions

NB: hid_draw_make_gc() and hid_draw_use_mask() take a HID_DRAW * pointer,
    not a hidGC pointer like all the other hid_draw_*() functions..

Ugly inconsistency, but avoids making the change too disruptive.

Add a pointer in hid_gc_struct to link a gc and the relevant HID_DRAW vfunc table

Rename hidGC "me_pointer" to "hid"

The pointer provides a link between a HID specific graphics context and HID
in question, name it accordingly.

Expose a base hidGC structure for HIDs to inherit from.

Have each HID inherit from a common base structure, which will later allow us
to store enough reference to the HID / HID_DRAW code owning the hidGC to
wrap up the API calls (rather than calling directly into the vfunc table).

src/create.[ch]: Converted plain comments into doxygen comments.

Signed-off-by: bert <bert.timmerman@xs4all.nl>

src/copy.[ch]: Converted plain comments into doxygen comments.

Signed-off-by: bert <bert.timmerman@xs4all.nl>

src/const.h: Converted plain comments into doxygen comments.

Signed-off-by: bert <bert.timmerman@xs4all.nl>

src/compat.[ch]: Converted plain comments into doxygen comments.

Signed-off-by: bert <bert.timmerman@xs4all.nl>