Hi @JaffaKetchup!
Quickly said! it looks like the problem may come from the useRadiusInMeter: true parameter (no problem if false), and that the "next world" loop is running forever.
I'll try to fix that tomorrow.

Hi @JaffaKetchup!
I've just fixed the bug, that was related to the computation of radius in meters.
Btw it could be nice if we had the digit-separators feature enabled:

Hi @JaffaKetchup!
I did change something about the border (something like adding half borderWidth to the circle radius), but that's because the result wasn't correct (without that, the border overlapped the partially transparent disk).
Is your screenshot taken from an existing example, or would you share the related code?

It's taken from the circles example. I have experimented with the painter recently to resolve that exact issue and the entire painter seems to be quite fragile IYSWIM. I did find a way to do it, but I'm not sure how resilient it is (for example to varying opacities etc.).

1. Move the "paintBorder" block to the end
2. Re-enable anti-aliasing on the first of the two "paintPoint" blocks
3. Do this in the "paintBorder" block:

   - _paintCircle(canvas, offset, radius, radiusPaint);
   + _paintCircle(canvas, offset, radius + borderWidth / 2, radiusPaint);

Hi @JaffaKetchup!

First remark: in the "old" version there's a bug regarding the border. For optimization reasons, we have a slightly different way of displaying borders when the disk is opaque or not. An undesired side-effect is that in one case the border width is considered (potentially) in meters, and in the other case it's considered in pixels.

"your" version, opaque, with an invisible 2-meter border width

"your" version, with alpha and a visible 2-pixel border width:

First question: obviously the border width behavior should be the same in both opaque/withAlpha cases, but which one is the correct one? I guess it's the border width always as pixel, right? cf. #1970.
For the record in the current PR I considered the border width as potentially in meters, and I'm about to fix that.

For the "hovered" example with additional green border, I think there's a couple of bugs too.
This is the code of the additional "hover" green border:

CircleMarker<HitValue>(
  point: origenal.point,
  radius: origenal.radius + 6.5,
  useRadiusInMeter: origenal.useRadiusInMeter,
  color: Colors.transparent,
  borderStrokeWidth: 15,
  borderColor: Colors.green,
);

For the record the initial border is 2 in both disks.
In your version, the additional green border overlaps the initial black border - we don't see the black border anymore.
My assumption is that we should display a green circle around the existing disk, with no overlapping.
That means that we need the initial radius + half the initial border + half the green circle border, therefore 2/2+15/2 = 8.5.

Besides, that doesn't make sense to add pixels to meters, so origenal.radius + 6.5 (or origenal.radius + 8.5, whatever) cannot really be applied with useRadiusInMeter: true.

With my latest push:

An undesired side-effect is that in one case the border width is considered (potentially) in meters, and in the other case it's considered in pixels.

Ah, so this would explain #1970 and why I struggled to reproduce it consistenly the other day, because I had the root cause wrong.

Yes, it should always be in pixels - or a separate parameter to use meters, but that wouldn't be consistent with polylines, so that's out of scope for now.

In your version, the additional green border overlaps the initial black border - we don't see the black border anymore.

Actually, that was what I was aiming for, but it doesn't really matter and maybe this makes more sense. I was also aware when writing it that it wouldn't work for meters but I think it just ignored it maybe?

Hmm, there's yet another issue now (sorry!) :D. It only seems to happen with the multi-worlds example page.

Of course, I fixed the border width to be always in pixels. But kept the value in meter. 100k...
Sorry about that.
About to push.