Bug 178508

Created attachment 29559 [details]
Horizontal lines on 4.1.85 zoom with XRender

I have this problem too with an ATI 9600SE PRO.

Horizontal lines show up when u zoom in with composite on through XRender.

KDE version: 4.1.85
ATI drivers: 8.552
Built on: Gentoo x86 w/ GCC 4.3.2

Confirmed on xf86-video-ati drivers (from git) as well.

As discussed on IRC, I can also reproduce this on nVidia 177.82 using r900281.

A case of integer rounding error.

Does anyone use Xrender compositing with KDE4 anyway? It made sense in kde3 back in a days, when it was mainly about fade in/out. Now, will full-blown 3d desktop - XRender is way too slow to handle things, unacceptably slow - it's impractical (it's pure software rendering afterall).
Please consider dropping XRender support at all and focus on polishing OpenGL compositing only instead. XRender has not future...

Yes, people do use XRender compositing and it runs quite acceptably on quite a few systems that do not have graphics cards. I used to be able to run XRender myself at high framerates a few months ago but something has changed and I can no longer run it at the same speeds anymore.

Ran Xrender myself (with some horizontal artifacts) on a Radeon X1600 mobility.

OpenGL rendering is broken in Ubuntu Jaunty with the stock 2.6.28 kernel and opensource driven ATI radeon cards, but it's working in 2.6.29.1, so more people will use Xrender.  It's certainly usable.

The biggest problem appeared in borderless windows for me.  Certain notifications, some but not all menus become unreadable.

Almost (or all) bordered windows have a horizontal line at the bottom floating below the window.  However, the bordered windows do end up perfectly readable and usable.

If you change your kernel, on that and other ATI video cards, OpenGL rendering suddenly works again, so the Xrender bug becomes moot.

Apparently OpenGL on ATI is broken again in 2.6.30 RC.

I can no longer reproduce bug in description, so I suppose Lucas fixed it, right?

Anyway I really see no point in keeping XRender in code. Not only it makes unnecessary complication to code flow (and UI), but it's virtually impractical. I mean, come on - Zoom In/Out takes over 5 seconds here per frame (it's P4 3.2GHz, I know it's not speed demon, but...).

(In reply to comment #9)

> Anyway I really see no point in keeping XRender in code. 
Good idea, so we should also drop OpenGL support because some drivers are so buggy that it doesn't work correctly. And best we should remove all shader effects because there is hardware that does not support it.

There are users who use XRender and it helps them. It even helps me during development.

Just because your graphics driver has slow/buggy XRender support does not mean KWin should not support it.

Maybe it's not the case anymore, but as of this bug (~around KDE 4.2) kwin had problems working well with any compositing (various glitches everywhere, with shadow effect and zoom effect especially as well as sphere/cylinder), so idea of having just one but actually working and polished compositing engine was vital imho.

And I'm not buying 'broken driver' story. I understand that every developer (I'm one myself) usually prefers to blame his/her upstream for everything but some line has to be drawn somewhere.
@Christoph
What setup do you have and what kwin effects enabled so that your XRender is practical? (you know, at least >5fps, not 1 frame per 5s, with Zoom Effect)

Maciej, the only reason I need compositing is for the shadow plugin, I don't need any other, so XRender is perfectly fine.

@maciej:

with the the mode "2" pixmap placement* the nvidia css (but i don't know about the legacy) driver performs scaling (even "smooth") w/o any notable cpu usage and as fast as OpenGL / my framerate, so whatever you do:
sorry, but the problem is on your/GPU/driver side. period.
(it's a stupid server request, there's as much bug potential as in using glScale()

Most of the effects code is actually shared (esp. for the plugins) and while the backend oc adds more code, it's encapsulated.
If you specific experience a bug, report it.

Also notice that the XRender backend easily bypasses all texture/pixmap conversion issues, what has a clear advance if this is not done on the GPU.
(i don't think the legacy nvidia driver has perfect support for this - ever tried to play translucent quake?)

Fact is that some effects don't work with XRender as there's no Z model (why any "made up" link between xrender and the cube/sphere/cylinder is entire nonsense)
That doesn't mean it's not worth it because it lacks some paricular iCandy (tm).
(and it's also why i've yet unfinished code for a 2d "coverflow" here :)

This particular bug seems to be related to the quad rendering which is apparently done on a fp base what's not supported by xrender as well (pixel based system - so the horizontal lines are likely to be rounding errors ... scaling up the report, lucas pointed that some time ago =)

Conclusion:
the vague notice that kwin has/had glitches in some (zooming seems to be your core item, personally i rarely use it ever) of it's effects frontend code and a rather uninformed connection to one of the backends (xrender scaling is slow -> kwin bug) doesn't make you a point in "cutting away some code will make it better" - worse: e.g. Christoph might stop any support instead :-(
(and become a happy e17 user which afaik supports only xrender  for the "bling" plugin ;-P )

* "nvidia-settings -a InitialPixmapPlacement=2", (re)load compositing/change backend _after_ setting it

Marking as WORKSFORME based on https://bugs.kde.org/show_bug.cgi?id=178508#c9 (I also can't reproduce it)

If you're still able to reproduce the bug, please reopen the bug report.