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

From: Matthew Flatt (mflatt at cs.utah.edu)
Date: Sat Sep 18 21:46:19 EDT 2010

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.



Posted on the users mailing list.