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

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]

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

[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.