Better PointTrans interface

[asinghvi17]

• Define PointTrans for VecTypes, not only Point
• Add transformation methods for Rects, so that PointTrans just works

The ultimate goal is that scene.transformation.transform_func[] = PointTrans{2}(f) where f(::VecTypes{N})::VecTypes{N} just works.

Here it's assumed that the method returns the input type, i.e., will return Point on an input of Point, Vec on an input of Vec.

Type of change

Delete options that do not apply:

• [X] New feature (non-breaking change which adds functionality)

Checklist

• [ ] Added an entry in NEWS.md (for new features and breaking changes)
• [ ] Added or changed relevant sections in the documentation
• [ ] Added unit tests for new algorithms, conversion methods, etc.

[MakieBot]

Compile Times benchmark

Note, that these numbers may fluctuate on the CI servers, so take them with a grain of salt. All benchmark results are based on the mean time and negative percent mean faster than master. Note, that GLMakie + WGLMakie run on an emulated GPU, so the runtime benchmark is much slower. Results are from running:

using_time = @ctime using Backend
# Compile time
create_time = @ctime fig = scatter(1:4; color=1:4, colormap=:turbo, markersize=20, visible=true)
display_time = @ctime Makie.colorbuffer(display(fig))
# Runtime
create_time = @benchmark fig = scatter(1:4; color=1:4, colormap=:turbo, markersize=20, visible=true)
display_time = @benchmark Makie.colorbuffer(display(fig))

	using	create	display	create	display
GLMakie	30.27s (30.05, 30.59) 0.19+-	16.53s (16.31, 16.90) 0.24+-	15.51s (15.31, 15.67) 0.13+-	10.73ms (10.53, 10.94) 0.13+-	113.56ms (112.62, 114.61) 0.79+-
master	30.22s (30.08, 30.44) 0.14+-	16.62s (16.43, 16.84) 0.18+-	15.48s (15.24, 15.66) 0.16+-	10.69ms (10.49, 10.94) 0.14+-	113.79ms (113.21, 114.91) 0.63+-
evaluation	+0.17%, 0.05s invariant (0.31d, 0.57p, 0.17std)	-0.53%, -0.09s invariant (-0.42d, 0.45p, 0.21std)	+0.17%, 0.03s invariant (0.18d, 0.74p, 0.15std)	+0.40%, 0.04ms invariant (0.31d, 0.57p, 0.14std)	-0.20%, -0.23ms invariant (-0.32d, 0.56p, 0.71std)
CairoMakie	26.59s (26.45, 26.79) 0.11+-	16.39s (16.22, 16.54) 0.10+-	2.53s (2.50, 2.57) 0.02+-	10.41ms (10.36, 10.51) 0.06+-	4.09ms (3.94, 4.31) 0.13+-
master	26.66s (26.54, 26.74) 0.09+-	16.43s (16.26, 16.62) 0.12+-	2.51s (2.48, 2.54) 0.02+-	10.35ms (10.28, 10.47) 0.07+-	4.06ms (3.98, 4.13) 0.06+-
evaluation	-0.27%, -0.07s invariant (-0.72d, 0.21p, 0.10std)	-0.27%, -0.04s invariant (-0.39d, 0.48p, 0.11std)	+0.61%, 0.02s invariant (0.70d, 0.21p, 0.02std)	+0.60%, 0.06ms invariant (1.01d, 0.08p, 0.06std)	+0.73%, 0.03ms invariant (0.30d, 0.60p, 0.09std)
WGLMakie	37.80s (37.57, 37.97) 0.15+-	19.92s (19.74, 20.17) 0.19+-	23.85s (23.61, 24.06) 0.16+-	14.22ms (13.79, 14.75) 0.37+-	2.41s (2.15, 2.62) 0.15+-
master	37.63s (37.45, 37.77) 0.11+-	19.93s (19.62, 20.27) 0.21+-	23.69s (23.39, 24.11) 0.25+-	14.70ms (14.00, 16.03) 0.67+-	2.29s (1.87, 2.47) 0.23+-
evaluation	+0.44%, 0.17s slower X (1.28d, 0.04p, 0.13std)	-0.08%, -0.02s invariant (-0.08d, 0.89p, 0.20std)	+0.67%, 0.16s invariant (0.77d, 0.18p, 0.20std)	-3.38%, -0.48ms invariant (-0.90d, 0.13p, 0.52std)	+5.00%, 0.12s invariant (0.61d, 0.28p, 0.19std)

[SimonDanisch]

Hm, could the _DEFAULT_RECT_TRANSFORM_DENSITY be part of the transformation function? Maybe we could even in general allow the transformation to resample the points, to e.g. easily turn the axis gridlines into curves. Although I'm a bit afraid that it'll be hard, since the transformation will only see points, but it may come from linesegments, lines, or even meshes or whatnot.

[asinghvi17]

We could definitely do that, perhaps as a field in scene.transformation. It's even possible that transforming lines etc could be a purely backend operation, and plot objects could be made more or less unaffected by the transform func in base Makie. This seems consistent with the model matrix approach we use now.

[SimonDanisch]

lines etc could be a purely backend operation

Well, it is right now, since the backends are applying any transformation ... Or what do you mean?

[asinghvi17]

I meant densifying / transforming lines, rects, heatmaps, etc.. so that a line with 2 points becomes a curve.

[SimonDanisch]

Yeah, so if we find a way to let apply_transformation guide this, we could do it quite elegantly in the backend, no?

[asinghvi17]

I think so - might want to make it another method in the interface though, and let apply_transform be a low-level method. I'll whip something up for this in a couple of weeks, but this might be best for a larger pull request. Does this look OK to merge as is?

[asinghvi17]

I'll put it into apply_transform for now, then spin it out in continued work. That makes sense - a global was the quick and dirty way to allow the transform to be configured but it does make sense to keep it as either a field of PointTrans or as a method (e.g. Makie.default_transform_density(f::T) where T).

[asinghvi17]

This should be ready for merge now...a future PR could implement resampling as we discussed.

[jkrumbiegel]

Not sure if a method for rects makes sense because the Rect around a set of points in linear space does not necessarily envelop those points in the transformed space right?

[asinghvi17]

@jkrumbiegel that's why I implemented that method, it basically takes a grid across the Rect (21x21 in this case), transforms each of those points, and finds the extrema, to get the min/max in transformed space. It's the same method which Proj (geospatial projection library) uses as a general fallback.

[SimonDanisch]

I think this will need further thoughts about the whole transformation pipeline and a proper refactor!