T.R | Title | User | Personal Name | Date | Lines |
---|
2058.1 | | LESLIE::LESLIE | Think laterally. Move forward. | Wed Jan 17 1990 10:47 | 3 |
| As one identifiable instance, I redirect OPCOM messages to the SM
message window. REPLY/ENABLE'ing a window causes an ordinary display
message, REPLY/DISABLE gives the 'jump' characteristic.
|
2058.2 | Strange scrolling... | NITMOI::PESENTI | Only messages can be dragged | Wed Jan 17 1990 11:33 | 5 |
| I have noticed this also. I assumed it was just strange scrolling behavior.
It appears that when the message area gets close to full, a jump scroll happens
to bring it to roughly half full. It never bothered me, since I don't pay
much attention to what shows up in that window. By the way SPOOL COPY NL: NL:
will cause it to happen every other time on my system.
|
2058.3 | Session Manager optimization | DECWIN::KLEIN | | Wed Jan 17 1990 14:19 | 10 |
| I believe that this is an effect of the session manager trying to avoid
certain particularly inefficient SText widget calls. Past history does
not roll out at the same rate as new information. It is batched
and periodically removed from the beginning of the SText buffer.
It is not a bug in the session manager but could be considered a workaround
for a performance problem in the SText widget.
Right Karen?
-steve-
|
2058.4 | | MOVIES::LESLIE | Think laterally. Move Forward. (Andy, CSSE/VMS, NEW B1/2-5) | Thu Jan 18 1990 03:04 | 2 |
| Sounds like we're fixing a symptom, not the problem. Is the SText bug
QAR'd? Or is the problem inherent in X?
|
2058.5 | huh? | TRNSAM::HOLT | Robert Holt ISV Atelier West | Tue Jan 23 1990 12:10 | 6 |
|
re.3
...what particularly inefficient SText widget calls..?
and are they inefficient on Ultrix _and_ VMS..?
|
2058.6 | String shuffling | DECWIN::KLEIN | | Tue Jan 23 1990 14:18 | 10 |
| >> ...what particularly inefficient SText widget calls..?
When replacing portions of the SText contents with another substring of
a different length, the SText widget does not know how to scroll partial
window contents to "open up" a region for the new text. In particular,
removing a line from the beginning of the buffer and adding a line to
the end triggers a complete repaint of the window, not an XCopyArea
and some smart shuffling of window contents.
-steve-
|