Open bric3 opened 1 year ago
Actually the fix introduced in #149 to fix #46 doesn't work properly and introduce flickering when the flamegraph is not zoomed.
The issue is due to the ScrollPaneLayout
that is checking before ViewPortLayout
if an horizontal bar is needed. Since the container is shrinking the width is getting narrower than the "out of date" canvas.
Note that layout is called on the ScrollPane first then on the view port.
To fix that there's two options (guassing from the ScrollPaneLayout
code:
boolean viewTracksViewportWidth = false;
...
if (!isEmpty && view instanceof Scrollable) {
sv = (Scrollable)view;
viewTracksViewportWidth = sv.getScrollableTracksViewportWidth();
viewTracksViewportHeight = sv.getScrollableTracksViewportHeight();
}
else {
...
if (hsbPolicy == HORIZONTAL_SCROLLBAR_ALWAYS) {
hsbNeeded = true;
}
else if (hsbPolicy == HORIZONTAL_SCROLLBAR_NEVER) {
hsbNeeded = false;
}
else { // hsbPolicy == HORIZONTAL_SCROLLBAR_AS_NEEDED
hsbNeeded = !viewTracksViewportWidth && (viewPrefSize.width > extentSize.width);
}
Scrollable
interface as in #92 and to toggle viewTracksViewportWidth
.setHorizontalScrollBarPolicy
.Either way the code needs to know when it's zoomed or not. The current approach is a bit hacky as it requires to deal with boundaries (width / height) to trigger the zoom. This approach is more and more problematic especially when it comes to layout. Even #149 had some issues with scale factor stability.
Introducing a proper Zoom or scale model will be likely helping. Doing so maybe an opportunity to revisit #92.
Using the bounds as a mean to zoom causes some complications. It was introduced to animate the zoom. But the various computation makes the factor not stable.
See #46
Using a
ZoomModel
, the code can control the actual zoom factor, the model should be able to perform the necessary checks (scale to low, too high).