Window repainting

[pamoroso]

I'm studying the window repainting demo of the Interlisp course notes by @fghalasz and I have a few questions.

The program, which prints a list of strings to a window, works well when the width of the longest string is shorter than the window width:

However, a narrower window wraps lines because stream output functions wrap text at the right margin rather than cropping:

which also causes screen corruption when scrolling:

I can't find an obvious way to make stream functions crop rather than wrap, so what is the idiomatic approach for repainting windows narrower than the output? Setting a minimum window width as large as the output? The windows of some Interlisp programs do crop the output.

Another question. Function MakeStringWindow sets the width of the extent to the width of the REGION property of the window, which may result in part of the output overlapping the window border. Wouldn't the WIDTH property be more appropriate as it constrains to the inner area?

Finally, in function StringWindowRepaintFn what is the purpose of the calls to ADD1 when calculating FirstLine and LastLine? Accounting for lines partially displayed at the top and bottom of the window?

[nbriggs]

It wraps at the right margin, so (DSPRIGHTMARGIN MAX.SMALLP stream-or-window) - on the assumption that your strings are not going to extend to 64K bits wide (or MAX.FIXP if you're paranoid). It'll clip at the interior border of the window (2 pixels in from the black border). By the way, you can easily look at what's going on with the (interior) bits in a window by passing the window to EDITBM, or if you're looking at border interactions, snap a piece of the the screen covering the border and contents of the window and look at that -- (EDITBM (SNAPW))

[pamoroso]

Thanks, I added the call (DSPRIGHTMARGIN MAX.SMALLP SW) to MakeStringWindow and repainting no longer wraps text:

Horizontal scrolling still causes artifacts, likely because the original program doesn't handle reshaping:

I set RESHAPEFN to the following function but scrolling after a reshape produces the artifacts in the screenshots:

(LAMBDA (Window BM Region PrevRegion)
       (DSPFILL NIL NIL NIL Window)
       (REDISPLAYW Window))

[pamoroso]

My RESHAPEFN is very short because the REPAINTFN takes care of setting the extent of the output which doesn't change when the program runs, yet reshaping the window leads to screen corruption.

[nbriggs]

I'd suggest using TRACE on your reshape and repaint functions and see how the window system is calling it, and whether that makes sense for what you're expecting your code to do.

[pamoroso]

The problem is I don't know what to expect. 😄 I traced the functions but no obvious clues jumped at me. I have a basic grasp of repainting but I'm still learning reshaping.

Along with reading the documentation I experiment and study how Frank's and other programs handle reshaping. That code usually clears the window, sets the extent, sets the margins, and repaints. But the repaint function of Frank's program already takes care of that.

Here is my code so far: STRINGWINDOW.TXT

[pamoroso]

I traced the repaint and reshape functions to gather clues. First, I launched the program:

Next, I reshaped the window:

Finally, I scrolled first horizontally:

and then vertically, which resulted in screen corruption:

One thing to notice is the reshape function is passed a region with the same size of the previous repaint region but offset by a few pixels.

[nbriggs]

Have you looked at the IRM documentation for SCROLLBYREPAINTFN and RESHAPEBYREPAINTFN ? This documentation should (... crosses fingers...) tell you enough about what your REPAINTFN needs to do in order to reconstruct the window contents for scrolling and reshaping.

[pamoroso]

I'm rereading the documentation of the repaint and scroll functions until something clicks. But I've noticed an interesting remark in the IRM description of REPAINTFN:

The REPAINTFNs are called with two arguments: the window and the region in the coordinates of the window’s display stream of the area that should be repainted.

It's not clear to me whether the region refers only to the exposed or damaged portion of the window or the full inner area of the window.

[pamoroso]

The documentation of SCROLLBYREPAINTFN says:

This function, when used as a SCROLLFN, BITBLTs the bits that will remain visible after the scroll to their new location, fills the newly exposed area with texture, adjusts the window’s coordinates and then calls the window’s REPAINTFN on the newly exposed region.

So REPAINTFN is passed only the newly exposed portion of the window, not the full interior area. Since Frank's code doesn't handle horizontal scrolling I tried calling DSPCLEOL to clear a full line before printing the corresponding text, but this doesn't help.

[nbriggs]

I think it says to use DSPFILL and that the clipping region has been appropriately set beforehand (and points out that code should NOT call CLEARW because that resets more than you want at this time). This is where interactive debugging by BREAKing your repaintfn and/or putting HELPs in the code is handy - then you can poke away at the window and its bitmap, and locate exactly the region(s) it's passing you. Making reproducible test cases by reshaping or scrolling the window programmatically (instead of manipulating it with the mouse) can ease the process.

[nbriggs]

Looking through the sources & library & lispusers... for uses of RESHAPEBYREPAINTFN, the TABLEBROWSER code does what I think you're trying to do -- have a look at library/TABLEBROWSER for the repaint/reshape functions and compare what they do to the IRM documentation.

[pamoroso]

Thanks for the leads, I'll study them. I'm also checking out a regexp parser design tool whose repaint and reshape functions are particularly clear even if the program mostly outputs graphics rather than text.