circles getting smaller when zooming in

[LucaMarconato]

@kevinyamauchi I have just noticed (I think it was not happening before and today this started) that if I zoom in the circles I have get smaller. Before giving more details on napari version etc, does it happen to you to know that this is maybe a know bug or option can be quickly fixed?

Thanks

[kevinyamauchi]

Hey, @LucaMarconato ! There were some bugs in point sizing in older versions of napari. I think the point scaling was fixed somewhat recently (napari/napari#5312, napari/napari#5050). You may need to update napari and vispy to correct the behaviour.

[LucaMarconato]

Thanks for the answer. I have now installed vispy and napari from github but the problem remains :( I try now seeing if plotting circles instead of points improves the situation.

[LucaMarconato]

Ellipses work! The downside is that the creation of the layer is like 5-10x slower. The good thins is that at some point we may want to support ellipses and rectangles (they originate from a ShapeLayer after a non-homogeneous transformation), so the code would have changed anyway. But probably the best would be to use points instead of ellipses when we detect a circle, so that the performance is better.

[LucaMarconato]

Reopening because in #37 we went back to using points instead of ellipses for performance reasons, so this bug is still present (i.e. the radius of circles is unreliable and it depends on the zoom level).

We can choose one of the following approaches to fix this, the underlined one is the currently chosen:

1. wait for this to be fixed upstream in napari and don't to anything in napari_spatialdata until then (please @melonora can you edit my comment to add a link to this issue in napari if you know it's already being tracked).
2. use ellipses for small datasets and points for large datasets. I have this implemented in the spatialdata branch; if we implement this we need to be careful that when we save a shape layer and the shapes are actually ellipses, these need to be saved as points and not as shapely objects, otherwise we get inconsistent behaviors depending on how many times we load and save and how many points are present.

[melonora]

We are still using napari 0.4.17. I believe this should be fixed with 0.4.18, but let me get back to that.

[brisvag]

Sizes shouldn't change with zoom as far as I know... the issue we had in napari was with camera rotation. Do they actually get smaller, or do they simply stop growing once you zoom beyond a certain level? And are you on mac? If so, this sounds like it could be this old issue: vispy/vispy#2078

If it's that, there's no solution since it's a hardware limitation.

[LucaMarconato]

Hi, thanks for the answer. Yes, I am on a Mac and correct, they don't get smaller but they stop growing. A workaround could be to use ellipses instead of points when a Mac is detected, but the performance is much worse. Any other advice?

[brisvag]

As I mentioned in that vispy issue, the best workaround would be to make our own implementation of billboards using geometry shaders (best, but currently an issue because apple does everything it can to make things harder with opengl) and/or meshes (less performant and requires more set up on the cpu side and so has slower startup, but would work fine everywhere).

I don't really have the bandwith to work on this now, so afaik the current solutions are:

• someone else takes this on and reimplements markers using one of the above in vispy
• use ellipses (you could conditionally use them only if the gl marker size is limited)
• expose instanced rendering in napari and use that to replace/rework our current shapes layer to use that, or make a new layer (this will be done at some point, and some folks at CZI are on it I think... but it's a big project)
• don't buy Macs 😉

[LucaMarconato]

An implication of having a discrepancy between the rendered point and the actual point in macOS is that if that the user, when hovering with the mouse over a point, may see the attribute of a different point that seems far a way but it is actually overlapping the current point.

Example

• dark points have genes: gene_a, light points have genes: gene_b
• the GIF shows the points at their real size
  
  If we zoom in we see an example of dark point with genes: gene_b. This is not expected! The reason we see this is that dark point overlaps with one light point. But from the zoomed view it seems that the points are far apart.