Fast text display?

[Christopher Subich]

As a hobby project, I'm writing a MUD client -- this scratches an itch,
and is also a good excuse to become familiar with the Python language.
I have a conceptual handle on most of the implementation, but the
biggest unknown for me is the seemingly trivial matter of text display.

My first requirement is raw speed; none of what I'm doing is
processing-intensive, so Python itself shouldn't be a problem here. But
still, it's highly desirable to have very fast text updates (text
inserted only at the end)-- any slower than 20ms/line stretches
usability for fast-scrolling. EVERY other action on the text display,
though, like scrolling backwards or text selection, can be orders of
magnitude slower.

The second requirement is that it support text coloration. The exact
markup method isn't important, just so long as individual characters can
be independently colored.

The third requirement is cross-platform-osity; if you won't hold it
against me I'll tell you that I'm developing under Cygwin in Win2k, but
I'd really like it if the app could run under 'nix and mac-osx also.

I'm pretty open to any graphical toolkit -- I have experience with none
of them, so I have little in the way of prejudice.

I'm not even sure where to start looking to see if a widget that does
this has been premade -- the text widgets that I've seen so far have all
had documentation geared more towards text editing than pure display.
My closest look has been at PyGTK -- the GTK text widget is certainly
complex enough to handle the markup, but it also seems a little bit
feature-rich for my needs so I'm concerned about the overhead.

In a worst-case scenario, I could try writing a widget-lite with SDL or
possibly an OpenGL texture, but if a widget somewhere will already do
this then it'd be needless work. To boot, I have no idea how to handle
selection on such a homebrew-display if I'm using a proportional font,
but that's a minor matter.

So, the one-line summation of the novel above, does any one know of a
gui toolkit/widget that will do (preferably extremely) fast text display
in a cross-platform manner?

PS: I couldn't get a prototype curses display working either, the
scroll() function didn't work -- interactive log below:Traceback (most recent call last):
File "<stdin>", line 1, in ?
_curses.error: scroll() returned ERR

 

[Andrew Dalke]

My first requirement is raw speed; none of what I'm doing is
processing-intensive, so Python itself shouldn't be a problem here.

There's raw speed and then there's raw speed. Do you want to
display, say, a megacharacter/second?

it's highly desirable to have very fast text updates (text
inserted only at the end)-- any slower than 20ms/line stretches
usability for fast-scrolling.

Ahh, that's 400 bytes per second. That's pretty slow.

The second requirement is that it support text coloration.

The third requirement is cross-platform-osity

qtextedit has all of those. See
http://doc.trolltech.com/3.3/qtextedit.html

Looks like LogText mode is exactly what you want
http://doc.trolltech.com/3.3/qtextedit.html#logtextmode

] Setting the text format to LogText puts the widget in a special mode
] which is optimized for very large texts. Editing, word wrap, and rich
] text support are disabled in this mode (the widget is explicitly made
] read-only). This allows the text to be stored in a different, more
] memory efficient manner.

and

] By using tags it is possible to change the color, bold, italic and
] underline settings for a piece of text.

Depending on what you want, curses talking to a terminal might be
a great fit. That's how we did MUDs back in the old days.

Andrew
(e-mail address removed)

 

[Paul Rubin]

The third requirement is cross-platform-osity; if you won't hold it
against me I'll tell you that I'm developing under Cygwin in Win2k,
but I'd really like it if the app could run under 'nix and mac-osx
also.

I'm pretty open to any graphical toolkit -- I have experience with
none of them, so I have little in the way of prejudice.

Use tkinter if you care about cross-platform operation. Everything
else requires downloading and installing separate toolkits.

 

[Christopher Subich]

> Christopher Subich wrote:
>

processing-intensive, so Python itself shouldn't be a problem here.

>
>
>
> There's raw speed and then there's raw speed. Do you want to
> display, say, a megacharacter/second?
[snip]

> Ahh, that's 400 bytes per second. That's pretty slow.

Scrolling the text at any faster than a blur is counterproductive for
the user, after all. You're off by a decimal, though, an 80-column line
at 20ms is 4kbytes/sec. My guess is that any faster throughput than
10kbytes/sec is getting amusing for a mud, which in theory intends for
most of this text to be read anyway.

>
> qtextedit has all of those. See
> http://doc.trolltech.com/3.3/qtextedit.html

