As you mentioned in the issue, the C++ code creates the codes, and it seems like those are returned in both cases:

Ah no, I see it doesn't:

But wouldn't it be less trouble to go to that directly?

Not really. Returning the kind codes from C++ would save us a few lines of Python but make the C++ more complicated, and it needs to be in both _contour.cpp and _tri.cpp. Those C++ changes will be obsolete in a few months when I address the performance issues in a coherent way.

[Aside: The major performance issue for contour lines in the example here is that Python/C++ create 318k numpy arrays of vertices and 318k numpy arrays of kind codes which are passed to the renderer for consumption. That is a lot of memory thrashing. It is only done this way because it was necessary for the 'new' (2014) contour algorithm to match the 'old' (2005) one. After 7 years I think we can be brave enough to change this to, for example, a smaller number of larger numpy arrays. But that needs to be done carefully and is outside the scope of this PR.]

As you have asked, I have added a commit that returns the kind codes from the C++. Interestingly it is marginally slower than the Python-only solution but my timings are not comprehensive. I'd be happy to roll back the PR to the Python-only changes if that is preferred. It is certainly simpler and lower risk.

Tests are passing now that I have modified the examples and mplot3d in line with the other changes. I've also added some new tests to increase the coverage.

There are two possible solutions here:

1. Simple Python-only fix (commit 1b15a11),
2. More complicated but more correct C++ fix (latest commit).

Either would be acceptable in terms of fixing the problem. I slightly favour of the C++ approach but could be persuaded either way. It is riskier than the Python-only solution in that there will almost certainly be some glitches caused by it, but I have the time and motivation to deal with these so now seems as good a time as any.

I guess I don't understand the tradeoffs in putting the work in the C++ code. Certainly there are a lot of changes, but they seem to be mostly just adding codes to the structure? The python changes are simpler, so what is the goal of pushing it down to C++?

The two implementations (Python and C++) are functionally equivalent and produce identical output. The difference is where the codes are calculated.

The benefit of the C++ implementation is that it is faster at determining if each contour line is a closed line loop or open line strip. However, this performance benefit is not a practical benefit as the time taken to create lots of numpy arrays swamps everything else. When I eventually improve the performance of contouring this will become important, but it isn't yet.

The git diff isn't hugely helpful here; looking at the changed C++ is probably better as the relationship between the vertices and codes arrays is more obvious. But yes, I am happy to add more comments.

@jklymak I've added more comments to _contour.cpp and _tri.cpp to explain the data returned from C++ to python, and also in the python function _make_paths.