Disable outer window scrollbars in X

[ecraven]

Would it be useful if it were possible to disable the outermost scrollbars (lower and right border) that scroll the entire X window completely? As most displays have a resolution close to two megapixels anyway, it seems like they are not necessary in all cases any longer.
This could be a startup switch for maiko, which tells it to just not draw them at all.

[masinter]

The entire window initialization is an area that needs work. I'm hoping @waywardmonkeys will succeed in his project that would remove dependence on X. If not, the scroll bars, window size adjustments, pixel doubling, bigger screens all are open topics.

[nbriggs]

BTW -- Bruce's change should provide an alternative display method, but it brings a dependence on "free" software that has no support and no guaranteed future. I wouldn't abandon X without a more certain future.

[nbriggs]

The X window size (-g[eometry]) is independent of the size of the screen that Lisp is imaging on. If the Lisp screen is smaller than the X window size then the scroll bars could be eliminated. However, you'll lose the lower corner of the screen to the window manager if there's no scroll bar or window border. It's already an annoyance that you can't get at the "bit gravity" selector in the bottom right corner because of the resize handle (which obscures 15x15 pixels).

[nbriggs]

The lisp display size can be adjusted when you exit Lisp and restart. Doesn't work so well to try to do it while it's running. The scroll bar code is really pretty ugly. A full size display doesn't fit on my 1440x900 (or so) laptop, so I'm always going to have to specify the Lisp screen size and the X window size. I can prune the scroll bars down from 18 bits wide to something smaller, and reduce the border size from 2 to 1, but...

[ecraven]

ok, changing pointer size sounds like a huge pain, even TEDIT files include READPTR calls, so all of them might have to be regenerated as well :-/
So there are no immediate plans to increase the maximum framebuffer size?

[masinter]

#154 screen size and resolution

[masinter]

I thought the display limit was 2^21 width x height, with width rounded up to multiple of 16.
2^21 = 2097152 bits. 286144 bytes. on my display (1920+1920)x1080 the tallest h is ~1000 (= 1080 minus 80 for title bar at top and scroll bar and windows task bar at bottom) . That means 2096x1000 display.

On a raspberry pi with a 4k display, it automatically turns on pixel doubling.

[nbriggs]

Yes, I forgot to mention that you do need to round the width of the Lisp screen to a multiple of 16 bits in width before you add the 22 for scroll bars.

[masinter]

@nbriggs

It's currently set up to handle at most 256 MB of memory, and every bit you add to the display means that much less for the rest of the system.

the limitation on the screen bitmap is because of address space limits? How can that be true? The address space is 2^28*2 (bytes, it was 2^24*2 bytes with 8 bit CDR-code?

It used to be limited to 32 MB, but it was expanded to 64 and then 256 MB. The last paid developers increased the pointer size from 16-bits to 24-bits at some point (pointers are offsets within the Lisp VM), and the cell size was increased from 16-bits to 32-bits (mostly). Atoms had to get bigger so they could contain all the pointers they needed.

I'm missing something here. I'm baffled by 4-byte atoms, it makes the code bigger and is unneeded until you compile code after your 2^24th symbol.

[nbriggs]

I was saying that we appear to have a current VM size of maximum 256 MB -- I'm not sure what the math is that generates that, but I believe it to be true. Given that limit, adding pages to the display means removing pages from the rest of the system.

You're right that in "BIGVM" mode, the cons cells are 4-bit cdr code, 28-bit car pointer (and I'm not sure if there's meaning to the 1 or 2 low order bits in the car.

But, the display is a BITMAP object, and I tracked down the maximum bitmap size limit, in LLDISPLAY --

       (\MaxBitMapWidth 65535)
       (\MaxBitMapHeight 65535)
       (\MaxBitMapWords 131066))

(those are 16-bit words) -- I'm not sure where those derive from, but it sure looks like a 16-bit field somewhere, or it's MAX.SMALLP.

[ecraven]

what is \MaxBitMapWords? The maximum total size of a bitmap in 16 bit words?

[ecraven]

Indeed that's what it seems to be:

(COND
  ((IGREATERP (SETQ RW (ITIMES RW HEIGHT)) \MaxBitMapWords)
   (ERROR (ITIMES WIDTH HEIGHT BITSPERPIXEL) "bits in BITMAP -- too big"))
  (T (\ALLOCBLOCK (FOLDHI RW WORDSPERCELL)
                  NIL
                  (AND (NULL WINDFLG) 0))))```

[masinter]

could this be a limit that isn't relevant in Maiko?

[ecraven]

(BITMAPCREATE 65535 31 1) works fine, but (BITMAPCREATE 65535 32 1) fails. so the limit is somewhere in between ;)
is there a trick to see the value of \MaxBitMapWords in the running system? If I just type it into an Exec, I get UNBOUND