Bug 203365

I think it is unrelated to the style changes as you say that it is even slow if you press alt+tab fast without raising the tabbox.

So the cause for the performance degradation has to be somewhere else and I have no idea (I don't use 30 windows, normaly I have a maximum of ten windows on one desktop).

i must confirm that (at least the first) plasma rendering introduced some cpu load (even w/o 30 open wins ;-), probably for svg rendering w/o cache data

The next calls usually run faster. If there's a timer (i usually use cover switch or exp... "present windows"...) to flush the svg cache this might hit everytime.

I also think pressing alt + 3xTab in a row won't prevent you from calling the tabbox, it's just visually dropped in the lag?!

@Carsten:
Is there also a lag if you alt+tab, wait eg. 5secs and alt+tab again or just with long delays between the calls?

@Martin: i saw the code earlier and it should be pretty simple to add a (hidden) config item to always use the simple OSD frames to support weaker systems (if it's actually due to bad plasma rendering performance and that can't be improved)

Yes adding a (hidden) option to not animate is no problem and could even be backported to 4.3 branch.

(In reply to comment #2)
> I also think pressing alt + 3xTab in a row won't prevent you from calling the
> tabbox, it's just visually dropped in the lag?!

Kwin has a slight delay before showing the tab box, so that it won't appear at all when you press Alt-Tab (once or multiple times) very quickly.
I don't know whether the box is created and populated immediately and only shown after the delay, or whether the creation and population is delayed too.

> @Carsten:
> Is there also a lag if you alt+tab, wait eg. 5secs and alt+tab again or just
> with long delays between the calls?

The lag is there every time even when I press Alt-Tab multiple times very quickly.

Note that cycling back and forth between just two windows (i.e. hitting tab just once, and not waiting for the box to appear) works quickly. Only when I want to tab to another "farther away window" with at least two tab presses, I get the lag. 

I suppose that with a single tab press, the window to be shown is already known and the tab box is not populated (because I release Alt quickly) => fast. For more tab presses, the window to activate needs to be calculated and/or the tab box is populated (even if not visible). Maybe the calculation of the window to activate is causing the lag.

(In reply to comment #4)
> Kwin has a slight delay before showing the tab box, so that it won't appear at
> all when you press Alt-Tab (once or multiple times) very quickly.
I can do that with /one/ alt+tab - as soon as i press tab the second time the tabbox pops up (or the cover switch animation starts...) and i'm certainly not slow on this (i can press it 12 times a second, just tested - 15 times righthanded ;-)


> Note that cycling back and forth between just two windows (i.e. hitting tab
> just once, and not waiting for the box to appear) works quickly. Only when I
> want to tab to another "farther away window" with at least two tab presses, I
> get the lag. 
ok, so it's rather while changing and not to popup the box.
To ensure it's the box drawing you could uncheck "Show window list while..." in the focus page of kwins config dialog (rmb a titlebar -> configure window behaviour...)

I can press tab 12 times in a row before the box appears (which takes something between 1 and 2 seconds :-])

When disabling the tab box with the option you mentioned, switching windows is really fast (around 12 windows per second ;-)

So the tab box really is related to this performance problem.

I just want to mention: I am currently rewriting the complete tabbox and by that found several "strange" code paths which could be responsible for the degeneration. I removed all those code pathes for the new tabbox, so the new implementation should fix this issue (and is able to handle something like 30 windows way better btw). But I'm unsure if it's worth to go through the code and try to fix it for 4.2 (I will look at the final diffs and hope to identify the worst mistakes ;-) ).

Cool, thanks! Fixing it for 4.3 would be enough for me, btw ;-)
If you're hesitant to backport this to 4.3, a hidden option to revert to the non-plasma tabbox would be nice, though, because switching windows really is a burden to me right now :-}

*** Bug 204858 has been marked as a duplicate of this bug. ***

The duplicate bug #204858 mentions that the problem did not exists before rc3. That was the time when the animation was added. So this could be related.

In case it may help - I just had effects disabled due to low battery and found, that switching with Alt-TAB has no delay now. Looks related to effects enabled.

I just tested my new implementation with something like 30 open windows. It takes about 1 to 2 seconds till the list is shown. That is independent from effects being enabled or not. Further more it is independent from layout - that is even if only text is shown it doesn't improve. Navigation in the list itself is quite fast as soon as the list is shown.

But when I open the layout configuration, which has a live preview based on stacking order, the same list is shown immediately. So I think the problem is the algorithm to setup the window list in focus chain. (that could explain the improvements when not showing the list). I'll investiage further.

Is this still an issue with the latest versions of 4.5 or 4.6? I have never experienced issues with Alt+Tab performance.

I can offer one data point - KDE version bundled with Fedora 12 presented this problem while after an installation of Fedora 13 (currently KDE 4.5.4?) the very annoying delay was resolved.

(In reply to comment #13)
> Is this still an issue with the latest versions of 4.5 or 4.6? 

Yes, I still see these delays in 4.6.

Is there any way to reproduce this issue reliable? E.g. some special settings, a window which has to be open?

to narrow this down a bit:
- is it actually related to the amount of windows?
- is it still slow if you use a window switcher that does NOT invoke any kind of plasma frame (say cover/flip switch withOUT displaying the title)
- (in 4.6 you can disable the tabbox entirely (but keep windows raising), does this prevent the lag?)

I can still confirm that the very first frame rendering takes some time here (~1s) but the following do not - could this be theme related? Can some themes be cached and others not?)

Oh, and last but not least:
if you use "no effect" while your desktop is composited, the tabbox will get the show animation - no matter how long that takes...

*** Bug 273690 has been marked as a duplicate of this bug. ***

(In reply to comment #17)

I never use most of these modes so not sure what they mean. When I have several windows open on more than one desktop and I do alt-tab, I always see the window outline appear immediately. However, sometimes it takes 10 seconds or more for the window list to appear (using "compact" form). The delay time seems to be proportional to how long it has been since the previous alt-tab and possibly how much other CPU usage has occurred.

Again, not using any compositing or effects. Also, all background desktop search stuff is disabled so CPUs are virtually idle. 

Re: Bug 273690 for my original write-up on this bug.

(In reply to comment #17)

> Re: Bug 273690 for my original write-up on this bug.

When I originally wrote this, the delay I was seeing was only a few seconds. Now the delay is sometimes about 10 seconds or more. I notice that the long delay is usually after having done a fairly CPU intensive action such as a large "make clean all" build. All other activities are very responsive except for the alt-tab. Also, the delay seem longer on a system with dual monitors. On system with single monitor the delay is often bad but it is not usually as long (but that system has a slightly faster CPU and newer AMD video card).

- Do you have an nvidia GPU?
- Does switching the plasma theme (try "plain") have any impact?
- Can you post the [TabBox] section of ~/.kde/share/config/kwinrc
- And to be sure: what kind of CPU do we talk about?

(In reply to comment #21)
> - Do you have an nvidia GPU?

No. Currently using two systems with AMD cards. The "faster system" (3-5 second delay) is ATI Radeon HD 4200 GPU. The slower system (10 second delay) is a "generic" ATI card included with a standard issue Dell. I don't know the model right off

> - Does switching the plasma theme (try "plain") have any impact?

Sorry, don't see a setting for "plasma theme". See "desktop theme" which is set to default laughlin and not setting listed for "plain".

> - Can you post the [TabBox] section of ~/.kde/share/config/kwinrc

For faster system with 3-5 sec delay:
[TabBox]
HighlightWindows=false
LayoutMode=0
LayoutName=Compact
ListMode=0
MinHeight=17
MinWidth=20
SelectedItem=0
SelectedLayoutName=Text
ShowDesktop=false
ShowOutline=false
ShowTabBox=true
SwitchingMode=0
TraverseAll=false

[TabBoxAlternative]
HighlightWindows=true
LayoutMode=0
LayoutName=Default
ListMode=0
MinHeight=20
MinWidth=20
SelectedItem=0
SelectedLayoutName=Text
ShowDesktop=false
ShowOutline=true
ShowTabBox=true
SwitchingMode=0

For system with 10 sec delay:
[TabBox]
HighlightWindows=false
LayoutMode=0
LayoutName=Compact
ListMode=0
MinHeight=0
MinWidth=0
SelectedItem=0
SelectedLayoutName=Text
ShowDesktop=false
ShowOutline=true
ShowTabBox=true
SwitchingMode=0

[TabBoxAlternative]
HighlightWindows=true
LayoutMode=0
LayoutName=Default
ListMode=0
MinHeight=20
MinWidth=20
SelectedItem=0
SelectedLayoutName=Text
ShowDesktop=false
ShowOutline=true
ShowTabBox=true
SwitchingMode=0


> - And to be sure: what kind of CPU do we talk about?

The system with smaller delay (3-5 sec) is AMD phenom II with 3-cores. The system with longer delay is a 2007 Dell box with Intel core-2 duo of some sort. Both are running 64 bit fedora 14 with all updates.

Hello there. This is marked NEEDSINFO WAITINGFORINFO. My alt-tab is lagging on first use and I have some info. Using gentoo ~amd64, kde 4.10.1, linux 3.8.3. Task switcher: compact. 

In reply to #21 "Does switching the plasma theme (try "plain") have any impact?"

After logging in the first use of alt-tab produces about 6s lag. After that the box pops up in less than 1s. After switching the desktop theme in system settings (ie Air -- Tibanna) and applying the settings the next use of alt-tab lags again for about 6s. After that it's fine.

Output in .xsession-errors:
plasma-desktop(1503)/kio (KDirListerCache) KDirListerCache::slotFileDirty: "/home/mart/.kde4/share/config/plasmarc"
plasma-desktop(1503)/kio (KDirListerCache) KDirListerCache::updateDirectory: KUrl("file:///home/mart/.kde4/share/config")
krunner(1530)/kio (KDirListerCache) KDirListerCache::slotFileDirty: "/home/mart/.kde4/share/config/plasmarc"
krunner(1530)/kio (KDirListerCache) KDirListerCache::updateDirectory: KUrl("file:///home/mart/.kde4/share/config")
krunner(1530) KRunnerDialog::themeUpdated: 4 2 4 4
X Error: RenderBadPicture (invalid Picture parameter) 141
  Extension:    138 (RENDER)
  Minor opcode: 7 (RenderFreePicture)
  Resource id:  0x3000025
(X error repeats 6x)

This is on a modest Intel integrated GM965 + core2duo with 4GB of RAM. 
I could debug and strace and whatever but I don't know where to start.

Oh, cool - a corpse bug.

What you describe is certainly related to create and map the desktop theme into memory.

In the meantime i learned that the /var filesystem has a *major* impact on this - esp. reiserfs but also ext2/3 are lousy on posix_fallocate - changing to ext4 or btrfs or even tempfs (if you got enough RAM) or preferably some cramfs derivate for /var or at least /var/tmp/kdecache-`whoami` will accelerate things *alot*.

Amazing! Moved the cache from encfs encrypted filesystem to ext4 and first run is down to <=1s. Thanks!

encfs - that explains a lot. Thanks, that's an important bit of information to remember to ask users in future when they complain about performance issues.

Not necessarily esp. encfs, since many systems do AES in HW.

The core issue here is that the plasma theme cache is just a huge sparse nothing, like 80 times oversized.

That's just a major problem for several filesystems (and it doesn't help that /var often is -still- reiserfs because its high performance with the usual high fluctuation of many small files in there)

It's also a problem for some setups where /var/tmp is (against suggestions but actually suitable for a desktop system) on tmpfs (because it quickly occupies too much space -there's a related bug- and then you run into OOM on that device)

Eg. i've 10MB in the entire icon cache, 30MB in the http cache and 81MB for each and every plasma theme cache - otherwise using tmpfs on /var/tmp/kdecache-`whoami` would be simple for every user.
This way it becomes science to keep the size under control (unless you just wipe it on every restart, don't change the theme and either way accept wasting 80MB RAM on the theme)

Compressing images won't solve that since the paddings would still remain.
On tempfs or SSDs it may be much better to use a file per cached element in subdir -> i wanted to suggest that for frameworks (*sigh*) one day

I too am having some delay using alt-tab.

My system is gentoo + KDE 4.10.4 on an SSD.
The delay is approximately 1s before displaying windows, which compared to the rest of the system performance, it quite bad IMO. I have my /var/tmp/ mounted onto a tmpfs filesystem (and the rest of my system is ext4). I will attempt changing the filesystem to ramfs, then ext4 if that is slow as well. All my partitions are primary and no LUKS or encryption if used. 
Kernel is custom built, fiddling with some of the desktop pre-emptive settings.
Video card is Integrated Intel 3000 series, Thinkpad T420.

I am getting some bad window (invalid window paramater) errors in xsession.

(In reply to comment #28)
> The delay is approximately 1s before displaying windows, which compared to
> the rest of the system performance, it quite bad IMO. I have my /var/tmp/
> mounted onto a tmpfs filesystem (and the rest of my system is ext4). I will
> attempt changing the filesystem to ramfs, then ext4 if that is slow as well.

tempfs /is/ a ramfs - the issue with tmpfs is usally that the plasma theme floods it with its oversize, certainly not speed.

The only thing i could assume is that plasma theme caching fails due to an insufficient (hard set) partition size (so the theme re-renders)

Please check whether there's
ls /var/tmp/kdecache-`whoami`/plasma*kcache

Also:
- is it only slow on the first invocation (of the session) or always and esp. if latter
- what switcher do you use and what happens if you change to cover or flipswitch?

> All my partitions are primary
That's only important for the MBR ;-)

> I am getting some bad window (invalid window paramater) errors in xsession.
Probably unrelated, usually access attempts to properties of deleted windows.

Thanks for responding Thomas. I may have solved my issue, though it may not solve others'.

 ~ # ls /var/tmp/kdecache-`whoami`/plasma*kcache
ls: cannot access /var/tmp/kdecache-root/plasma*kcache: No such file or directory

No cache.
- It is slow on the first invocation especially, when switching to ext4 it was slow on all invocations.
- I use the Box Switch and for Scale Method I was using "Accurate"

What I did, was switch everything back to my tmpfs and put the Scale Method on "Crisp". I already disable VSync and am using OpenGL/Native for rendering.
Since using Crisp, the delay is non-existant. Perhaps extra processing is done in Accurate that delays the alt-tab. 
I haven't changed my switcher to cover or flip, I can revert my changes and test those if you want.

Many thanks for your help thus far. :)

(In reply to comment #30)
> Thanks for responding Thomas. I may have solved my issue, though it may not
> solve others'.
> 
>  ~ # ls /var/tmp/kdecache-`whoami`/plasma*kcache
> ls: cannot access /var/tmp/kdecache-root/plasma*kcache: No such file or
> directory
> 
> No cache.
> - It is slow on the first invocation especially, when switching to ext4 it
> was slow on all invocations.
> - I use the Box Switch and for Scale Method I was using "Accurate"
> 
> What I did, was switch everything back to my tmpfs and put the Scale Method
> on "Crisp". I already disable VSync and am using OpenGL/Native for rendering.
> Since using Crisp, the delay is non-existant. Perhaps extra processing is
> done in Accurate that delays the alt-tab. 
> I haven't changed my switcher to cover or flip, I can revert my changes and
> test those if you want.
> 
> Many thanks for your help thus far. :)

Sorry, root doesn't run kde. I was root when calling the whoami command; apologies for the double post.

celestia@celestia ~ $ ls /var/tmp/kdecache-`whoami`/plasma*kcache
/var/tmp/kdecache-celestia/plasma_theme_Amarok-Mockup.kcache  /var/tmp/kdecache-celestia/plasma_theme_default.kcache  /var/tmp/kdecache-celestia/plasma_theme_internal-system-colors.kcache

(In reply to comment #30)

> - I use the Box Switch and for Scale Method I was using "Accurate"
On what KDE version? BoxSwitch has long time been dropped
 
> Since using Crisp, the delay is non-existant. Perhaps extra processing is
> done in Accurate that delays the alt-tab. 

       -> This is entirely unrelated to this particular bug.

"Accurate" implementes a lanczos filter on shaders, it's mostly a matter of your GPU on whether this is possible at all or eventually slow (esp. if the driver lies about its capabilities and then just uses some software emulation, things get slow)

Since your KDE version would be ~4.8 (to use BoxSwitch), have a look at the output of "kwin --replace &" or just "glxinfo" to know what system you're on.

Info:

celestia ~ # kwin -v
Qt: 4.8.4
KDE Development Platform: 4.10.4
KWin: 4.10.4

celestia ~ # glxinfo
name of display: :0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
    GLX_ARB_create_context, GLX_ARB_create_context_profile, 
    GLX_ARB_multisample, GLX_EXT_create_context_es2_profile, 
    GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, 
    GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, 
    GLX_SGI_swap_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, 
    GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_INTEL_swap_event
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
    GLX_ARB_create_context, GLX_ARB_create_context_profile, 
    GLX_ARB_create_context_robustness, GLX_ARB_framebuffer_sRGB, 
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, 
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_framebuffer_sRGB, 
    GLX_EXT_create_context_es2_profile, GLX_MESA_copy_sub_buffer, 
    GLX_MESA_multithread_makecurrent, GLX_MESA_swap_control, 
    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_INTEL_swap_event
GLX version: 1.4
GLX extensions:
    GLX_ARB_create_context, GLX_ARB_create_context_profile, 
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, 
    GLX_EXT_visual_info, GLX_EXT_visual_rating, 
    GLX_EXT_create_context_es2_profile, GLX_MESA_copy_sub_buffer, 
    GLX_MESA_multithread_makecurrent, GLX_MESA_swap_control, 
    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_INTEL_swap_event
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile 
OpenGL version string: 3.0 Mesa 9.1.2
OpenGL shading language version string: 1.30
OpenGL extensions:
    GL_ARB_multisample, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, 
    GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_copy_texture, 
    GL_EXT_polygon_offset, GL_EXT_subtexture, GL_EXT_texture_object, 
    GL_EXT_vertex_array, GL_EXT_compiled_vertex_array, GL_EXT_texture, 
    GL_EXT_texture3D, GL_IBM_rasterpos_clip, GL_ARB_point_parameters, 
    GL_EXT_draw_range_elements, GL_EXT_packed_pixels, GL_EXT_point_parameters, 
    GL_EXT_rescale_normal, GL_EXT_separate_specular_color, 
    GL_EXT_texture_edge_clamp, GL_SGIS_generate_mipmap, 
    GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, 
    GL_SGIS_texture_lod, GL_ARB_framebuffer_sRGB, GL_ARB_multitexture, 
    GL_EXT_framebuffer_sRGB, GL_IBM_multimode_draw_arrays, 
    GL_IBM_texture_mirrored_repeat, GL_3DFX_texture_compression_FXT1, 
    GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_transpose_matrix, 
    GL_EXT_blend_func_separate, GL_EXT_fog_coord, GL_EXT_multi_draw_arrays, 
    GL_EXT_secondary_color, GL_EXT_texture_env_add, 
    GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias, 
    GL_INGR_blend_func_separate, GL_NV_blend_square, GL_NV_light_max_exponent, 
    GL_NV_texgen_reflection, GL_NV_texture_env_combine4, GL_S3_s3tc, 
    GL_SUN_multi_draw_arrays, GL_ARB_texture_border_clamp, 
    GL_ARB_texture_compression, GL_EXT_framebuffer_object, 
    GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_MESA_window_pos, 
    GL_NV_packed_depth_stencil, GL_NV_texture_rectangle, GL_ARB_depth_texture, 
    GL_ARB_occlusion_query, GL_ARB_shadow, GL_ARB_texture_env_combine, 
    GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, 
    GL_ARB_texture_mirrored_repeat, GL_ARB_window_pos, GL_ATI_envmap_bumpmap, 
    GL_EXT_stencil_two_side, GL_EXT_texture_cube_map, GL_NV_depth_clamp, 
    GL_APPLE_packed_pixels, GL_APPLE_vertex_array_object, GL_ARB_draw_buffers, 
    GL_ARB_fragment_program, GL_ARB_fragment_shader, GL_ARB_shader_objects, 
    GL_ARB_vertex_program, GL_ARB_vertex_shader, GL_ATI_draw_buffers, 
    GL_ATI_texture_env_combine3, GL_ATI_texture_float, GL_EXT_shadow_funcs, 
    GL_EXT_stencil_wrap, GL_MESA_pack_invert, GL_MESA_ycbcr_texture, 
    GL_NV_primitive_restart, GL_ARB_depth_clamp, 
    GL_ARB_fragment_program_shadow, GL_ARB_half_float_pixel, 
    GL_ARB_occlusion_query2, GL_ARB_point_sprite, GL_ARB_shading_language_100, 
    GL_ARB_sync, GL_ARB_texture_non_power_of_two, GL_ARB_vertex_buffer_object, 
    GL_ATI_blend_equation_separate, GL_EXT_blend_equation_separate, 
    GL_OES_read_format, GL_ARB_color_buffer_float, GL_ARB_pixel_buffer_object, 
    GL_ARB_texture_compression_rgtc, GL_ARB_texture_float, 
    GL_ARB_texture_rectangle, GL_EXT_packed_float, GL_EXT_pixel_buffer_object, 
    GL_EXT_texture_compression_dxt1, GL_EXT_texture_compression_rgtc, 
    GL_EXT_texture_rectangle, GL_EXT_texture_sRGB, 
    GL_EXT_texture_shared_exponent, GL_ARB_framebuffer_object, 
    GL_EXT_framebuffer_blit, GL_EXT_framebuffer_multisample, 
    GL_EXT_packed_depth_stencil, GL_APPLE_object_purgeable, 
    GL_ARB_vertex_array_object, GL_ATI_separate_stencil, GL_EXT_draw_buffers2, 
    GL_EXT_draw_instanced, GL_EXT_gpu_program_parameters, 
    GL_EXT_texture_array, GL_EXT_texture_integer, GL_EXT_texture_sRGB_decode, 
    GL_EXT_timer_query, GL_OES_EGL_image, GL_MESA_texture_array, 
    GL_ARB_copy_buffer, GL_ARB_depth_buffer_float, GL_ARB_draw_instanced, 
    GL_ARB_half_float_vertex, GL_ARB_instanced_arrays, 
    GL_ARB_map_buffer_range, GL_ARB_texture_rg, GL_ARB_texture_swizzle, 
    GL_ARB_vertex_array_bgra, GL_EXT_separate_shader_objects, 
    GL_EXT_texture_swizzle, GL_EXT_vertex_array_bgra, 
    GL_NV_conditional_render, GL_AMD_draw_buffers_blend, 
    GL_ARB_ES2_compatibility, GL_ARB_blend_func_extended, GL_ARB_debug_output, 
    GL_ARB_draw_buffers_blend, GL_ARB_draw_elements_base_vertex, 
    GL_ARB_explicit_attrib_location, GL_ARB_fragment_coord_conventions, 
    GL_ARB_provoking_vertex, GL_ARB_sampler_objects, GL_ARB_seamless_cube_map, 
    GL_ARB_shader_texture_lod, GL_ARB_texture_cube_map_array, 
    GL_ARB_texture_rgb10_a2ui, GL_ARB_uniform_buffer_object, 
    GL_ARB_vertex_type_2_10_10_10_rev, GL_EXT_provoking_vertex, 
    GL_EXT_texture_snorm, GL_MESA_texture_signed_rgba, 
    GL_ARB_get_program_binary, GL_ARB_robustness, GL_ARB_shader_bit_encoding, 
    GL_ARB_timer_query, GL_ANGLE_texture_compression_dxt3, 
    GL_ANGLE_texture_compression_dxt5, GL_ARB_internalformat_query, 
    GL_ARB_shading_language_packing, GL_ARB_texture_storage, 
    GL_EXT_transform_feedback, GL_ARB_ES3_compatibility, 
    GL_ARB_invalidate_subdata

16 GLX Visuals
    visual  x   bf lv rg d st  colorbuffer  sr ax dp st accumbuffer  ms  cav
  id dep cl sp  sz l  ci b ro  r  g  b  a F gb bf th cl  r  g  b  a ns b eat
----------------------------------------------------------------------------
0x020 24 tc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x021 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x082 24 tc  0  32  0 r  y .   8  8  8  8 .  .  0  0  0  0  0  0  0  0 0 None
0x083 24 tc  0  32  0 r  . .   8  8  8  8 .  .  0  0  0  0  0  0  0  0 0 None
0x084 24 tc  0  32  0 r  . .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x085 24 tc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8 16 16 16 16  0 0 Slow
0x086 24 tc  0  32  0 r  y .   8  8  8  8 .  .  0  0  0  0  0  0  0  4 1 None
0x087 24 tc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  4 1 None
0x088 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0  0  0  0  0  0  0  0 0 None
0x089 24 dc  0  32  0 r  . .   8  8  8  8 .  .  0  0  0  0  0  0  0  0 0 None
0x08a 24 dc  0  32  0 r  . .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x08b 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x08c 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8 16 16 16 16  0 0 Slow
0x08d 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0  0  0  0  0  0  0  4 1 None
0x08e 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  4 1 None
0x05d 32 tc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None

36 GLXFBConfigs:
    visual  x   bf lv rg d st  colorbuffer  sr ax dp st accumbuffer  ms  cav
  id dep cl sp  sz l  ci b ro  r  g  b  a F gb bf th cl  r  g  b  a ns b eat
----------------------------------------------------------------------------
0x05e  0 tc  0  16  0 r  y .   5  6  5  0 .  .  0  0  0  0  0  0  0  0 0 None
0x05f  0 tc  0  16  0 r  . .   5  6  5  0 .  .  0  0  0  0  0  0  0  0 0 None
0x060  0 tc  0  16  0 r  y .   5  6  5  0 .  .  0 16  0  0  0  0  0  0 0 None
0x061  0 tc  0  16  0 r  . .   5  6  5  0 .  .  0 16  0  0  0  0  0  0 0 None
0x062  0 tc  0  16  0 r  y .   5  6  5  0 .  .  0 24  8  0  0  0  0  0 0 None
0x063  0 tc  0  16  0 r  . .   5  6  5  0 .  .  0 24  8  0  0  0  0  0 0 None
0x064 24 tc  0  32  0 r  y .   8  8  8  8 .  .  0  0  0  0  0  0  0  0 0 None
0x065 24 tc  0  32  0 r  . .   8  8  8  8 .  .  0  0  0  0  0  0  0  0 0 None
0x066 24 tc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x067 24 tc  0  32  0 r  . .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x068  0 tc  0  16  0 r  y .   5  6  5  0 .  .  0 16  0  0  0  0  0  0 0 None
0x069  0 tc  0  16  0 r  y .   5  6  5  0 .  .  0 16  0 16 16 16  0  0 0 Slow
0x06a 32 tc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x06b 24 tc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8 16 16 16 16  0 0 Slow
0x06c  0 tc  0  16  0 r  y .   5  6  5  0 .  .  0  0  0  0  0  0  0  4 1 None
0x06d  0 tc  0  16  0 r  y .   5  6  5  0 .  .  0 16  0  0  0  0  0  4 1 None
0x06e 24 tc  0  32  0 r  y .   8  8  8  8 .  .  0  0  0  0  0  0  0  4 1 None
0x06f 24 tc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  4 1 None
0x070  0 dc  0  16  0 r  y .   5  6  5  0 .  .  0  0  0  0  0  0  0  0 0 None
0x071  0 dc  0  16  0 r  . .   5  6  5  0 .  .  0  0  0  0  0  0  0  0 0 None
0x072  0 dc  0  16  0 r  y .   5  6  5  0 .  .  0 16  0  0  0  0  0  0 0 None
0x073  0 dc  0  16  0 r  . .   5  6  5  0 .  .  0 16  0  0  0  0  0  0 0 None
0x074  0 dc  0  16  0 r  y .   5  6  5  0 .  .  0 24  8  0  0  0  0  0 0 None
0x075  0 dc  0  16  0 r  . .   5  6  5  0 .  .  0 24  8  0  0  0  0  0 0 None
0x076 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0  0  0  0  0  0  0  0 0 None
0x077 24 dc  0  32  0 r  . .   8  8  8  8 .  .  0  0  0  0  0  0  0  0 0 None
0x078 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x079 24 dc  0  32  0 r  . .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x07a  0 dc  0  16  0 r  y .   5  6  5  0 .  .  0 16  0  0  0  0  0  0 0 None
0x07b  0 dc  0  16  0 r  y .   5  6  5  0 .  .  0 16  0 16 16 16  0  0 0 Slow
0x07c 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x07d 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8 16 16 16 16  0 0 Slow
0x07e  0 dc  0  16  0 r  y .   5  6  5  0 .  .  0  0  0  0  0  0  0  4 1 None
0x07f  0 dc  0  16  0 r  y .   5  6  5  0 .  .  0 16  0  0  0  0  0  4 1 None
0x080 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0  0  0  0  0  0  0  4 1 None
0x081 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  4 1 None

I say boxswitch because that is what it's called in the KDE system settings window. 
This is what I mean: http://i.imgur.com/kTbh4d1.png

Setting the Scale method to crisp or smooth does away with the delay, so I'm beginning to think that my problem isn't as related to this bug as I first thought. Apologies if that's the case.

you encounter bug #313613 - there's just been a commit disabling lanczos for all intel chips and mesa 9.1

Please: what distribution do you use?

Closing original bug upstream, could be downstream but i blame the plasma theme cache size more than "user chose wrong filesystem", notably as at least (outdated or not) reiserfs is not "wrong" for /var ;-)