Celestial Software

Has anyone else seen a problem where the "top" of characters is cut off when the character is typed?

For example, the dot of an i or the top half of the vertical line in a d or b.

I'm using version 3.0 with the following settings:

Connection = SSH2
TERM = VT100
Translation = ISO-8859-1
Colors = ANSI Defaults
Client OS = Win2k
Server OS = RH 7.2, 8.0

The character becomes "complete" if I hit Enter or sometimes if I backspace and re-type it. It doesn't happen constantly, but it's not rare either.

[ February 18, 2004, 01:52 PM: Message edited by: Brian T. Pence ]

Robert,

What happens when you just hold down the 'i' key and create a string of them quickly? Do some get cut off and others don't?

Yes, some of the i's are fine and others are "cut off." However, when the line wraps (I have the window set to 80 cols) all of the "cut off" i's become complete.

I *have* seen this, but I thought I'd fixed it. It's a bit of a difficult problem to identify, though, as it's very unpredictable as to where and when it will happen. It is at least OS specific, and possibly OS/Video card specific.

Can you give me some more info about your hardware specifices?

Also, if anyone else reads this and has this problem, please post your hardware/software information here!

What I need:
PC type/model number
Video card model
Video card driver version
OS Version (and SP number)
Amount of memory
AbsoluteTelnet version

