it would be nice if it ignored what it couldn't parse. I can't use weaponm in a real game right now because it doesn't parse everything and i don't have teh script written yet. however i'd gladly let it tag along on twx proxy if it would work ok with it.

that way it could parse as i went along. and i could play with it and have it do things with the data it collects. i'd be testing it the same time i'd be playing a game with twx proxy.

neato. i was able to open up the jar in a text editor and view the source. i get a idea how things are put together.

one thing i'm not sure of is how to add more parsing. i know mongoose uses a lexer. and from what i understand, he has to compile it separate from the application?? thats probably what those automation files are .gz or something.

i'm not going to jump right in though messing with the app right now. i liked how the telnet negotiation was just one command he sent to satisfy twgs. i was looking in to see if he implemented the whole thing and how he worked with it. haha cause i was working on a client at one point and was playing with telnet negotiations. sending and receiving responses.

yeah, that one worries me.

it starts out fast. haven't heard much from mongoose on how that is coming.

Ok, good news - I'm making some progress. I'm writing out my findings to help me think it through:
- There is a thread that is forcing a full screen redraw every 750 milliseconds for blink handling
- There is another paint request when any character in the current viewport changes
- After 10000 lines, the limit of the buffer, repaint requests on character changes stop working. Scrolling up then down triggers a full redraw so you can see the state
- After 10000 lines, the only reason we see any content is the 750 ms blink redraws, hence it feel sluggish
- Even if I fix the 10k line problem, I still notice the redraws take progressively longer, especially around the 8k mark

There is a thread that is forcing a full screen redraw every 750 milliseconds for blink handling

There is another paint request when any character in the current viewport changes

I think that's a good solution with little to be gained from complex optimization. Repainting is extremely fast, as you can see if you grab the scroll bar knob and jerk it around. If the screen is scrolling, the whole thing needs repainted anyway. And if not, it's idle and can spare the CPU cycles. Swing repaints are asynchronous and automatically combined, so if repaint() is called twice before the screen actually repaints, it will only repaint once. And only the visible area is painted; the buffer size doesn't matter.

It should only repaint the region that contains the change.

I knew there was some weirdness at the very top of the display when it's full, but I haven't encountered the sluggishness you're describing. What happens when you run the speed test demo from JTX? The longer it runs, the higher the thread scheduler seems to prioritize the thread writing to the character buffer, at the expense of the thread repainting the screen.

The blink repaint seems to be repainting the whole component, which includes the large buffer. Wouldn't it be better to tell the blink to only paint the visible portion?

It was trying to tell the terminal to paint outside the region of the component, so nothing happened.

While I'm at at, what do you use for lexer debugging?

Calling repaint() with no params dirties the whole component. It's up to the Swing repaint manager to calculate the visible portion, because it might change between the calls to repaint() and paintComponent(). If there's any doubt, we can examine the clip rectangle of the Graphics object passed to paintComponent().

While I'm at at, what do you use for lexer debugging?