query MUST filter or MAY filter

[tacaswell]

Thinking a bit more about @greglucas 's argument that range-restricted auto-limiting may be easier than I thought lead me to this idea.

As currently proto-typed the query semantics are "here is some information, you MAY use it to restrict the data returned. If we were going to start doing range-restricted autoscaling, then maybe we should change this to "here is some information, you MUST use it to restrict".

However while this does make the API more explicit and means we can do a bit more stuff with it on the calling side, it does impose a bunch more complexity on implementation side. If we consider the data

x = [0, 1, 0, 1, 0, 1]
y = [1, 2, 3, 4, 5, 6]

and the xview limit [-.5, .5] a naive way to just filtering could turn the zigzag into a vertical line. If we are doing scatter that is fine, but if the data is meant to be discretely sampled continuous data then that is quite wrong! So maybe you could say "well, in that case the query should add points at the edge of the view limit" which is fine, but then we have to be able to tell (if say we are showing both the lines and the points) the difference between the "real" points that should have markers and the "synthetic points" that are there to preserve continuity. We could (should) push the notion of continuity down into the containers so they can make the decisions.

However, this is a huge step up in obligatory complexity to go to MUST so I think I still prefer MAY as a pragmatic choice and think about adding another get_limits(...) with a similar API to query but that only returns ranges.

[greglucas]

I was also having a think about this 😄 I agree with what you wrote above, with some additional examples/links below.

If we push this to the data object that may not actually be what we want because we have markers that will add to this limit, matplotlib/matplotlib#7413, we also have non-affine transforms which can really mess up final extents depending on which data(x, y) pair gets projected in maps to projected(x, y). For example, here if I project all coordinates first and then do a contour in the native map projection, versus letting Cartopy handle the non-affine projection for me (slower, but better extent filling). https://scitools.org.uk/cartopy/docs/latest/gallery/scalar_data/contour_transforms.html#sphx-glr-gallery-scalar-data-contour-transforms-py

I do think this will require quite a bit of work and thought! (slightly contradicting my comments from yesterday) I feel like the true extent might need to be obtained from the rendering layer and that screen extent passed back to the MPL layer for setting the data limits... Is there a way to query a renderer for this information instead of the data objects?

[jklymak]

If you have artists that visually interpolate, like Line2D or any patch, I dont see how doing this is going to lead to useful optimizations. If you are doing Line2D and you have to check every data point pair for intersection of their connecting line with the viewport, that seems super inefficient compared to what I assume the backends can do for you?