Hello to all,
I'm still on this topic, I can't let it go :-) Actually, I think this can be
fixed...
It seems that there is a phase transition in speed with the display of
character in
urxvt together with the vncserver.
What I see is the following (using the fixed font to exclude xft issues):
First produce different characters:
$ perl -e 'for(1..1E7) { $c=chr(rand()*(0x60-1)+0x20); print "$c"; }' > delme
Then start a local vncserver and connect to it via vncviewer:
% vncserver :1
% vncviewer -passwd ~/.vnc/passwd localhost:1
I use it on a 4k display.
Then measure the time to display the characters:
$ urxvt-256color -g 100x100 -fn fixed -pe -matcher -j -ss -e time cat delme
0,27s user 0,09s system 92% cpu 0,383 total
$ urxvt-256color -g 200x100 -fn fixed -pe -matcher -j -ss -e time cat delme
0,26s user 0,10s system 39% cpu 0,895 total
$ urxvt-256color -g 250x100 -fn fixed -pe -matcher -j -ss -e time cat delme
0,29s user 0,08s system 24% cpu 1,521 total
$ urxvt-256color -g 300x100 -fn fixed -pe -matcher -j -ss -e time cat delme
0,47s user 0,22s system 4% cpu 14,703 total
$ urxvt-256color -g 400x100 -fn fixed -pe -matcher -j -ss -e time cat delme
0,60s user 0,32s system 2% cpu 35,341 total
So, first the time to display the text goes linear with the area of the drawn
screen, which is understandable.
Then at around 250x100 something happens, which slows down everything
dramatically. Some latency and urxvt seems to wait for the xserver
or vice versa. Maybe some issue with the jumpScroll and skipScroll
functionality, which thinks it has to draw everything before continuing instead
of skipping.
Why do I think again that this can be fixed and is not a sole issue of the
vncserver (tigervnc in my case).
Because tigervnc seems to behave nicely, when using for example glxgears to
display graphics. The frame rate goes linearly down with the area to be drawn,
even up to a 4k display.
Then one more hint:
qterminal is able to "display" the same text and font without this phase
transition is speed.
1/4 of 4k: cat delme 0,00s user 0,09s system 6% cpu 1,331 total
1/2 of 4k: cat delme 0,00s user 0,07s system 4% cpu 1,762 total
1/1 of 4k: cat delme 0,00s user 0,07s system 2% cpu 2,612 total
So, it might be something that can be solved in urxvt, what do you think?
By the way: the same phase transition for a xft font:
$ urxvt-256color -g 100x50 -fn -pe -matcher -j -ss -e time cat delme 0,27s
user 0,09s system 49% cpu 0,726 total
$ urxvt-256color -g 200x50 -fn -pe -matcher -j -ss -e time cat delme 0,45s
user 0,13s system 2% cpu 25,835 total
Thanks a lot,
Michael
---------------------------------------
On Fri, 4 Aug 2017, Gregor Zattler wrote:
Date: Fri, 4 Aug 2017 22:03:49 +0200
From: Gregor Zattler <[email protected]>
To: rxvt-unicode <[email protected]>
Subject: Re: Limiting the update framerate
Hi Phil,
* Phil Tooley <[email protected]> [28. Jul. 2017]:
Is there some way to limit the update framerate? I am having
the issue that processes that produce large amounts of output
such as compiling cause the X server to consume huge amounts of
cpu due to the rate at which urxvt sends updates. I would like
to limit this update rate similar to the way Xterm or
suckless-term do. Is this possible at all with urxvt?
Besides the answer Marc gave you there are two command line
options:
-j|+j
Turn on/off jump scrolling (allow multiple lines per refresh);
resource jumpScroll.
-ss|+ss
Turn on/off skip scrolling (allow multiple screens per refresh);
resource skipScroll.
This might help you.
Ciao, Gregor
--
-... --- .-. . -.. ..--.. ...-.-
_______________________________________________
rxvt-unicode mailing list
[email protected]
http://lists.schmorp.de/mailman/listinfo/rxvt-unicode
_______________________________________________
rxvt-unicode mailing list
[email protected]
http://lists.schmorp.de/mailman/listinfo/rxvt-unicode
