Shipping Clipper 2 with Z enabled - cost/benefit?

[philstopford]

For most of my usage of Clipper2, I use C# and a local build from source, so I can enable the Z component. I use the Z component in a number of ways, from tracking insertion points to tracking weighting values for secondary rays through a raycaster (for visibility calculations and similar). Almost everything I've used Clipper 1 and 2 for, the Z callback has been extremely helpful.

Recently, I needed to port some of this code from C# to Python, and found the pyclipr library (which wraps some version of Clipper in Python - https://github.com/drlukeparry/pyclipr). Very useful, but it doesn't seem to support the Z component when used via 'pip install', and I assume this is because the default shipping mode of Clipper is to not have the Z support built-in.

This is also true for C# nuget packages from what I could tell.

I wondered if there was actually-measurable benefit (memory / runtime) to not shipping with the Z support enabled, especially given the functional limitations this brings for packaged releases.

[AngusJohnson]

HI Phil.

IIRC, the performance costs (of using Z) are relatively small. But nevertheless, I suspect some library users would be unhappy to give up this modest reduction in performance.

However, perhaps more problematic would be redesigning the various structures and functions in clipper.export.h (that currently don't accommodate Z). This could perhaps be done in a separate clipper.export.usingz.h file, but I'm currently disinclined to do this as it's a fair amount of work (also requiring documentation) and it would further complicate the library.

[philstopford]

Given that Z already exists as an option, I wasn't expecting you'd need a broader bit of work than just flipping the preprocessor flag to on when packaging. I'm just wondering if the performance-focussed folks pick up the shipped package rather than building it themselves (to allow them to add compiler optimizations, etc.)