That looks quite good, except that Trolltech doesn't yet have a GPL-qt
for Win32. I might take another look at it whenever qt4 comes out, but
in the meantime (since I'm unfortunately developing on a win2k system)
it's not useful.

> Depending on what you want, curses talking to a terminal might be
> a great fit. That's how we did MUDs back in the old days.

See the scrolling problem in the original post, as to why I can't use it
as a temporary user interface.

 

[Christopher Subich]

> Use tkinter if you care about cross-platform operation. Everything
> else requires downloading and installing separate toolkits.

Oh, the downloading and installing isn't a big deal. If in the
far-flung future anyone else uses this program, they'll be big boys who
can install things themselves.

I'm just concerned about availability; the cross-platform operation for
me would exclude things like direct Win32API calls, or direct
linux-terminal calls (which apparently mcl uses to great effect).

 

[Paul Rubin]

Oh, the downloading and installing isn't a big deal. If in the
far-flung future anyone else uses this program, they'll be big boys
who can install things themselves.

No, it's a big pain. I'm a big boy and gave up on trying to install
wxpython for bittorrent on FC3 (the problem was with wxwidgets needing
an obsolete version of gtk, not with wxpython itself). There's just
no compelling reason to want to deal with this stuff. Tkinter has its
warts but it allows making functional gui's without all that much
fuss. If it were replaced in the default distro then I'd say use
whatever the new default is, but as it is, it's best to not impose
unnecessary extra headache on users.

 

[Christopher Subich]

No, it's a big pain. I'm a big boy and gave up on trying to install
wxpython for bittorrent on FC3 (the problem was with wxwidgets needing
an obsolete version of gtk, not with wxpython itself). There's just
no compelling reason to want to deal with this stuff. Tkinter has its
warts but it allows making functional gui's without all that much
fuss. If it were replaced in the default distro then I'd say use
whatever the new default is, but as it is, it's best to not impose
unnecessary extra headache on users.

Fair enough. At the moment, the expected user base for the program is
exactly one, but making it easy has its advantages. Since you've
obviously used it yourself, if I end up going with tkinter, are there
any performance gotchas on text rendering that I should be aware of?

 

[Andrew Dalke]

You're off by a decimal, though, an 80-column line
at 20ms is 4kbytes/sec.

D'oh! Yeah, I did hundredths of a second instead of thousands.

My guess is that any faster throughput than
10kbytes/sec is getting amusing for a mud, which in theory intends for
most of this text to be read anyway.

Which is why I don't think you'll have a problem with any of
the standard GUI libraries.

That looks quite good, except that Trolltech doesn't yet have a GPL-qt
for Win32.

Cost and license weren't listed as requirements.

You *did* say "hobby" though in post-hoc justification, I've known
people with some pretty expensive hobbies.

See the scrolling problem in the original post, as to why I can't use it
as a temporary user interface.

Indeed, but MUDs 15 years ago could run in a terminal and display
colored text via ANSI terminal controls, letting the terminal
itself manage history and scrolling. I had some sort of TSR for
the latter, under DOS.

Andrew
(e-mail address removed)

 

[Paul Rubin]

Fair enough. At the moment, the expected user base for the program is
exactly one, but making it easy has its advantages. Since you've
obviously used it yourself, if I end up going with tkinter, are there
any performance gotchas on text rendering that I should be aware of?

We're just talking about a scrolling text window that has to run at
human reading and typing speeds, right? It shouldn't be a problem.
I've used the text widget and found it to be fast enough for what I
was doing, though I didn't exactly stress it.

 

[Diez B. Roggisch]

That looks quite good, except that Trolltech doesn't yet have a GPL-qt
for Win32. I might take another look at it whenever qt4 comes out, but
in the meantime (since I'm unfortunately developing on a win2k system)
it's not useful.

Look at qt feee win edition, available here:

http://pythonqt.vanrietpaap.nl/

Diez

 

[Riccardo Galli]

No, it's a big pain. I'm a big boy and gave up on trying to install
wxpython for bittorrent on FC3 (the problem was with wxwidgets needing an
obsolete version of gtk, not with wxpython itself). There's just no
compelling reason to want to deal with this stuff. Tkinter has its warts
but it allows making functional gui's without all that much fuss.

Using tkinter doesn't need downloading and installing only in Windows.
In *nix is not so common to have tcl/tk installed (and probably in Mac too)

GUI cross platform need external support, in a OS or in another.

Bye,
Riccardo

 

[Paul Rubin]

Using tkinter doesn't need downloading and installing only in Windows.
In *nix is not so common to have tcl/tk installed (and probably in Mac too)

Hmm, in the Linux distros that I'm used to, tcl/tk is preinstalled. I
had the impression that it was included with Python but obviously I
haven't looked that closely.

 

[Christopher Subich]

> We're just talking about a scrolling text window that has to run at
> human reading and typing speeds, right? It shouldn't be a problem.
> I've used the text widget and found it to be fast enough for what I
> was doing, though I didn't exactly stress it.

It should have burst speeds of 2-10x reading speed; given the
stop-and-start nature of most muds, the data comes in bursts that the
player processes and reacts to before the next burst.

It's good to know that my concerns seem mostly unfounded. When I get to
a reasonable state of implementation, I'll post here if I've made any
unexpected discoveries.

 

[Eric Brunel]

Using tkinter doesn't need downloading and installing only in Windows.
In *nix is not so common to have tcl/tk installed (and probably in Mac too)

GUI cross platform need external support, in a OS or in another.

Even if tcl/tk is not installed by default on your system, doing it is usually not a pain, since the guys making it insist on keeping its required dependencies minimal: IIRC, to install tcl/tk on any Unix, you just need to have X and a C compiler.

This may be a slight advantage over most other toolkits, that usually require other libraries that you may not have installed on your system, or installed at the wrong version. I was sometimes caught in such a dependency hell when trying to install a toolkit that I eventually gave up...

 

[Renato Ramonda]

Riccardo Galli ha scritto:

GUI cross platform need external support, in a OS or in another.

Sure, but using win32 versions of gtk and glade plus py2exe and
InnoSetup (if you want to build a fancy installer) will give you a self
contained gui program in windows.

Big, sure, but self contained :-D