Remove all resizing logic on the front-end

[martinRenou]

@kboone if you don't mind looking at it that would be awesome!

I am removing lots of code you added in #147. I am basically removing all resizing logic on the JavaScript side, and matplotlib is entirely responsible for the plot sizing through figsize in plt.figure() and fig.set_size_inches(). Some of this leftover resizing logic was causing some flickering (the front-end was requesting resizes while there was no need for a resize).
I wonder why you added so much logic in the resize

Note that we might put back some of this resizing logic when adding a resize handle on the figure (allowing to resize with the mouse). I am planning to work on this after this cleaning.

I think it is safe to say that it will finally close #117.

[martinRenou]

We don't want this, this was causing a redraw every time the plot container was resized in JupyterLab, but this redraw was useless (because the plot size is controlled by matplotlib, not JupyterLab), and it was causing some flickering.

[martinRenou]

Same here, all those request_resize were useless and were causing flickering.

[kboone]

Thanks for looking into this. When I first started working on this, it seemed like from the discussion in #117 that people wanted to be able to set the figure size either by using either the matplotlib api (e.g. fig.set_size_inches()) or the widgets API (e.g. fig.canvas.layout.width = '500px).

The JavaScript logic was an attempt at handling the widgets API. When the canvas width is set to something like 500px, there isn't a good way of inferring what size that should be in matplotlib, and it will depend on the client. My approach was basically a hack to take the current widget and calculate what the matplotlib figure size should be off of that. I then sent out a request to matplotlib to resize the figure to that size. This works and has the "expected behavior" for both APIs, but is ugly because it requires you to know how the figure and decorations are all laid out.

I am not personally experiencing any flickering, but that is likely a bug where the matplotlib resize code is being called somewhere that it shouldn't be.

With your PR you will lose the ability to set the canvas size via the widgets API (e.g. fig.canvas.layout.width). There is probably a much better way of supporting that API... I am not a javascript expert by any means.

[martinRenou]

I guess not supporting fig.canvas.layout.width and only allowing setting the size from the matplotlib API is fine. We cannot really support fig.canvas.layout.width anyway, because values like auto or 100% would not work (due to the fact that multiple views that don't have the same available space on the page would fight and keep requesting resizes from matplotlib).

It was actually my first approach to ignore the sizing from matplotlib and to do a "responsive" plot, but that does not fit with the matplotlib way of doing things, and people were unhappy about not being able to set the size from the matplotlib API (see #117 ).

Do you agree with all this? Were you using fig.canvas.layout.width yourself?

[kboone]

I do not use fig.canvas.layout.width myself and I am fine if you want to drop that support. I assumed that it was necessary to support both based off of the discussion in #117, but I think that in most cases people just want the matplotlib API.

There is definitely no easy way to sync things across multiple clients and keep both APIs. I believe that even the decorators aren't guaranteed to be the same sizes across clients so even for fixed sized plots there would be issues. To handle multiple clients properly, you would need to have different matplotlib figure sizes for each of the clients and rework the backend to support that.