• Previous message: Robert Penny: "Tile splitting question"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Dear Rob,
   The pathological benchmarks are readily explained by the style of
layout used interacting with magic's "maximal horizontal lines" policy
of tile splits and merges, without invoking non-Manhattan geometry.
However, it is also true that the stairstep conversion of non-Manhattan
polygons is an ABSOLUTELY worst-case scenario, and is usually marked
by memory and file sizes blowing up to epic proportions unless the
usage of the non-Manhattan geometry is minimal.  The non-Manhattan
extensions usually will alleviate that problem, especially for the
average use of 45-degree lines chamfering or beveling 90-degree
corners on pads and large metal areas.  However, if you get something
like a bus of metal lines travelling at a non-Manhattan angle for a
significant distance (compared to the width of the lines), you get a
worst-case scenario which is only slightly more efficient than if you
stairstepped the same geometry.
   Additionally, there is no routine which tries to clean up the
tiled plane over non-Manhattan tiles, so the more you work with
non-Manhattan geometry, the more fragmented the plane becomes.  This
is not a bug, but rather something that I have not yet got around to
implementing.
						Regards,
						Tim

• Next message: Jeff W. Sondeen: "Re: npn bjt"
• Previous message: Robert Penny: "Tile splitting question"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]