Skip to content

[ENHANCEMENT] ScrollView Rewrite #990

Open

Description

@Mystin

Describe the current behavior of what you're trying to improve. If your enhancement request related to a problem, please also describe the problem.

The current ScrollView class was not created carefully and has a number of problems that interfere with the experience of using both the puzzle solver and creator. Zooming relies on controlling a JSlider in the ZoomWidget which can only store integer values, making interactions feel choppy and needing to constantly jump between different scrollbars/sliders to make fine adjustments. This is particularly noticeable when antialiasing is enabled (which is notably absent from the board view currently) revealing clipping errors. There also is a particularly resilient bug resulting from this which causes the zoom scale to get "stuck" at a particular value due to double -> integer truncation. Additionally, every puzzle and the tree have their own ScrollView subclasses which are bulky and unnecessary as opposed to simply making a canvas and controller for every view type.

Describe the improvement you'd like

Puzzles' and the Tree's ScrollViews should be extracted to simple canvases which can be plugged into a standard ZoomPane class such that the board view in the puzzle solver can remain the same instance whilst several different puzzle types are injected as its view and removed. This ZoomPanel should offer double-precision view positioning and scaling, draw the view with antialiasing, and possibly provide some way of raising information to the user with tooltips or even a JLayeredPane to display popups. Additionally, boards are currently drawn on a per-element basis such that borders are left up to each element to draw their own portion of within a strict clipping bound, whereas the Tree takes care to lay out how much space it will require by giving each element as much space as it needs. The Tree's approach could benefit the rendering of puzzles like sudoku which need additional space for the thicker border lines indicating the larger 3x3 regions or puzzles like towers which needs to draw indicators which are not strictly puzzle elements onto the game board outside of any other element's clipping region.

Describe alternatives you've considered

Using double-precision in Swing architecture is a large departure from anything currently in the application, and will mean that it is insufficient to simply modify the existing ScrollView class or to have views be drawn onto JPanels. I have thoroughly eliminated the viability of these approaches in previous attempts to eliminate the bugs mentioned above and have come to the conclusion that an exhaustive restructure is the only option to produce satisfactory results.

Additional Context

I am currently working on such a rewrite. Please contact me before trying to mess with and ScrollView behavior as it will be replaced as soon as my rewrite is complete.

Activity

  1. self-assigned this
    on Jul 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

enhancementImprovement to existing feature

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions