Bug 280156 - xterm: missing data on terminal
Summary: xterm: missing data on terminal
Status: RESOLVED WORKSFORME
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 4.7.0
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-15 20:38 UTC by Rich Coe
Modified: 2011-12-23 16:46 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rich Coe 2011-08-15 20:38:55 UTC
Version:           4.7.0 (using KDE 4.7.0) 
OS:                Linux

When I'm scrolling through a file with less or vi, sometimes many lines
don't paint.  When I move the mouse out of the window and the 
window loses focus, the window repaints with the correct data.  
I have 'focus follows under mouse' configured.

I first discovered this under KDE 4.6.0, but I recently upgraded to KDE 4.7.0
to see if the problem still exists.

Xserver is xorg-x11-server-7.6_1.9.3-15.18.4.x86_64
My display card is 'Broadway XT [Mobility Radeon HD 5800 Series]'.

If I turn off 'Desktop Effects' with either config menu or ALT-SHIFT-F12,
the problem goes away.

Additionally, scrolling is slower with Desktop Effects enabled.
I have a 11094 line file I created (list of files from the file system).
cat'ing this file to the terminal takes approximately 4.5 seconds
with desktop effects enabled.
cat'ing this file to the terminal takes less than a second with 
desktop effects disabled.


Reproducible: Always

Steps to Reproduce:
scroll text with less or vi in a xterm

Actual Results:  
Some lines of text are missing, especially near the top of terminal

Expected Results:  
All lines of text shall be displayed
Comment 1 Thomas Lübking 2011-08-15 22:04:09 UTC
- Please also have a look at bug #264259
Compare the "show paint" results on your side.

(settings in "kcmshell4 kwineffects")
- This only happens with OpenGL but not with XRender, i assume?
- Do you have the blur effect and/or v'syncing enabled? Is it any related?
- What if you keep compositing active but disable all effects?
- Are *only* terminals affected?
- What about other terminals but XTerm? Like konsole, aterm, lxterm or gnome-terminal or whatever.


A performance regression through the indirection and (in the GL case) pixmap -> texture conversion is unavoidable.
This also heavily depends on your HW and drivers. The XRender backend doesn't have to convert and might be in advance here.
Look forward to wayland.

However we hope to have improved damage event handling performance in 4.8 (current git master)
Comment 2 Rich Coe 2011-08-15 22:46:29 UTC
I changed OpenGL to XRender and didn't immediately see the issue.
I'll run it for a few days and see.

cat'ing the file to screen still took about 4 to 5 seconds in the two
runs I performed.

I'll have to read through bug #264259 more carefully to understand the 
'show paint' request.

I first noticed the issue when I upgraded my OS distro version which 
upgraded kde from 4.4.4 to 4.6.0.  I'll have to experiment with the different
effect settings.  I did not set any of them or knew of their existence. 

I'll try the other terminals as well.
Comment 3 Martin Flöser 2011-09-25 08:55:55 UTC
any news?
Comment 4 Rich Coe 2011-09-25 14:17:21 UTC
konsole is unaffected by desktop effects on or off.
The other terminal programs are not installed.
Comment 5 Thomas Lübking 2011-11-13 15:42:27 UTC
Ok, have you meanwhile inspected the "showPaint" results?
Is this still an issue with more recent xterm version at all?
Comment 6 Rich Coe 2011-11-23 04:39:26 UTC
I'm running kde 4.7.2 with xorg-x11-server 7.6 and xterm-276-3.2
and I don't notice the issue.

The default on this version is with desktop effects disabled.
I enabled desktop effects, and still did not notice the issue.
Comment 7 Stefanos Harhalakis 2011-12-23 16:46:54 UTC
I have the same problem for a loooong time now and I can reproduce it.

KDE 4.7.4 from debian experimental. Problem exists for more than a year IIRC.

Info: Radeon Hd4870, opensource driver, KMS.

xorg radeon driver: 6.14.3
mesa: 7.11.1
kernel: 3.1.5
libdrm: 2.4.27
xorg: 1.11.2.901 (1.11.3 RC1)

To reproduce: Open a terminal (xterm or rxvt - with rxvt seems to be more often - may by my imagination) and open a text file in vi. Then press ctrl-l to refresh the screen. To me, it happens every second refresh. At first it may need more that one to have parts of the screen disappear. 

If I move the window it gets repainted correctly.