By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,235 Members | 1,011 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,235 IT Pros & Developers. It's quick & easy.

Fast text display?

P: n/a
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:
import curses
x = curses.initscr()
print curses.has_il() True x.idlok(1)
x.scroll(1)

Traceback (most recent call last):
File "<stdin>", line 1, in ?
_curses.error: scroll() returned ERR
Jul 19 '05 #1
Share this Question
Share on Google+
14 Replies


P: n/a
Christopher Subich wrote:
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
da***@dalkescientific.com

Jul 19 '05 #2

P: n/a
Christopher Subich <sp****************@block.subich.spam.com> writes:
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.
Jul 19 '05 #3

P: n/a
Andrew Dalke wrote:
Christopher Subich wrote:
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?
[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. :)
Jul 19 '05 #4

P: n/a
Paul Rubin wrote:
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).

Jul 19 '05 #5

P: n/a
Christopher Subich <sp****************@block.subich.spam.com> writes:
> 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. :)


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.
Jul 19 '05 #6

P: n/a
Paul Rubin wrote:
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?
Jul 19 '05 #7

P: n/a
Christopher Subich wrote:
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
da***@dalkescientific.com

Jul 19 '05 #8

P: n/a
Christopher Subich <sp****************@block.subich.spam.com> writes:
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.
Jul 19 '05 #9

P: n/a
>
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
Jul 19 '05 #10

P: n/a
On Wed, 08 Jun 2005 13:58:00 -0700, Paul Rubin wrote:
Christopher Subich <sp****************@block.subich.spam.com> writes:
> 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. :)


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

--
Riccardo Galli
Sideralis Programs
http://www.sideralis.net
Jul 19 '05 #11

P: n/a
Riccardo Galli <riccardo_cut1@cut2_sideralis.net> writes:
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.
Jul 19 '05 #12

P: n/a
Paul Rubin wrote:
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.
--
PS: Really sorry to everyone about all the e-mails I've generated. I'm
not quite used to Thunderbird, and it puts "reply to sender only" where
I'd expect "reply to newsgroup" to be.
Jul 19 '05 #13

P: n/a
On Thu, 09 Jun 2005 02:22:08 +0200, Riccardo Galli <riccardo_cut1@cut2_sideralis.net> wrote:
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...
--
python -c "print ''.join([chr(154 - ord(c)) for c in 'U(17zX(%,5.zmz5(17;8(%,5.Z65\'*9--56l7+-'])"
Jul 19 '05 #14

P: n/a
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

--
Renato
--------------------------------
Usi Fedora? Fai un salto da noi:
http://www.fedoraitalia.org
Jul 19 '05 #15

This discussion thread is closed

Replies have been disabled for this discussion.