Large polygons are bad for performance

[asinghvi17]

You can't realistically go above 720x360 in a polygon without running into serious performance issues, at least the way I've implemented it currently. @SimonDanisch is there any way this could be done in the backend, as a nonlinear projection? It would have to be sort of black-boxed, though.

To give a brief explanation of what's going on now, what I've done is to simply define a mesh based on a regular grid in input space (usually untransformed lat-long), and then transform the points into projected space (whatever target projection is given). Then, an image is provided as the colour for the mesh.

As I understand it, this is similar to the approach which most people take to deforming images; however, it is much less performant. Any help optimizing this would be really appreciated.

[SimonDanisch]

Is this using poly?

[asinghvi17]

Yep, just poly(coordinates::Vector{Point2f0}, connectivity::Matrix{Int}). Would it be better to preconstruct a mesh?

[SimonDanisch]

Hm...If you give it a connectivity, that shouldn't be a problem.
Is it the rendering that is slow? a ~259_200 element mesh doesn't sound very big, so I'd be surprised to run into rendering performance problems

[visr]

Not sure to which degree the projection part is responsible. But would be good to set that up such that it doesn't allocate a length 2 Vector for each coordinate.

[asinghvi17]

I guess it might be? I get a lot of mouse stutter, and typing speed slows to a crawl. Replotting something else, like lines(rand(10)) fixes the issues...

[asinghvi17]

Not sure to which degree the projection part is responsible. But would be good to set that up such that it doesn't allocate a length 2 Vector for each coordinate.

The projection isn't, per se, but we have to deform the image - since projections are a black box, we need to know where the x, y coordinates of the image's grid map to. Therefore it's unfortunately necessary to allocate that length-2 vector. On the plus side, though, it only needs to be allocated once, and as long as the data isn't some ridiculously large resolution it should be fine to at least save to png.

[SimonDanisch]

Do you have an mwe for pure Makie?

[asinghvi17]

So this is really weird:

using Makie, GeoMakie
lats = LinRange(89.5, -89.5, 1000)
lons = LinRange(-179.5, 179.5, 1000)
points, faces = GeoMakie.triangulated_grid(lons, lats) # triangulated regular grid
cvec = rand(RGBf0, length(points))

is the setup code.

Now,

mesh(points, faces; color = cvec)

doesn't cause much of a performance penalty, but the image looks wrong I forgot to set shading = false, with that it looks fine:

whereas using poly, the performance penalty is very bad, but the image looks correct:

poly(points, faces; color = cvec)

[asinghvi17]

Nevermind, figured the mesh thing out, forgot to set shading to false.

[asinghvi17]

Whoa, this is really fast now...what happened to poly, to make it so slow?

[SimonDanisch]

btw, surface also works with gridlike but distorted data like this, and has an optimized shader ;)

[asinghvi17]

What's the method signature for that?

[SimonDanisch]

https://simondanisch.github.io/ReferenceImages/gallery//image_on_surface_sphere/index.html

[asinghvi17]

dang...I've been missing out I guess :D...thanks Simon! Will try that now. BTW, is it possible to use a 2D surface?

[SimonDanisch]

Yup!

[asinghvi17]

Huh, transforming this will be interesting :D - will have to figure some way out of transforming subarrays. Will be interesting for sure....is there any way to provide a Matrix of Point2f0 or something to the surface instead?

[asinghvi17]

Figured it out - just hacked the underlying proj4 implementation :D

[asinghvi17]

Again - thanks a lot @simon! @visr, the situation is a little better now - instead of materializing ncoords 2-vectors, I now just create 2 matrices of the same size as the image, which is a bit more space-efficient. They're created by using a monkeypatch to Proj4 which relies on the old API, but I'd like to upstream it anyway - it's just a relaxation of type constraints in _transform!.