freenode/#clim - IRC Chatlog
Search
4:38:18
loke
I've been trying to find out why I got redraw problems in certain circumstances with my optimised scroll feature.
4:38:46
loke
Anyway, I figured it out, and I believe the issue is caused by a logic problem in the CLIM code itself.
4:39:43
loke
And after I found the root cause, I was able to create a test case that illustrates the issue even without any special scroll optimisation.
4:40:44
loke
I need a subject matter expert to tell me if I am right about the issue, and if so, tell me what the expected behaviour is. Or... perhaps there really isn't anything that can be done about it, it's just the way CLIM is.
4:55:53
loke
Imagine a normal application pane, and you write to it using FORMAT, with each line terminated by a TERPRI (or a write of a newline character, it all ends up in the same function that terminates a line anyway)
4:57:26
loke
What the line-termination code does is to increate the cursor Y-position and set the X-position to 0. It then checks if the new Y-position is created than the height of the pane, and if it is it recomputes a new pane size and scrolls the content up (by using MOVE-SHEET)
4:58:11
loke
However... Imagine if this call to TERPRI was done inside of a WITH-OUTPUT-TO-OUTPUT-RECORD...
4:58:44
loke
What happens now is that the pane will be resized, scrolling will happen, but nothing is drawn!
5:01:15
loke
One place where this happens all the time (but is generally invisible) is when drawing stuff using FORMATTING-TABLE. It captures all its output in output records before rendering, but the scrolling happens during initial draw.
5:03:07
loke
Remember above where I said that MOVE-SHEET is called? It turns out that MOVE-SHEET triggers a repaint. This repaint happens at a point when there actually isn't anything to draw yet. But... The repaint called by MOVE-SHEET only queues a repaint, the actual repaint happens later. Actually, it happens _after_ the formatting-table has been drawn.
5:04:02
loke
Now, the only reason this works most of the time is because of two somewhat incidental reasons:
5:04:35
loke
1) In almost all cases, the output record ends up being drawn at roughly the same place as where it was generated, so the pane resize turns out to be mostly correct
5:05:03
loke
2) The redraw triggered by MOVE-SHEET repaints the entire pane, not just the newly exposed area.
5:19:42
jackdaniel
please make an issue on github with this description, illustratory screenshot and code to reproduce
5:20:22
jackdaniel
irc is too ephemeral for such entry ;) that said Ill look at it later, Im busy atm
5:26:22
loke
Just my thought, but I believe the responsibility to handle the pane reiszing should not be when TERPRI is called, but rather at some other point (perhaps when the output record is added to the stream)
8:20:01
littlelisper
the display fn is called everytime there is a change in the data structure. but the change is only checked after a command is finished. for now i use redisplay-frame-pane
8:21:17
littlelisper
but the application freezes until the loop is finished. i dont want that. i am a novice. any help will be appreciated
8:32:33
jackdaniel
I've replied to email, though more polite would be staying here and waiting for an answer…