Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Maximum canvas% scroll-range of 1,000,000 pixels? #295

Open
jjsimpso opened this issue Apr 2, 2023 · 4 comments
Open

Maximum canvas% scroll-range of 1,000,000 pixels? #295

jjsimpso opened this issue Apr 2, 2023 · 4 comments

Comments

@jjsimpso
Copy link
Contributor

jjsimpso commented Apr 2, 2023

I see the following contract violation in my program when the scroll range exceeds 1,000,000. I'm providing pixels as the units to the set-scroll-range function. Assuming using pixels is correct here, I propose 1,000,000 pixels is too small for a maximum range since I have run into the limit displaying a text file with about 30,000 lines.

set-scroll-range in canvas%: contract violation
expected: (integer-in 0 1000000)
given: 1130504.0
Context (plain; to see better errortrace context, re-run with C-u prefix):
/usr/local/racket/share/pkgs/gui-lib/mred/private/lock.rkt:43:38
/usr/local/racket/collects/ffi/unsafe/atomic.rkt:73:13
/home/jonathan/git/molasses/src/test/newcanvas.rkt:265:4 update-scrollbars
/usr/local/racket/collects/racket/private/more-scheme.rkt:148:2 call-with-break-parameterization
/usr/local/racket/share/pkgs/gui-lib/mred/private/lock.rkt:43:38
/usr/local/racket/collects/ffi/unsafe/atomic.rkt:73:13
/usr/local/racket/share/pkgs/gui-lib/mred/private/wx/common/queue.rkt:435:6
/usr/local/racket/share/pkgs/gui-lib/mred/private/wx/common/queue.rkt:460:2 yield

@spdegabrielle
Copy link
Sponsor Member

I’m guessing this is a significant piece of work? You would need to build tests in addition to making the change. 30,000 seems very large for a single file.
Text editor applications normally implement their own strategies to manage large files, as most gui toolkits do not offer this as part of core functionality.

I believe pages is how emacs handles large files. I found this http://www.finseth.com/craft/#c4

@jjsimpso
Copy link
Contributor Author

jjsimpso commented Apr 3, 2023

I expect that the issue here is just an arbitrary limit added in the contract for set-scroll-range, but I could be wrong if the limit is due to an underlying limit in the GUI toolkit. The contract in question is checking for dimension-integer?.

My app is actually using a subclass of canvas% which is handling the data, but my canvas does need a way to communicate the size of the virtual canvas to the scroll bar widgets provided by canvas%.

@jryans
Copy link
Member

jryans commented Apr 3, 2023

Here's a commit from 2013 when these limits were last tweaked: 4ad4792

The commit message there suggests canvases larger than 32k in a dimension may struggle on some platforms.

@jjsimpso
Copy link
Contributor Author

jjsimpso commented Apr 3, 2023

@jryans, thanks for pointing me to that commit. One thing I noticed is that the range for most things was increased, but the range for scroll bars was actually decreased from 10,000,000 to GAUGE_MAX, which is only 1,000,000.

In my case the scroll range is just an abstract value representing the size of a virtual canvas. It isn't tied to anything in the underlying GUI toolkit, so I don't see any reason to limit it.

I suppose I do have some other options, but they have drawbacks/complications.

  1. I could change my scroll range units to something else besides pixels, like lines. This would require a bit of work on my end, but perhaps it is worth doing anyway. I haven't investigated yet.

  2. Potentially I could override the set-scroll-range method in canvas%, but since this is implemented in terms of the wx layer below that, I may have to re-implement all of the scroll bar functions in my canvas.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants