kde apps draw very slowly

Interesting update to this problem: starting compiz actually fixes the problem. Everything is much faster..

I can confirm this. I run Ubuntu, but i also get this problem when i start Kate or K3b for example.
Xgl uses about 99% of my cpu when resizing so it's definitly got something to do with the new hardware based drawing stuff that's in Gutsy.

Starting compiz does indeed solve the slowness but changes my theme and enables all kinds of eye-candy i'm not interested in.
Maybe the bug description isn't accurate and it might very well be a duplicate but i'm wondering why we are the only two people having these problems.

I'll be happy to help debugging this problem.

Also using the restricted Nvidia module by the way.

I'm having the same problems - ATI graphics card, non-free drivers (fglrx).

Would it be a good idea to mark this bug as being related to a specific package? In my (admittedly limited) experience, bugs get attention faster if you specify a package.

I'd mark it as affecting kwin, although maybe it should go with xgl.

I've seen the same problem. Running the kernel's 'make menuconfig' inside a Konsole took over
5 seconds to draw!

Same thing here on a Compaq Presario V2610Cas with ATI XPress 200M, with opensource driver or ATI one. Didn't try with Compiz though. Things seems to go wrong just after I start a KDE session with KDM: the screen is flashing a couple of times before the session starts Everything works fine with Gnome. Could it be something in the startkde script?

I have the same problem. On my Dell Inspiron 1300. VIdeo Intel I915GM
When i am using it direct rendering is not enabled:

name of display: :1.0
display: :1 screen: 0
direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose)
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
    GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating,
    GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_OML_swap_method,
    GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe,
    GLX_SGIX_swap_barrier, GLX_SGIX_fbconfig
client glx vendor string: SGI
client glx version string: 1.4
client glx extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory,
    GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control,
    GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control,
    GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync,
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
    GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap
GLX version: 1.2
GLX extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_OML_swap_method,
    GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_fbconfig,
    GLX_EXT_texture_from_pixmap
OpenGL vendor string: Mesa project: www.mesa3d.org
OpenGL renderer string: Mesa GLX Indirect
OpenGL version string: 1.2 (2.1 Mesa 7.0.1)
OpenGL extensions:
    GL_ARB_depth_texture, GL_ARB_fragment_program, GL_ARB_imaging,
    GL_ARB_multitexture, GL_ARB_point_parameters, GL_ARB_point_sprite,
    GL_ARB_shadow, GL_ARB_shadow_ambient, GL_ARB_texture_border_clamp,
    GL_ARB_texture_cube_map, GL_ARB_texture_env_add,
    GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar,
    GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat,
    GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle,
    GL_ARB_transpose_matrix, GL_ARB_vertex_program, GL_ARB_window_pos,
    GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_func_separate,
    GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract,
    GL_EXT_clip_volume_hint, GL_EXT_copy_texture, GL_EXT_draw_range_elements,
    GL_EXT_fog_coord, GL_EXT_framebuffer_object, GL_EXT_multi_draw_arrays,
    GL_EXT_packed_pixels, GL_EXT_point_parameters, GL_EXT_polygon_offset,
    GL_EXT_rescale_normal, GL_EXT_secondary_color,
    GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, GL_EXT_stencil_wrap,
    GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D,
    GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add,
    GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3,
    GL_EXT_texture_lod_bias, GL_EXT_texture_object, GL_EXT_texture_rectangle,
    GL_EXT_vertex_array, GL_APPLE_packed_pixels, GL_ATI_texture_env_combine3,
    GL_ATI_texture_mirror_once, GL_ATIX_texture_env_combine3,
    GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate,
    GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_NV_blend_square,
    GL_NV_point_sprite, GL_NV_texgen_reflection, GL_NV_textur...

Now marked this bug as affecting xgl and kdebase - please someone remove one of these if it is inappropriate.

It seems quite clear that something in KDE and/or QT is drawing very slowly under XGL. Can *anyone* offer any convincing theory as to why this might be, or suggest what might be done to correct it?

Same here, after removing xgl kde works with normal speed again.
By the way compiz didn't work here too. NVidia Driver (NVIDIA FX5200).

Just to be a little bit more precise, I solved the problem just by removing the xerver-xgl package

I am also having this problem, NVidia Driver for Geforce4. Removing XGL fixes the problem but I'd rather not have it removed.

Strange; I knew about terrible performance of the fglrx drivers under Xgl without Compiz. Obviously the QT toolkit is doing something that is slow under Xgl without a Composite manager (such as Compiz).

Since this only appears in Xgl without compiz, why are people using Xgl? It's only really useful for running Compiz (and working around driver bugs while using Compiz), or for people using the fglrx drivers who also want kwin's Composite manager functionality. Marking as low priority, and I'll forward this upstream.

I had assumed it was the reason I couldn't get Compiz to work! I'm trying to run Compiz Fusion and I can't get it to work, getting the white screen, even though my nvidia card seems to be working okay when I try glxgears...

Are these separate issues?

Problems running Compiz are unrelated to this bug. An all-white screen when running Compiz under Xgl generally indicates that you've manually installed the nvidia drivers from nvidia.com, and they've overwritten some important libraries without backing them up. Reinstalling all the various mesa libraries (you can search for them in Synaptic) and then installing one of the Ubuntu-packaged nvidia drivers (from the Restricted Manager, for example) should fix that.

