Consider exposing control over point compression

[abdelq]

Hello Matthias,

At $DAY_JOB, the chip designers are somewhat irrationally against point compression in general.

I'm aware this exists for test purposes:

klayout/src/db/db/dbPolygonGenerators.h

Lines 166 to 171 in 6d6596a

	/**
	* @brief Disables or enable compression for polygon contours
	*
	* This method switches the global flag and is intended for regression test purposes only!
	*/
	static void enable_compression_global (bool enable) { ms_compress = enable; }

I'm also aware of raw polygons, but that doesn't extend to Region#merge/merged, any boolean (AND/OR/XOR/NOT), or EdgeProcessor pass

For those folks, it would be useful to have a flag at a global level, accessible from the Python API (something at the Layout level perhaps?).

[abdelq]

On further thought, I'm curious what the ramifications are for when you are writing a GDS, but the polygon count is too high. Does it just error out or split them? IIRC, they currently get compressed.

[klayoutmatthias]

Hi @abdelq,

do you mean people want to have compression or don't want it?

That specific flag you mention is for a very specific purpose and applies to polygons generated by booleans. If you turn off compression, the resulting polygons will have many more vertices in places where original edges met for example. I don't think that is really useful. A merged polygon by definition is the minimum set of edges that encloses the original polygons, so turning off compression is a bit against that definition.

Regarding writing all points to GDS: in GDS, the polygon points is stored in a XY record whose size is limited. So you cannot fit an infinitely large number of points in a polygon. If you exceed the number of points per XY record, you will get a corrupt GDS file. There is a (inofficial) way of fitting more points by writing multiple XY records per polygon, but I think most third-party reader will not like that. OASIS has unlimited number of points per polygon.

Matthias

[abdelq]

do you mean people want to have compression or don't want it?

They don't want it. They'd rather tweak the point density manually to get a smaller GDS.

That specific flag you mention is for a very specific purpose and applies to polygons generated by booleans. If you turn off compression, the resulting polygons will have many more vertices in places where original edges met for example. I don't think that is really useful. A merged polygon by definition is the minimum set of edges that encloses the original polygons, so turning off compression is a bit against that definition.

Let's say we have a polygon that represents a circular 90° bend. It has a certain specific point density.
If, let's say, they decide to connect two of these together and merge them as a single polygon to form a 180° bend, they would assume that only the points of contact are fused, and that the rest of the points don't change.

I think the general worry stems from them knowing that with a specific polygon given to a certain foundry, they have a good idea of the result for the metrics they care about. However, if the compression happens, they have to potentially pay the cost of a wafer to figure out if this changes anything or not.

Regarding writing all points to GDS: in GDS, the polygon points is stored in a XY record whose size is limited. So you cannot fit an infinitely large number of points in a polygon. If you exceed the number of points per XY record, you will get a corrupt GDS file. There is a (inofficial) way of fitting more points by writing multiple XY records per polygon, but I think most third-party reader will not like that. OASIS has unlimited number of points per polygon.

We have multi XY records enabled by default for $DAY_JOB use, but yeah, I believe we already got a case of one third-party not supporting it. There is an internal push to switch to OASIS too.

[abdelq]

I can't reopen #2343, so I'll just comment here since it's somewhat linked.

That specific patch is somewhat inconsistent. For the full context, the script that prompted that issue is trying to build a reticle/mask out of a few dies by just importing the GDS and applying basic transformations. This is a bit different from what prompted this issue, which is more generally about design and making the layout itself.

For #2343, I believe the code that reads the GDS outputs SimplePolygon, and potentially SimplePolygonRef / PolygonRef / ShapeRef and others that end up getting compressed.

Reverting that change, but having a global flag to control the compression would address that specific issue too.