[FEATURE] Use classes instead of `Record`s for efficiency

[josxha]

The research in #1750 (comment) and #1750 (comment) points out the reasons to avoid records.
Records have no advantage on memory consumtion while they require about double the time to be initialized.

As a consequence we should remove records from the package and use immutable classes in favour of it.

[monsieurtanuki]

@josxha That would include this one in Projection:

  (double, double) projectXY(LatLng latlng);

Would definitely be a breaking change, but would hopefully bring better performances. Something like that?

  DoublePoint projectDoublePoint(LatLng latlng);

Instead of redundant code like this one:

  _ProjectedPolygon._fromPolygon(Projection projection, Polygon<R> polygon)
      : this._(
          polygon: polygon,
          points: List<DoublePoint>.generate(
            polygon.points.length,
            (j) {
              final (x, y) = projection.projectXY(polygon.points[j]);
              return DoublePoint(x, y);
            },

[monsieurtanuki]

@josxha For the record I've just tried to replace (double, double) methods with Offset in class Crs (which eventually impacted a dozen of classes).
I cannot say that there was that much impact on performances using Offset instead of (double, double), in a first approach, using the "Polyline Stress Test" in profile mode (raster then UI, in ms):

x	old solid algo	new solid algo
offset	203.4 + 43.6	556.2 + 54.6
(double, double)	206.2 + 42.1	578.9 + 53.2

For next tests:

• profile mode
• "Polyline Stress Test"
• zoom 5 times around "Valence, France"
• slider to the left

Something like that:

[JaffaKetchup]

I will say that I don't think this is top priority. This is quite a level of micro-optimization!

[mootw]

@josxha @monsieurtanuki quick update on this. I have been doing some numbers optimizations for another rendering project using FM and drawing verts. Here are a few things i have found that using the

The math Point class is much slower (2-3x in my testing) than the Offset class which is fixed to the double type.

I actually looked at swapping out all of the references to Point in FM to Offset, and it affects many classes but it should be doable, and would lead to noticeable improvements in performance, especially in slow areas.

Avoid creating new objects, always reuse objects if possible.

Record/destructuring response from the project method is significantly faster than the Offset return type, ONLY if i do not re-create more Offset objects after handling projection.

Writing/reading things to fixed size lists is insanely fast, easily 10x faster than Linked List types.

I am able to render easily in under 16ms well over 50k projected triangles with unique colors per frame using DrawVertsRaw and these tricks above!

I believe that implementing fixed size lists, using the destructuring/record type for offsets and removing offsets from the last 0-2 steps of rendering (depending on where it is appropriate) will lead to significant improvements in render time for the most expensive layers like polygons and polylines. Storing a Float32List for all positions is significantly faster than a List of Offsets.

[monsieurtanuki]

@mootw If relevant, we could even create our own MyPoint class. We somehow currently do so, with DoublePoint, don't we?
As I started coding in the 80's I can have surprising ideas regarding optimization, like storing 2 floats inside a single 64-bit integer. Especially given the level of "floatitude" that we probably need here (I mean, pixels). Tell me if you're interested.

About fixed-length lists, it does look promising, but there may be problems with memory (as I assume they allocate a single consecutive space that needs to be "big enough", like an array, TBC). What happens when we add an item: does it rebuild the whole array?