People are using Xgl because the upgrade to Gutsy makes them use XGL by default (at least, it did for me). I assume this is because Ubuntu (with GNOME) is using Compiz by default. Kubuntu still uses kwin, but also now seems to have XGL enabled.

No, they're using it because at some point they installed it and forgot. With the upgrade to gutsy just having xserver-xgl installed is enough to automatically have it start being used.

I am not sure. But i suspect KDE-3.5.8 upgrade on 7.04. I've done it right before 7.10 release. But in any case i've never install xserver-xgl explicitly. Also it's not default for Gutsy, because it's not listed as a dependency.

Same problem.

Using Ubuntu Gutsy (it was not there in Feisty)
NVIDIA GeForce FX 5500

It can be summarized as:

- Compiz disabled: some applications draw very slowly: qt-based, openoffice, maybe others. Video playback in totem and others is buggy: moving images seem broken by a diagonal line from top-left to botton-right and some other artifacts caused by some parts of the image been drawn before other parts. Specially visible in 1680x1050 full screen.

- Compiz enabled: now redraw is fast. Video playback in a windows seems ok, but consumes above 90% CPU in a AMD Athlon XP 2600. Video at full screen is also buggy, maybe becouse glx is disabled in full screen.

This issue makes video playback buggy at fullscreen in any case, and many applications to work slowly without compiz enabled. I think its importance should be more than "low".

I think it may be related to direct rendering being available or not:

glxinfor | grep direct

NVIDIA GeForce FX 5500
- direct rendering: No
- behaves as described in the previous post

NVIDIA GeForce 6200
- direct rendering: Yes
- window drawing is always fast (both with compiz and without it)
- video playback is OK without compiz.
- video is corrupt (just a colour pattern) with compiz on in both totem an gxine.

Can you check your direct rendering configuration?

It is indirectly related to direct rendering being available: when you're using Xgl, clients under Xgl don't get direct rendering.

On your GeForce 6200 you're not using Xgl, so you obviously don't see this Xgl bug.

I see. I thought xserver-xgl was standard in Gutsy. I forgot I had it installed manually some time ago.
Maybe not the right place to ask but, why would someone prefer xserver-xgl over xserver-xorg?

Thanks.

XGL is required to run compositing window managers like Compiz, at least on some graphics cards.

(For the time being, I've opted out of compiz/xgl, in favour of stability. Oh, and also bug 147642 )

Same over herewith Kubuntu Gutsy Gibbon on Intel i910/5.

I can confirm this problem, but I do not have XGL installed. I am using Ubuntu 7.10, nvidia 7800. Desktop effects are disabled. I have recorded a video to illustrate the difference:

http://upvector.com/kate_slow.avi

Kate is on the right (obviously). It is essentially unusable, as are all of the other KDE apps I use.

Notes:
- I am using the a driver downloaded from nvidia manually, installed with Envy (I am new to this Envy thing). While I typically downloaded the nvidia drivers in Ubuntu 7.04 as well, I always installed them using their provided installer only. Unfortunately, the restricted nvidia driver provided in the repositories incorrectly detects and sets my 1920x1200 display to 1600x1200, even if I manually "force" it to use 1920x1200 in various ways, but that's another issue for another bug.
- Kate was quite fast in the time I've been using Ubuntu prior to 7.10, from 5.04 to 7.04.
- While Gtk-based applications seem to be generally slower than they were in 7.04 (I have no data to back that up), they all run at a usable speed, unlike Kate and other KDE applications.

I also wanted to mention that this was a clean installation of 7.10 to a new drive, not an upgrade from 7.04.

To be sure, this is not only a KDE issue. I am also having this problem on Gnome: No Compiz --> *slow* OpenOffice.org; Compiz --> Fast. Let me know if it's useful to provide any other information...

Gnome window manager
Running Compiz + restricted ATI drivers, Desktop Effects enabled
Ubuntu Gutsy Gibbon 7.10 fresh install
Linux machname 2.6.22-14-generic #1 SMP Tue Dec 18 08:02:57 UTC 2007 i686 GNU/Linux
Compal CL56 notebook/laptop, Pentium M
Installed/using "xserver-xgl" in order to work around "driver bugs" (re: Chris Halse Rogers wrote on 2007-10-21)
ATI MOBILITY RADEON 9600/9700 Series
direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose)

Is there even a bug here? Xgl is meant to be used with compiz, why would you use Xgl otherwise?

>why would you use Xgl otherwise?

Because changes made for Gutsy mean that, if you have it installed, it will start automatically. I had it installed for playing around with Compiz in Feisty, but usually used plain Xorg with kwin. I've had to uninstall it to use Gutsy effectively.

Same problem here with Ubuntu 7.10, ATI card (restricted drivers), XGL session and without Compiz.
It sucks with Kile, Kdenlive, Konsole (QT issue?)

I do not have this problem anymore since a while on Gusty in an ATI card an compiz.

I seem to have simmilar/same problem
Ubuntu 8.04 amd64, nvidia 8600gt, nvidia's binary driver;
KDE is slooowwwwwww (drawing a START menu takes 3 seconds etc)
gnome is ok (apart from XGL crashing all the time, as reported in different bugs)

I have the same problem and the same solution....
I use Ubuntu 8.04 and my videocard is ATI Radeon XPress 200M. What happens next?

Rommel Oliveira, BRAZIL

xserver-xgl has been deprecated upstream, and removed from Intrepid. Closing the bug as won't fix.

+1 on Timo's Won't Fix