peter@ficc.ferranti.com (Peter da Silva) (08/03/90)
In article <1990Aug3.002317.12535@pcrat.uucp> rick@pcrat.UUCP (Rick Richardson) writes: > In some cases, it simply must be done. Anything that wants to do > graphics is going to have to go directly to the screen. That's a different matter, though a less CPU-expensive standard than X for using this resource would be desirable, I don't see one forthcoming. But where acceptable standards exist (termcap, terminfo) they must be used. > In other cases, direct screen writes are of tremendous value. > People find it convenient to lean on the arrow keys to move > around, and expect to stop on a dime when they see where they > want to be. There are many programs that provide this facility over even slow serial ports, by either doing heuristics to determine when to do updates, or by simply abandoning the current update of the screen image so long as input is pending. Another point to consider is that this sort of interaction is, while simple to understand and implement, not always the most convenient for the average user. The time spent making this fast could have been better spent implementing more powerful tools such as incremental searches. Optimisation is not free. Gratuitous optimisation can be translated directly into missing features or later release dates. I consider optimising a program for the special case of users logged in directly at the console, and not using X, to be gratuitous. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` <peter@ficc.ferranti.com>
karl@ficc.ferranti.com (Karl Lehenbauer) (08/10/90)
In article <R4:49J@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >Optimisation is not free. Gratuitous optimisation can be translated directly >into missing features or later release dates. ...and more bugs. ...and performance optimization without thoughtful performance testing is usually misdirected and, as above, at best does nothing and at worse delays/worsens the product and drives up life-cycle costs. -- -- uunet!ficc!karl uunet!sugar!karl
rick@pcrat.uucp (Rick Richardson) (08/13/90)
In article <R4:49J@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >> In other cases, direct screen writes are of tremendous value. >> People find it convenient to lean on the arrow keys to move >> around, and expect to stop on a dime when they see where they >> want to be. >There are many programs that provide this facility over even slow serial >ports, by either doing heuristics to determine when to do updates, or by >simply abandoning the current update of the screen image so long as input >is pending. This is true (and where I got on this boat by pointing out that ETI implements jump-scroll for you). The point is that jump scroll doesn't allow you to lean on arrow keys. Jump scroll, no matter how you implement it, is visually annoying. You cannot train your eyes on just one spot on the screen in order to scan for the context you are looking for. When it comes to human engineering, there is no substitute for a fast scroll capability. Mere mortal users expect it, and it is one of the first 'features' they look for. As my little test program shows, this is not gratuitous optimization. It is clearly a desirable optimization. The optimization allows region scrolling to keep up with the repeat rate from the keyboard (typically 20-30 per second) in a visually pleasing manner. Pipe dreams like 'it should be in the device driver' don't help todays users. Wizbang search features aren't a substitute (though needed) since it is most natural to use the eye as a pattern recognizer. The Norton *implementation* may have been buggy in that there was no way to disable it (or perhaps it should have defaulted 'off', with a manner to enable it). -Rick -- Rick Richardson | Looking for FAX software for UNIX/386 ??? Ask About: |Mention PC Research,Inc.| FaxiX - UNIX Facsimile System (tm) |FAX# for uunet!pcrat!rick| FaxJet - HP LJ PCL to FAX (Send WP,Word,Pagemaker...)|Sample (201) 389-8963 | JetRoff - troff postprocessor for HP LaserJet and FAX|Output
wilber@aludra.usc.edu (John Wilber) (08/15/90)
In article <1990Aug13.115811.4371@pcrat.uucp> rick@pcrat.UUCP (Rick Richardson) writes: >The Norton *implementation* may have been buggy in that there was >no way to disable it (or perhaps it should have defaulted 'off', >with a manner to enable it). Actually, it is pretty easy to disable the fast screen features of Norton Utilities. Wasn't the original complaint that when using the icelandic code page you couldn't use the fast method and had to resort to curses? I have heard that the icelandic problem has been solved anyway.