Reference FPS test for Windows console and Linux terminal

[anatoly techtonik]

We have a dispute if handling Windows console should be done the

same way as Linux terminal. I feel that Linux terminal is slower (Gnome

terminal in particular), but I can't prove that. Are there any tests on Go

that can test this cross-platform and show FPS.

For Windows there is http://www.pouet.net/prod.php?which=18381 that

runs at about 60 FPS in 80x50 window and has some C++ code. What

would be the equivalent for Linux?

[Staven]

On Tue, Nov 17, 2015 at 03:40:36PM -0800, anatoly techtonik wrote:
> We have a dispute if handling Windows console should be done the
> same way as Linux terminal. I feel that Linux terminal is slower (Gnome

> terminal in particular), but I can prove that. Are there any tests on Go

> that can test this cross-platform and show FPS.

This is the first time I've ever heard anyone mention FPS of terminals.
I don't know about you, but I can't read text at 60 FPS.
So, I'm just curious here, what do you need something like that for?

[Ian Davis]

 

 

On Tue, Nov 17, 2015, at 11:40 PM, anatoly techtonik wrote:

We have a dispute if handling Windows console should be done the

same way as Linux terminal. I feel that Linux terminal is slower (Gnome

terminal in particular), but I can prove that. Are there any tests on Go

that can test this cross-platform and show FPS.

 

For Windows there is http://www.pouet.net/prod.php?which=18381 that

runs at about 60 FPS in 80x50 window and has some C++ code. What

would be the equivalent for Linux?

 

 

You might be able to do some testing using https://github.com/JoelOtter/termloop which includes some render timing code.

 

Ian

 

 

[Konstantin Khomoutov]

On Tue, 17 Nov 2015 15:40:36 -0800 (PST)
anatoly techtonik <tech...@gmail.com> wrote:

> We have a dispute if handling Windows console should be done the
> same way as Linux terminal. I feel that Linux terminal is slower
> (Gnome terminal in particular), but I can prove that. Are there any
> tests on Go that can test this cross-platform and show FPS.
>
> For Windows there is http://www.pouet.net/prod.php?which=18381 that
> runs at about 60 FPS in 80x50 window and has some C++ code. What
> would be the equivalent for Linux?

I'm not sure about Windows console but "on Linux" (it's a strange term
but oh well) "the console" is a way more moot term or, rather, a term
which stands for a broader concept [1]. In short, back in the olden
days, "the console" stood for a hardware terminal connected to a host
machine (which actually run programs) via some sort of serial
connection (either direct RS-232 cable or modem etc). To not reinvent
the wheel, the Linux kernel, while supporting "true" hardware terminals,
does support two other concepts both of which *emulate* hardware
terminals to some degree:

1) Virtual terminals (VTs) [2]: are those text windows you see on an x86
machine when physically working with it "in text mode" (that is,
without graphical display provided by X Window System).

2) Pseudo terminals (PTYs) [3]: a completely virtualized solution which
provides terminal facilities to program which are not interfacing
to any hardware.
This one is the most tricky, and is used by several popular kinds
of software:
* Terminal emulators for X Window System;
* SSH client sessions;
* Software terminal multiplexers (screen, tmux).

Your GNOME Terminal is in fact not "a console" in the full sense of
this word but rather a "terminal emulator for X Window System".
And it uses the same protocol to interact with the programs it runs
a hardware terminal would use or a VT.

As you could have guessed, when you measure how GNOME Terminal renders
something, you should first try to understand what exactly you're
measuring. This might be the speed at which its code interfacing X
performs or this might be the speed at which it talks to the PTY
subsystem or it might be the speed of the PTY subsystem or it might be
the speed of the library used to talk to PTY or whatever.

As to low-level code for talking to the host's terminal subsystem, you
might look at the ncurses package (a ubiquitous solution on POSIX
systems to write "full-screen" text programs, written in C) or the
termbox-go package for a pure Go solution (and cross-platform, FWIW).

