Feature: use kiwi.js for controlling min and max aspect

[maartenbreddels]

Describe your changes
For more complex layouts, we may want to use Cassoway solvers, where kiwi.js is an implementation of that.

Testing performed
Test are first written to confirm the current working solution, it is then rewritten using kiwi.\

Additional context
This is a proof of concept to show how it changes the code. Actually, we should keep the current solver, not rebuild it all the time from scratch for performance. Although maybe it is fast enough to let us do this.

Next step would be to add a layout feature based on kiwi, for instance, automatic padding or resizing based on color axes.

[jbednar]

You might want to discuss this approach with Mateusz Paprocki, as he has years of experience working with kiwi for Bokeh, with a lot of positive and negative he can share...

[maartenbreddels]

Thanks @jbednar, will do, I was actually looking at Bokeh, to see why it is not a dependency anymore, and I couldn't find it.

[jbednar]

Right. Talk to Mateusz about that. :-)

[mattpap]

In bokeh we dropped constraint system based layout, because of inadequacy of this approach both from functional and performance perspectives. If the decision was up to me at the time, we wouldn't go that direction at all, choosing a classical "box" layout (or QT-style layout) instead, which is what we use now. Constraint system based layout seems very appealing to people, almost irresistible as the initial approach, but usually it is eventually replaced by another approach, at least based on my observations.

This approach could have been made at least somewhat viable if there was a solver 10x (or better 100x) faster than kiwi (was at the time, but looking at benchmarks in the new repository, that didn't change significantly). Even then, the complexity wouldn't be acceptable from long term maintenance point of view. Though that could have been a problem with our particular approach (a global solver, with thousands of constraints). I considered keeping kiwi to solve local optimisation problems within the layout, but that seemed more trouble than it was worth, considering issues with kiwi itself.

[maartenbreddels]

Thanks for sharing your experience.

I considered keeping kiwi to solve local optimisation problems within the layout, but that seemed more trouble than it was worth, considering issues with kiwi itself.

I think that is the approach we aim to use as well. I think for now it's easier to put the constraints in kiwi first, and let it solve it. It should be easy to replace by an analytical solution if needed/possible.

[maartenbreddels]

Update for now. I've managed to combine aspect ratio constraints with what I call 'decorators' (stuff outside the figure that takes up width or height). It works for the title, and partly for the axes:

The axes though, still needs a bit of work, because the label offset is fixed. We probably also want to have color axes support.

I also don't know what we should do with the fig_margins. Should we keep them, and what is the meaning of them?

[jasongrout]

Sylvain, you missed one of the emojis :)

[SylvainCorlay]

Sylvain, you missed two emojis :)

Was is ?

[jasongrout]

Was is ?

Nice. I meant eyeballs, but I'm sure shipit will apply soon too :).

[maartenbreddels]

I've put together support for a coloraxis and added an example ipyvueitfy small UI to play with the 'side' trait of axes (to be committed):

[maartenbreddels]

Note that because of the refactor, we don't have Figure.width and Figure.plotarea_with anymore, only Figure.width is used now (with itself was never used without fig_margins, and width now is the old plotarea_width).

[martinRenou]

If I understand correctly, in the current state of the PR, there is a circle in the logic:

• The size of the plot area is computed with kiwi with the following constraints: min-aspect-ratio, max-aspect-ratio and the axes sizes
• The axes sizes depend on the plot area size, so they must be displayed already

This means that kiwi cannot compute the plot area size until the plot is already displayed. Am I getting this right @maartenbreddels ?

[maartenbreddels]

• The axes sizes depend on the plot area size, so they must be displayed already

I don't think that is the case, it depends on the getBBox(), which doesn't depends on the plot area size right, maybe you are confusing it with the Axis.width property (which does depend on the plot area size, and I was confused about that :))

[martinRenou]

I'm rebasing your PR and testing it

[martinRenou]

@maartenbreddels the problem I see with the approach is that the plot needs to be displayed already before being able to solve the constraints.

This results in the plot being rendered a first time not properly, then we compute the constraints, then we display with the resulting solution.

This can be seen in your screencast #1046 (comment), the plot gets displayed a first time without the axes, then the axes pops up (though it seems to happen quite fast on your laptop).

I can reproduce this behavior more clearly locally:

plot.mp4

[martinRenou]

@maartenbreddels as we discussed, I refactored the rendering logic a bit:

• Create the scales and axes and call updateDecorators once, all this before solving the sizing with kiwi
• Prevent relayout calls during the first render
• Do the first render only when attached

Plus a couple of fixes.

I'm willing to add some Galata tests for this.

[maartenbreddels]

This will improve bqplot performance overall right?

[martinRenou]

I guess so. There was one extra relayout call that was not needed.

[martinRenou]

Update galata references

[martinRenou]

Update galata references