Hi and thanks for the answer,
I appreciate that recources are always limited and that my proposal might be a non-trivial effort.
Maybe I should have posted here before using GitHub, because I really am interested in how many other users are affected by this. In my application (10 plots in a grid on one tab, several other tabs with tables and settings) this may be the next game-changer after webgl had been resolved (thanks again for that!). The lag feels like almost half a second. But if the user does not pan around wildly, it is of course no issue at all.
With regard to your advice:
setting a ‘min_border_left’ does not solve the issue at all. The y_axis itself does not move anymore, but the lag remains the same. Now instead the axis_label moves, because it tries to be as close to the axis as possible. But even disabling the axis_label does not change the lag.
setting ‘p.yaxis.major_label_orientation = “vertical”’ does completely resolve the issue. But I need some user feedback to see if it is a practical solution (with regard to readability). A nice side effect is that plots can now stay quadratic, even with long numbers on the ticks
All in all: Issue resolved for now. Still curious how many other are affected.
Am Donnerstag, 12. April 2018 20:15:16 UTC+2 schrieb Bryan Van de ven:
It appears at some point that someone updated the example to rotate the y-axis labels. This is one quick way to improve the situation. Another idea would be to specify a larger min_border (or min_border_left) so that the axis gutter does not resize at all when the labels get bigger. If there has not been a response it is because:
there are simple and immediately available reasonable workarounds
the proposed idea would be a non-trivial effort involving low level code
there are many other much higher current priorities
Certainly if a technical solution is important enough to you, we’d be happy to consider a PR.
On Apr 12, 2018, at 01:59, Joris Nettelstroth [email protected] wrote:
I have posted the following issue on GitHub on Feb. 15, but it does not seem to have gained any attention.
Therefore I’d like get some discussion going in this group
Are there others who experience the same problem?
ALL software version info (bokeh, python, notebook, OS, browser, any other relevant packages)
Official Bokeh examples viewed in Edge and Chrome (Edge’s poor performance is best for worst-case example) in Windows 10
Description of expected behavior and the observed behavior
If you zoom or pan a figure it often happens that the axis range changes in such a way that the axis needs to be redrawn. For example when the y_range [9, 99] changes to [10, 100] the extra digit requires more space and the axis is moved to the right. When such a redraw occurs while you keep panning, a lag happens. In single plots this is hardly noticeable, but in a more complicated grid with lots of figures it becomes annoying.
I would suggest the following:
Only adapt the location of the axis once the user ends the panning (i.e. after the mouse click is released). This way the user will not “feel” the lag, because there is no interaction while the redraw happens.
Complete, minimal, self-contained example code that reproduces the issue
Zoom out and pan to the range [-10000, -5000]. Then pan up and down, such that -10.000 appears and disappears at the lower end. You can see how the y-axis is moved left and right, and you will feel a lag.
You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/bec4d7d3-bacb-42a6-830c-4a9cc9443174%40continuum.io.
For more options, visit https://groups.google.com/a/continuum.io/d/optout.