1. https://en.wikipedia.org/wiki/Computer_terminal#Text_terminals
2. https://en.wikipedia.org/wiki/Virtual_console
3. https://en.wikipedia.org/wiki/Pseudoterminal

[anatoly techtonik]

For building responsive deterministic and smooth user interfaces. Kind
of blocks you see on mobile phone are possible to do in console. And
I suspect that nobody do this on Linux, because it's very slow and/or
full of bugs (like accidentally hitting Ctrl-Q etc.). If Linux terminal gives
2-5 FPS, no matter how fast you type - ruined visual feedback will make
it feeling sluggish. So to change than in Linux kernel you need to make
a good proof of the problem, i.e. data. Then the next version of console
interface may get as good feeling as AAA game. And it is not about look
- many games with beautiful art are ruin the experience after first 15 min
because they don't get the simple fact that humans interact with
surrounding world not only with their eyes, and the standard for
responsiveness from you mouse, TV, mobile phone are all the same -
if your phone will make 200ms delay while typing - you will notice this
after playing with 60ms device, and console is no different - it should be
fast.

--
anatoly t.

[anatoly techtonik]

On Wed, Nov 18, 2015 at 5:31 PM, Konstantin Khomoutov
<flat...@users.sourceforge.net> wrote:
> As you could have guessed, when you measure how GNOME Terminal renders
> something, you should first try to understand what exactly you're
> measuring. This might be the speed at which its code interfacing X
> performs or this might be the speed at which it talks to the PTY
> subsystem or it might be the speed of the PTY subsystem or it might be
> the speed of the library used to talk to PTY or whatever.

I want the time what it takes to render one frame. As a user I don't care about
low level details or optimizations for particular cases. I want to
watch video in
console. =) Found this - https://www.youtube.com/watch?v=9ukhOAUseKY

--
anatoly t.

[anatoly techtonik]

Looks like the collision demo returns 62.5 FPS, but it is too simple and the
value doesn't change. I can't say from code if it redraws the whole screen
as fast as possible or only when input occurs. That's for Windows. How
much is on Linux?

go get -u github.com/JoelOtter/termloop
go run _examples/collision.go

[Milan P. Stanic]

This video is demo of the Ascii Art library:
http://aa-project.sourceforge.net/

I like sometimes to watch some videos with mplayer with 'aa' (ascii art)
or 'caca' (color ascii art).

[Staven]

I think you're trying to use the wrong tools to solve something that isn't a problem.

[Konstantin Khomoutov]

On Fri, 20 Nov 2015 01:38:17 +0300
anatoly techtonik <tech...@gmail.com> wrote:

[...]

> And I suspect that nobody do this on Linux, because it's very slow
> and/or full of bugs (like accidentally hitting Ctrl-Q etc.).

[...]

You meant ctrl-s, did you?

That's not a bug but rather a feature from "real" terminals: the
characters input by ^s and ^q are *by default* mapped to
terminal's flow control sequences which allow to send the program
controlled by the terminal SIGTSTP/SIGCONT signals thus pausing and
resuming its output (so that the operator has a chance to digest what
was output up to the current moment). Sure, in these days of insanely
large scrollbacks available (even on VTs) this feature appears to be a
funny leftover, and you're free to switch it off completely -- just put

stty -ixon ixoff

in your ~/.whatevershellrc and your ^s and ^q characters will be
delivered "as is" to the program controlled by the terminal.
Many folks do this just to enable incremental searching in
readline-enabled programs (or zsh or whatever else).

Actually, that's nothing strange about certain input be processed by
the terminal: otherwise ^c and ^d and ^z etc won't work either.

By the way, the `stty` program allows to control most aspects of
terminal emulation.

As to the rest of your response, I'm with Staven on it: if you need
fast screen output use appropriate means for this (OpenGL or framebuffer
directly or just use SDL).