[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference bulova::decw_jan-89_to_nov-90

Title:	DECWINDOWS 26-JAN-89 to 29-NOV-90
Notice:	See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit
Moderator:	STAR::VATNE

Created:	Mon Oct 30 1989
Last Modified:	Mon Dec 31 1990
Last Successful Update:	Fri Jun 06 1997
Number of topics:	3726
Total number of notes:	19516

3257.0. "DECterm display of large file is erratic" by CSC32::IRONS () Fri Aug 24 1990 11:11

    I am inquiring about a screen behavior that a customer reported.
    They have a VS3100 with 16mb of memory and a VR160.  When using
    DECterm, they set the screen length longer than than the number
    of lines that the monitor is capable of displaying at one time.  That
    is, if the screen can display 54 lines and they do a " $SET 
    TERM/PAGE=66", then scroll through a large file.  The new information
    displayed onto the screen becomes very erratic or "jumpy".
    Are we exceeding what the hardware can display to the screen or 
    what some buffer can hold or is this a bug?
    
    GMI

T.R	Title	User	Personal Name	Date	Lines
3257.1		CVG::PETTENGILL	mulp	`Sat Aug 25 1990 00:01`	8
	That's not a bug, that's a feature.... It would be possible to eliminate this behaviour but that would slow down output significantly with little benefit. You can make the behaviour consistent by setting batch scrolling to a large value, (99 lines), now it will do it all the time and the performance will be faster.
3257.2		STAR::KLEINSORGE	Fred Kleinsorge, VMS Development	`Mon Aug 27 1990 18:56`	8
	Huh? You'll have to explain that explanation. Why should erratic behaviour be considered a feature? Batch scrolling at 90 lines is not a particularly useful setting and will actually cause data to be "paged" when sent to the emulator fast enough (perhaps never even displayed when set that large). Making a terminal larger than the screen shouldn't cause jerky behaviour. It doesn't make sense and would sound like a bug to me.
3257.3	The feature is improved performace against some minor cosmetic defects	CVG::PETTENGILL	mulp	`Tue Aug 28 1990 00:36`	19
	You would find a non-batch refresh version of DECterm too slow as the only way to ensure that scrolling the display up a scanline or a text line and then refreshing exposed areas synchronously would be to wait a round trip time to ensure that any required exposures had been serviced by the DECterm process. Even when the DECterm wasn't occluded this would be necessary since you can't readily determine when the window is occluded, so consequently this means that the performance would always be limited by the round trip time. Creating a DECterm that doesn't fit on the screen is just another case where part of the window is occluded. While one can argue that this is a special case that could be handled, my question is `why?' The effect is purely cosmetic, although some might find it annoying, but the real bugs and missing features in DECterm are much more in need of attention and it would certainly not make many people happy if DECterm was slower or took more CPU and network resources to run. In other words, it is a feature: CPU and network resources were conserved by trading off some minor cosmetic defects in the scrolling for some unusual cases.
3257.4		STAR::KLEINSORGE	Fred Kleinsorge, VMS Development	`Tue Aug 28 1990 18:16`	9
	In other words: because the engineers cannot keep up with the backlog of bugs, that a minor "bug" is being called a "optimization". Yes, I agree that given the lengthy list of needed features in DECterm, that I wouldn't put too much effort into this minor annoyance. _Fred