PC Type: x86 based PC
PC Model: Kenetic (something or other....it's a generic clone)
Processor: x86 Family 6 Model 8 Stepping 6 GenuineIntel ~871 Mhz
Video Card Model: ATI Technologies Inc. RAGE XL AGP 2X
Video Card Driver: atidrab.dll
Driver Version: 5.00.2179.1
OS Name: Microsoft Windows 2000 Professional
OS Version: 5.0.2195 Service Pack 4 Build 2195
Total Physical Memory: 261,596 KB
Absolute Telnet Version: 3.00

It might be worth noting that this problem did not occur with previous versions of Absolute Telnet, 2.13 being the last one I used. No hardware changes have been made to the system since switching from 2.13 to 3.00.

Right. Nothing may have changed in your system, but changes did occur in AbsoluteTelnet. Specifically, the drawing mechanisms have changed to eliminate the flicker on screen when things change on the screen quickly. Now, the program uses double-buffering to paint to an area of memory and then update the screen in one shot.

Unfortunately, this seems to have an unwanted side-effect. I've seen the exact behavior you mention, but I thought I'd fixed it and I can no longer reproduce it myself. That's why knowing more exact information about your system may be helpful.

Tell me something.... If you resize the screen to something very small (under 60 chars wide), do you still have the problem??

I've tried to resize the window to less than 60 chars wide and the problem still occurs.

It's logical that an application change could cause this problem, I just wanted to paint as complete a picture as possible. In a situation like this, any detail might be important.

Do you think combinations of Translation, font type and font size could alleviate the problem?

Or do you think that this is an application wide bug that only occurs with certain systems (OS, hardware, drivers, etc.)?

I've seen it happen in some fonts and not others. It would happen more often at wider screen sizes, regardless of screen height. Larger fonts would make it worse.

I've only seen it happen under Win2k, and I haven't seen it happen now in awhile, which makes it difficult for me to diagnose.

sigh.......

I've got a beta version for you to try. I found an issue that might be related and may affect your problem. Unfortunately, since I can't reproduce your exact problem, I have no way to be sure if this will fix it. Give it a try and let me know...

http://www.celestialsoftware.net/telnet/AbsoluteTelnetBeta.exe

Thanks!

I've tried the beta version, and the problem still exists.

Since I can reproduce the problem easily, is it possible to give me a debug version with extra log messages in it (it's something I've done with my own stuff in the past)? This way I can reproduce the problem and give you the log.

Just a thought....

That would normally be useful, especially when I've never seen the bug before. Unfortunately, I've already seen this one and had a hard enough time troubleshooting it inside my own debugger. As soon as I'd get close enough to identifying the bug, it would go away!!

I have a feeling it's a timing issue between the thread that's receiving data and the main thread that's painting it, but I've had a difficult time proving this. The fact that it no longer happens to me is doubly frustrating

Let me stare at the code a little more tonight and see if I can come up with a test case for you to run to verify some assumptions.

later...

It's been a few weeks, so I was wondering if you'd had any ideas on this one?

I'm now using version 3.11 RC14 and the problem still occurs.

Once again, if you'd like to give me a debug version, I'd be happy to run a few tests for you to try and shed some light on this one.

Robert,

I appreciate your offer to debug. The only problem is that I'm not sure what area to focus the debug on to isolate it. I've had this particular problem before, in the debugger itself. My problem was that as soon as I got close to isolting it, the problem mysteriously went away. And, as with most problems that mysteriously go away, they mysteriously come back as well!

RC14 contained some modifications that were supposed to help. I'm disappointed to hear that they did not. One other thing I'd like you to check is the settings of your graphic card's hardware acceleration.

Check ControlPanel->Display->Settings->Advanced

It should be somewhere under there. If enabled, disable them and try again.

Let me know...

Brian

Robert,

I've got another Beta I'm anxious for you to try! I’m *almost* positive it resolves the problem you are having, however I cannot be sure until you test it.

In version 3.00 and above there were two issues that cropped up that seemed to be related but I could never resolve. On some systems, under rare conditions, AbsoluteTelnet would experience one or both of the following conditions:

1. Seemingly random cut-off characters
2. Excessive (but harmless) page faults when you’re watching the process run in Task Manager.

Now, I always believed the two problems were related, as they both appeared in version 3.00 and at least both seemed to be related to some of the screen drawing code that changed between version 2.13 and version 3. The problem in debugging is that I can not reproduce condition number 1 and condition number 2 was elusive and evaded me for some time.

I happy to announce that I’ve found the cause for condition number 2 and have provided a fix in RC15!!! My belief is, also, that this will take care of condition number 1, so please give it a test and let me know your results!!

http://www.celestialsoftware.net/telnet/AbsoluteTelnetBeta.exe

Thanks for your help!

Brian Pence
Celestial Software

Brian,

I've had to deal with "mystical, magical" problems myself, and they are always the most frustrating to solve.

I'm sorry to say that version 3.11 RC15 did not solve the problem.

However, I've been playing around with the hardware acceleration on my machine and I have some more info.

Originally, my machine was set with full acceleration enabled. With that setting, the problem occurs (but we already knew that). However, if I reduce the acceleration by one notch (it's a Windows slider with 6 hard notches on it) the problem goes away. The details of that notch read that cursor and bitmap accelerations are disabled, but all others are enabled. It continues on to read that the setting is for problems with the mouse pointer and corrupt images.

I need to use the program for a little while longer until I'm convinced that this work-around truly works. But since I could reliably reproduce it before and now cannot, it looks promising.

However, since I can reproduce this issue so easily, I'd be more than happy to keep working on this one with you until it's solved if you think that it's worth it. I know the value of a system where a "mystical, magical" problem can be reproduced at will.

Thanks for the info, Robert!! That give me a little more info to go on. I was *so* hopeful that RC15 would do it!!!

At least knowing that hardware acceleration is involved gives me a direction in which to look.

In the short-term, I'd be interested to know if switching video drivers affects the problem. You're running 5.0.2195.5012, which is not the 'recommended' driver. Can you try 5.00.2179.1 and see if it makes a difference? You can find the driver for the Rage XL here:

www.ati.com/support/products/pc/ragexl/w...exlwin2kdrivers.html

Robert,

One other quick thing.... Could you take a screen snapshot of the window where your hardware acceleration slider is located? If you could, please e-mail it to me at:

(bpence at celestialsoftware.net)

Thanks!

Brian,

I've emailed you the screen captures that you asked for.

According to my system information, I'm using version 5.00.2179.1 already.

Did you mean that you wanted me to try version 5.0.2195.5012?

Sorry, I got that reversed. Whichever you are using, try the other.

Your sys info from a previous post:

Driver Version: 5.00.2179.1
OS Name: Microsoft Windows 2000 Professional
OS Version: 5.0.2195 Service Pack 4 Build 2195

I got it reversed. I must have looked at OS Version when I wrote that post. Strange coincidence, that!

I thought that's what'd happened.

I tried the new driver (5.0.2195.5012) and got the old result. The characters are still cut off in full acceleration mode and fine with cursor and bitmap acceleration turned off.

Thanks for testing that.

I've put a bid in on EBay for one of these ATI cards. I'd like to try to identify a possible workaround, but I'll have to be able to reproduce the problem first.

I'm not happy having to tell people to disable hardware acceleration in order for my program to work. There must be a better way!! I'm not doing anything all that complicated.

I won the auction unopposed. $7.99. I’m not sure I’ll be able to do anything about fixing the problem, as it’s likely a driver bug, but I *know* I can’t fix it if I can’t reproduce it. I’ll keep you posted.

Brian,

I'm impressed. Your determination to resolve this problem even thought it might not have anything to do with your software is commendable.

There are quite a number of developers out there (I've worked with too many of them) that would just throw up their hands and say that it's not their problem and move on.

Once again....well done good sir!!

Robert,

It's probably a bug in the driver, but there may possibly be a work-around. If I'm passing something that the driver is not expecting, it may be reacting in an un-predictable way. It's possible that by adjusting the way the drawing code works, I won't hit the bug. We'll see. Device drivers can be funny that way.

For example, I had a condition in the serial connection code where I would occasionally send a string of zero bytes on the COM port. On most hardware, this would just return immediately without sending anything. However, on some USB->COM PORT adapters, this would crash the driver (and the program). It was easy to work around. I just don't call the send routine when the byte count is zero!! Because it had never come up before, there appeared to be an incompatibility between my program and the user's hardware. I really considered that a driver bug( the driver had obviously never been tested with a zero-length input), but it was something that my program could adapt to.

It's possible that this issue could be similar. However, I'll have to see under what conditions this error occurs. If it's reproducable and predictable, I might be able to work around it.

For now, just turn down the hardware acceleartion.

I'll keep you posted.