[racket] Limits of init-auto-scrollbars in canvas%

Thanks, Matthew, for your in-depth reply! 

If there is a 16-bit limit to some drawing operations,
this will affect the application only if using auto scrollbars.
When using manual scrollbars, everything related to drawing
stays within the coordinates of the visible area of the
canvas. So maybe it's an option to allow at least manual
scrollbars to scroll to a maximum of 2^31-1 (assuming there
is an int value used for that in wxwidgets)?

I've checked the new implementation and could successfully
scroll to a bottom position of 1000000 with auto scrollbars,
but this still feels somewhat limited. Using the default font
this is enough room for ca. 55000 lines of text, which is not
really that much. With manual scrollbars, this could translate
to 1000000 lines if each scrollbar step equals one line. That
would be enough for my purposes, but I will need to wait until
manual scrollbars are implemented in the new version...


On Sat, 18 Sep 2010 19:46 -0600, "Matthew Flatt" <mflatt at cs.utah.edu>
wrote:
> At Sat, 18 Sep 2010 20:56:54 +0000 (UTC), Martin Dirichs wrote:
> > In the docs for canvas%
> > 
> > http://docs.racket-lang.org/gui/canvas_.html
> > 
> > the limits for function init-auto-scrollbars
> > are given as
> > 
> >   horiz-pixels : (or/c (integer-in 1 1000000000) false/c)
> >   vert-pixels : (or/c (integer-in 1 1000000000) false/c)
> 
> I must have gotten this wrong as part of the v4.0 document conversion.
> Maybe I optimistically raised the limit, intending to follow through in
> the implementation, but I didn't follow through when I remembered the
> problem with drawing coordinates. I'll fix the docs.
> 
> The problem with raising the limit is that drawing is not well defined
> for combinations of positions and offsets greater than 16k or so. The
> 16k boundary is related to 16-bit numbers in the some of the drawing
> APIs that we built on.
> 
> > I would much prefer the limits
> > given in the documentation, as a maximum virtual height
> > for a canvas of 10000 is severely limiting its usefulness
> > (at least for me, I am trying to display large tables
> > with it).
> 
> FWIW, auto-scrolled canvases are mainly useful for cases where you want
> to simply draw the whole virtual space and let the canvas take care of
> scrolling and clipping. That works well for moderately large virtual
> areas. For an application with a virtual area larger than 10000 in a
> dimension, then it's probably just as well to use manual scrollbars.
> Since you end up scaling the scroll position yourself, that gives you a
> somewhat larger effective scrolling range.
> 
> 
> Looking forward, I have good news and bad news.
> 
> The good news is that we are rebuilding the drawing and GUI layers, and
> the new drawing API is in terms of floating-point numbers, so the
> conservative 16k limit on drawing coordinates will disappear. Scroll
> positions in the underlying GUI widget are sometimes stored as 32-bit
> floating point values, so the limit cannot be as high as 1000000000,
> but it can be 1000000.
> 
> The bad news is that the new drawing and GUI implementation won't be
> production quality for months, at least.
> 
> The in-between news is that you can try the new version if you'd like,
> and it may work well enough. The source currently lives here:
> 
>  http://github.com/mflatt/gr2
> 
> I pushed a change there to allow scroll ranges up to 1000000.
> 
>