lplot and kplot slow and unresponsive within notebook environment when showing number labels.

[CesarRodriguezPereira]

Since updating to the latest PyMAPDL version I've found the new lplot and kplot implementations to be really slow and unresponsive. Rotating the views, zooming in or zooming out, displacement, everything takes a lot longer, when plotting within a notebook (in my case I use vscode to open the ipynb files). This slow behaviour often leads to kernel crashes, having to restart the whole kernel.

When using the notebook = False argument, the plots behave as they used to even while in notebooks. Also, using show_line_numbering=False or show_keypoint_numbering=False (for lplot and kplot respecitvely) bring back the old responsiveness. So it would seem it's the combination of labels and the notebook itself which leads to the slow performance and kernel crashes.

The rest of the tools (aplot, eplot, nplot) and result plots are working perfectly, and are still responsive even while within the notebook by default. This probably has something to do with these plots not having any label enabled by default (and I haven't checked manually activating the labels yet).

Relevant libraries:

ansys-corba               0.1.1                    pypi_0    pypi
ansys-grpc-mapdl          0.4.0                    pypi_0    pypi
ansys-mapdl-core          0.59.3                   pypi_0    pypi
ansys-mapdl-reader        0.51.3                   pypi_0    pypi
pyvista                   0.31.3             pyhd8ed1ab_0    conda-forge

PS: I've just tested after writing this. Both jupyterlab and jupyternotebook (the default implementations not related to any IDE) present the same behaviour as the ipynb within VScode.

[akaszynski]

You're exactly right regarding the labels. We switched over to the new labels visualizer that is supposed to hide labels when they overlap. It works well for a handful of labels, but I'm guessing that there's an edge case that we've completely missed.

I can revert this behavior by default. Curious, which version of ansys-mapdl-core did you upgrade from?

[CesarRodriguezPereira]

You're exactly right regarding the labels. We switched over to the new labels visualizer that is supposed to hide labels when they overlap. It works well for a handful of labels, but I'm guessing that there's an edge case that we've completely missed.

I can revert this behavior by default. Curious, which version of ansys-mapdl-core did you upgrade from?

Thanks for the quick response. I seem to remember the previous version I had installed was 0.58.9, before all the plotting methods consolidation. The edge case at play here is probably the sheer amount of lines at play in the geometry of my model, and the amount of overlap. It's not that many (len(mapdl.geometry.lnum) just returned 1415), but I'm guessing the complexity of the calculation for label overlap scales a lot. Curiously it works perfectly fine in a separate window, it's just with the notebook that the new labels wont play nice.

[akaszynski]

it's just with the notebook that the new labels wont play nice.

Interesting. That's the edge case we didn't consider. I'll have it such that when displaced within the notebook we disable the "smart" label feature.

[CesarRodriguezPereira]

Any way to manually disable smart labels when calling the plot functions (aside from completely disabling labels)? This bug complicates pure pyansys geometry operations a lot on anything that's mildly complex. Maybe having a kwarg that let's people disable the smart feature is an easier fix, without having to go to the hassle of detecting the execution environment.

[akaszynski]

Yes, that would be best. @germa89, can you take care of this? Effectively, when we create labels we should just set always_visible=True in our general_plotter. See add_point_labels