Kile 2.1 LaTeX editor is extremely slow

[s_saksonovs]

Hello,

I am using Kubuntu 9.04 Jaunty.
Kile package version is: kile-1:2.1.0~svn942443-0ubuntu3.

Upon launching Kile 2.1 the editor is very slow, e.g. page down page up takes longer than a second, keyboard presses also lag noticeably - it's difficult to select text. Menu operations seem to work fine, and buttons are responsive, just the text editing is very slow.

Upon launching Kile from the command line I get the following output:

kile(14771) KStatusBar::removeItem: KStatusBar::removeItem: bad item id: 302
kile(14771) KStatusBar::removeItem: KStatusBar::removeItem: bad item id: 301
kile(14771) KStatusBar::removeItem: KStatusBar::removeItem: bad item id: 303
kile(14771) KStatusBar::removeItem: KStatusBar::removeItem: bad item id: 304
KComboBox::setTrapReturnKey not supported with a non-KLineEdit.
Object::connect: No such signal KileWidget::ProjectView::dropped(QDropEvent*, QTreeWidgetItem*)
Object::connect: (receiver name: 'KileDocument::Manager')
kile(14771): Shortcut for KAction "tool_BibTeX" "BibTeX" set with QShortcut::setShortcut()! See KAction documentation.
kile(14771): Shortcut for KAction "tool_DVItoPDF" "DVItoPDF" set with QShortcut::setShortcut()! See KAction documentation.
kile(14771): Shortcut for KAction "tool_DVItoPS" "DVItoPS" set with QShortcut::setShortcut()! See KAction documentation.
kile(14771): Shortcut for KAction "tool_LaTeX" "LaTeX" set with QShortcut::setShortcut()! See KAction documentation.
kile(14771): Shortcut for KAction "tool_MakeIndex" "MakeIndex" set with QShortcut::setShortcut()! See KAction documentation.
kile(14771): Shortcut for KAction "tool_PDFLaTeX" "PDFLaTeX" set with QShortcut::setShortcut()! See KAction documentation.
kile(14771): Shortcut for KAction "tool_PStoPDF" "PStoPDF" set with QShortcut::setShortcut()! See KAction documentation.
kile(14771): Shortcut for KAction "tool_QuickBuild" "QuickBuild" set with QShortcut::setShortcut()! See KAction documentation.
kile(14771): Shortcut for KAction "tool_ViewDVI" "ViewDVI" set with QShortcut::setShortcut()! See KAction documentation.
kile(14771): Shortcut for KAction "tool_ViewPDF" "ViewPDF" set with QShortcut::setShortcut()! See KAction documentation.
kile(14771): Shortcut for KAction "tool_ViewPS" "ViewPS" set with QShortcut::setShortcut()! See KAction documentation.

so at least the beginning of this seems like an error message.

Incidentally, perhaps someone can tell me how to use Kile 2.0.3, the latest stable version with KDE4, it complains that QT version is >4 naturally. Can Qt3 and Qt4 co-exist?

Thanks a lot in advance.

[Adymo (adymo)]

Version: (using Devel)
Installed from: Compiled sources

The long text line when word wrapped in kate/kwrite makes everything (like cursor movement, text insertion, etc.) slow. The callgrind profile (attached) suggests that it's because line repaining takes most of the CPU time.

To reproduce, open any file with a long line which would wrap onto 30-40 "view" lines.

What's interesting is that when you move cursor towards the end of the long line, repainting becomes a little bit faster.

[Adymo (adymo)]

Created attachment 27425
The test file where cursor movement is slow because of repainting

[Adymo (adymo)]

Created attachment 27426
Callgrind profile taken during up/down cursor movements in kwrite

[Andreas Pakulat (apaku)]

I think kate devs already dealt with the "problem" here:
http://bugs.kde.org/show_bug.cgi?id=169549

I'm not sure and haven't looked at your data, hence not closing it as duplicate yet.

[Adymo (adymo)]

Yeah, looks like the same problem, but slowdown is tangible even with 5-10 wrapped lines. I don't know if that can be improved though.

[Rodda (rodda)]

I'm aware of these issues and plan to look into them; we may need to switch to having multiple QTextLayouts per dynamically wrapped line :(

[Adymo (adymo)]

As it turns out, to really see the problem, you should be running a NVidia card and using the proprietary driver. On a system with an ATI card (also proprietary driver) you can see the problem, but kate and kwrite are perfectly usable. With nvidia, you can't work with wrapped lines at all.

[Søren Holm (sgh)]

I allso have that problem. What happenend since kde3. On kde3 my nvidia card worked perfectly.

[Søren Holm (sgh)]

Is it possible to somehow make QT4 behave (from a hardware perspective) like QT3 ?

[Adymo (adymo)]

I've just upgraded to Qt 4.5 RC1 (same system with ATI proprietary drivers). The problem is almost solved by the new Qt.

To see the slowdown, you now need to have a long line with more than 15000 characters.

When launched as "kwrite --graphicssystem raster", slowdown disappears completely and kwrite from KDE4 behaves just like kwrite from KDE3.

[Søren Holm (sgh)]

This is great news. Is 4.4.3 and 4.5 rc1 binary compatible ?

[Andreas Wenning (andreas-wenning)]

Try launching kate and doing some writing there; do you notice the same problems with slowness there?

[s_saksonovs (saksonovs-sergejs)]

Thanks for the quick response!

I have tried the same file (which is less than 1000 lines of LaTeX) in Kate and it's faster (in fact, as fast as would be expected). One thing that I should've mentioned is that I set Kile to display text in Courier New (from the standard Microsoft fonts package). Kate shows text in Liberation Mono. Having seen this, I reset Kile to Liberation Mono, I found that it's faster (especially on individual key presses), but still slower than Kate, especially on page down.

[Andreas Wenning (andreas-wenning)]

Kile uses the same text-area component as kate (technically a kate-part), so using the same fonts they should have around the same speed.

Does the slow-down on page up/down happen with all latex-files, or only some; any coincidence with the size of the file?

[Uwe Schilling (uschilling)]

I have also noticed a slowdown in text-editing. I did not change the font style and still text highlighting is sometimes painfully slow and the characters appear or disappear with quite a lag after the key stroke. One more point I noticed is that the autocomplete function for latex commands is _very_ slow. I use only a customized file for completion which is not more than 200 commands long and since I switched to v2.1 I am usually faster just typing the whole command than waiting for autocomplete to come up with a suggestion.

[Andreas Wenning (andreas-wenning)]

I've been working with the 2.1 version for a while without noticing any major showdowns. Is it possible that you have an example of a project you can provide which shows the slow-down?

[Uwe Schilling (uschilling)]

No showdowns so far? How boring, you should change the channel :p

There seems to be no connection between the project size and the slow down. I kept deleting parts of the text and it was still there even with only a few lines of text left. Especially slow is highlighting multiple lines (shift+up/down). I also noticed that scrolling down hardly lags at all on my machine, while when I keep the up key pressed for a while, kile keeps on scrolling for easily for another page or two, depending on how long I pressed it.

I have included a chapter of my diploma thesis. There the describe effects are very visible (at least on my machine).

[s_saksonovs (saksonovs-sergejs)]

I can confirm everything that Uwe said, especially the part about highlighting multiple lines, which is a more precise description of what I originally meant by slow. My files are small and size doesn't seem to matter.

It seems that changing fonts somewhat changes the speed, although it could be subjective - lag is present in all cases, but I think it's less with Liberation Mono and a bit better still with Tahoma and definitely the worst with Courier New 10. I can also confirm that Kate works fine on the same file no matter, which font is set.

[Benjamin von Engelhardt (bve)]

Same here.
Some things I noticed:

Kile is only slow in some files. If multiple files are open in different tabs, I can write fast in some and in some not.

Deleting more and more text in one slow file, I realized that the responsiveness seems to be different in different paragraphs. I can't say that for sure, but I have the impression, that very long lines seem to trigger that effect. If I open a new, empty file, kile is fast. If I add many short lines, \sections etc., it is still fast, until I add a very long line (see attached example). Interesting enough, kile is than only slow, if the long line is shown on my screen. If I scroll up, so that the long line is out of the window, kile behaves fast. Kile gets even slower, if the long line gets longer (see second attachment).

If I have less then about 500 lines in one document, kile seems to become faster (still not really fast, especially when highlighting text with Ctrl+Up oder Down).

[Andreas Wenning (andreas-wenning)]

I can see that it becomes a little slow with the very long lines, but this is the same as when using kate on the same file; no speed difference there. Highlighting lines seems smooth enough and auto-completion normally appears right after typing the second/third letter.

Based on the many reports, there seems to be a problem in some cases; so marking as confirmed.

[Cullmann-t (cullmann-t)]

And therefor there will be no patches to katepart, painting text is expensive, there is not that much room for kate to do it better, still the line needs to be redrawn.

[Søren Holm (sgh)]

still. kde4 kate is a lot slower than the kde3 version.

[Chengkun Huang (huangck)]

I can confirmed this problem with kile 2.1 in Jaunty. When typing a long line, it becomes very slow. Same problem also exists in kate with about 500 characters in one line. I just open kate and kile and start editing by pressing key without releasing. The slowdown is obvious once the line gets long.

[Benjamin von Engelhardt (bve)]

This could be related to
http://bugs.kde.org/show_bug.cgi?id=171099

Following the advice given there, I successfully tried to start kile with

kile --graphicssystem raster

This new QT4.5 feature makes kile workable again.

Ben

[Andreas Wenning (andreas-wenning)]

Changing to --graphicssytem raster really makes kile fly here as well. Let's hope that the raster system is stable enough to be used as default soon for karmic.

[xorkid (syd-shah)]

I don't know why it is marked invalid, I've found this issue too with kile but not with kate.

I fixed it by turning sub-pixel font rendering off in kde systemsetting. (alt-f2 > systemsettings > appearance > fonts click "configure..." next to anti aliasing, turn sub pixel off. you may need to install systemsettings from the repos)

it seems to be related to the new graphics driver for intel which I'm using

[Uwe Schilling (uschilling)]

I can confirm that --graphicssystem raster speeds up kile considerably. Problems remain however, when highlighting lines upwards, if the editor has to scroll.

btw.: sub-pixel font rendering is turned off on my (gnome) system

[Benjamin von Engelhardt (bve)]

turning sub-pixel hinting off worked too, but --graphicssystem raster is even faster. I'm using the new intel driver too, that could explain why Andreas isn't experiencing the same problem.

[s_saksonovs (saksonovs-sergejs)]

I can confirm that graphicssystem raster improves the speed and yet, problems remain with highlighting lines upwards.

[Chengkun Huang (huangck)]

I can also confirm the speed improvement by using "-graphicssystem raster", my graphic card is intel 945GM and using xf86-video-intel-2.7.0 driver. Just hope there is a global setting for all kde applications.

Some information can be found here:

http://swik.net/Trolltech/Trolltech+Labs+Blogs/So+Long+and+Thanks+for+the+Blit%21/cihha

[Andreas Wenning (andreas-wenning)]

The raster graphicssystem is not used as default, as it is not considered stable yet; and some kde components/applications has severe problems when trying to use it.

The general slowness definitely seem to be some qt / graphics related issue.

After getting a clear description of the highlighting slowness I'm actually able to reproduce it now. Thx Uwe. I'm going to check if it exists in a recent svn snapshot, and report it upstream in that case.

[rosy27 (rosy27)]

I have also got the problems. Also got intel graphics. In my case, disabling "dynamic word wrap" brought back the typing speed.

[rosy27 (rosy27)]

...additional information: Subpixelhinting is enabled, and "-graphicssystem raster" did it even with dynamic word wrap set to "follow line number".

[Benjamin von Engelhardt (bve)]

Andreas,

I tried two days ago with a recent svn snapshot (of kile and not katepart) and experienced the same problem.

Ben

[Antoine Pairet (b-ly)]

I also experience this problem and I had like to precise the following:
When scrolling up/down, some lines are reproduced twice. It can take about 30 seconds or more for Kile to recover from this situation.

the option "--graphicssystem raster" does not solve the problem as the screenshots provided are taken with Kile launched with this command:
kile --graphicssystem raster

I do not think it is intel related as suggested above. I am using an ATI graphic card with the -ati driver. I am running gnome with subpixel smoothing enabled. I will test and report back if the behavior changes when disabling subpixel smoothing.

The screenshot should be compared with the latex file attached.

[Antoine Pairet (b-ly)]

Disabling subpixel smoothing does not solve the problem of slowness and line duplication.

ps: sorry for the double post of the .tex file

[keridito (sanan-baena)]

I also experience this issue in ubuntu 9.04., both with kile and kate (I just test kate following the first message of Andreas Wenning) . In my case the option "-graphicssystem raster" solve this. In my laptop the application runs without any incidence.

[Uwe Schilling (uschilling)]

I think it is important to keep in mind that the -graphicssystem raster option is should be a workaround to the problem, not a solution. Since kile 3.0 was able to render the fonts quickly, so should kile 3.1. Seeing switching to a new, faster rendering system as a solution is like saying: I have ten for-loops in my program that do not help the program, but delay it's execution for a few seconds. Instead of removing the for-loops, I switched to a faster machine.

The basic issue most likely remains when using -graphicssystem raster, it is just covered up.

[Ivo Roghair (ivo-82)]

I am also experiencing slow response with the Jaunty provided version of Kile. The about box gives me: "Version 2.0.81, Using KDE 4.2.2 (KDE 4.2.2)", I am running Gnome with subpixel smoothing using a decent free font (liberation mono) and the intel graphics driver (running compiz). I noticed a speedup with the '-graphicssystem raster' command, but still it feels much less responsive than it used to feel in the previous release, especially when selecting text, the selection comes a second later.

[Jonathan Thomas (echidnaman)]

This seems to be another instance of bug 342923 (Kile uses a Kate KPart for text editing)
Bug 342923 happens to be a duplicate of bug 252094.

[Antoine Pairet (b-ly)]

I do experience this slowness but I do not use the intel driver (my card is from AMD and I use the -ati driver). So why is it marked as duplicate of a bug related to the intel graphic driver? There is definitively something I do not understand here!

[Uwe Schilling (uschilling)]

I also don't see why this is supposed to be a duplicate of bug 252094. The problems people are experiencing there started after an update to hardy, while this bug here is a result from an upgrade to jaunty.

[Wouter Charle (wouter-charle)]

I noticed that the speed of Kile is influenced by the size of the editing window. If I edit in full screen, editing text is very slow. Resizing the window to 1/4 the size of my screen remarkably speeds up editing. Further I did not change any settings from the standard configuration. Using the --graphicssystem raster command also speeds up the editor.

[Pieter Hintjens (ph-imatix)]

I can confirm the bug, and the workaround, on two different notebooks that upgraded to 9.04. One is a Thinkpad X61, and one is an ASUS Eee 1000. In both cases, Kate is noticeably slow in all cursor activity, and painfully slow when editing longer lines. Often, characters will appear half a second or a second after typing. By comparison, gedit responds normally. Running "kate --graphicssystem raster" provides a normal experience.

[bernhard (bernhardredl)]

on my ubuntu 9.04 machine ALL kde4 apps are making rendering problems.
Like yakuake > does only display parts of the text.
Amarok. Does only display 1/10 of the folder in the file open dialog. the other folder are just not painted in the control

Or when i click down arrow it paints each element as selected. And only refreshes when i move the cursor over it again
(see the attached image)

i'm using an nvidea. So i can confirm for nvidea too.

Can also confirm: workaround helps a lot

[Ivo Roghair (ivo-82)]

This may be a related issue; if I leave Kile 2.1 open for a while (The window keeps focus until the screensaver starts), and I return to my computer I cannot immediately start to type. I have to minimize or switch to another window, switch back to kile and then it grabs the keys on my keyboard again. Anyone else having this issue? I do start Kile with the raster argument.

[Rlgc79 (rlgc79)]

>This may be a related issue; if I leave Kile 2.1 open for a while (The window keeps focus until the screensaver starts), and I return to my >computer I cannot immediately start to type. I have to minimize or switch to another window, switch back to kile and then it grabs the >keys on my keyboard again. Anyone else having this issue? I do start Kile with the raster argument.

Same problem here.

[Dengji (dengji-zhao)]

The same problem here as Rlgc79 has, sometime even with Kate.
Still very slow even with -graphicssystem raster.

[ratcho (rss-pdx)]

Same problem (Gnome on Ubuntu 9.04). Kile gets super slow and noise appears in the window.

So, I thought, Kile be damned, I'll download TexMaker and use it. The same problem occurs there.

The slow-typing etc. did not occur in open OpenOffice windows.

Restarting fixed it. Like Windows :(

Seems to be some problem in the communication between Kile and (a particular state of) the graphics engine. Just guessing.

[Doughy (doughywilson)]

I also have the slow editing problem with my integrated intel graphics driver. Running Kile with "kile -graphicssystem raster" fixed the problem for me. I also noticed that turning off dynamic word wrap improved the problem. It's almost like the shifting of the lines in dynamic word wrap is extremely slow if you dont use the raster option.

[Félix Beaudoin (felix-beaudoin)]

I have the same problem about slow Kile. When I run it with -graphicssystem raster, it is a lot faster. However, some bugs appear in the window. I actually see the desktop through it instead of the text when I go to another window and back to kile. To get my text again, I have to minimize the window and open it again. Very weird...
It is really annoying since Kile is a very good environment for Latex. I never had any problem with it when I used the Hardy Heron.

[redbrain (oliver2000)]

i installed a fresh Ubuntu jaunty jackalope with kile on my system, and the problem occurs here to. kile -graphicssystem raster helps a bit. But i will downgrade to an older kile version until the bug get fixed.

[Peutch (7-launchpad-peutch-e4ward-com)]

Same problem with me. Running Jaunty with Nvidia driver 180.

In Kile, disabling Dynamic word wrap stopped messing the noise in editor window, and the display bugs that also affected the menus in Kile.
But when scrolling, the lines don't update fast enough. So for instance, if i scroll until line 350 appears, and then I click on that line, the line gets updated, and I discover that I actually clicked on line 379...

The only thing that really prevents Kile display/scrolling from bugging seems the "kile -graphicssystem raster" command line.

The scrolling/menus issue also appears in Okular, when viewing a PDF document for instance.

[Carsten Block (cblock)]

Hi

Running Jaunty / Gnomw on a Lenovo Z61m Kile was originally very slow and unresponsive as described by Uwe. After restarting Kile with --graphicssystem raster command line option the editor now works without any speed issues even if dynamic word wrap is enabled.

Marking multiple lines also works without problems even if some scrolling is involved.

In short: To me --graphicssystem raster option seems to lead to a stable and fast Kile.

[Muelli (ubuntu-bugs-auftrags-killer)]

I had that problem too.
But at least I feel that it's gone with the XServer, Kernel and intel-driver from Karmic. I imagine the poor acceleration performance in Jaunty with Intel graphics was a problem for me. That doesn't explain the problems of NVidia users though.

[ororo (ororo)]

I have a similar problem, but I don't know if it is the same.
In my case, I found out a workaround to make Kile working properly again: I change working space:
Ctrl+Alt+Left, then Ctrl+Alt+Right
and now Kile returns to work with the normal speed.

...very strange...

[Andreas Wenning (andreas-wenning)]

In general this seems to be fixed with the improved kernel/drivers in karmic. Is anyone still experiencing this, as an issue?

[s_saksonovs (saksonovs-sergejs)]

I think it is better in Karmic, even graphicssystem raster does not seem to be necessary anymore.

[Uwe Schilling (uschilling)]

What I still notice is that if I highlight text linewise over more lines
than the screen shows, then it does the highlighting at an irregular
speed. But it is way faster than before, I would say reaction time is
not a problem anymore.

s_saksonovs schrieb:
> I think it is better in Karmic, even graphicssystem raster does not seem
> to be necessary anymore.
>

[Andreas Wenning (andreas-wenning)]

Thanks for reporting back. Glad that improvements in Qt/KDE has solved this.

[Benjamin von Engelhardt (bve)]

> Glad that improvements in Qt/KDE has solved this.

I'm working on ubuntu lucid lynx and still have to use --graphicssystem raster. Otherwise, kile is very slow again. So for me, it doesn't look solved.

[Mark Rose (markrose)]

I am experiencing the same issue with Kate in Lucid. Using --graphicssystem raster fixes the problem. I also experienced the issue in Karmic, and possibly Jaunty (can't remember).

00:00.0 RAM memory: nVidia Corporation MCP78S [GeForce 8200] Memory Controller (rev a2)
00:01.0 ISA bridge: nVidia Corporation MCP78S [GeForce 8200] LPC Bridge (rev a2)
00:01.1 SMBus: nVidia Corporation MCP78S [GeForce 8200] SMBus (rev a1)
00:01.2 RAM memory: nVidia Corporation MCP78S [GeForce 8200] Memory Controller (rev a1)
00:01.4 RAM memory: nVidia Corporation MCP78S [GeForce 8200] Memory Controller (rev a1)
00:02.0 USB Controller: nVidia Corporation MCP78S [GeForce 8200] OHCI USB 1.1 Controller (rev a1)
00:02.1 USB Controller: nVidia Corporation MCP78S [GeForce 8200] EHCI USB 2.0 Controller (rev a1)
00:04.0 USB Controller: nVidia Corporation MCP78S [GeForce 8200] OHCI USB 1.1 Controller (rev a1)
00:04.1 USB Controller: nVidia Corporation MCP78S [GeForce 8200] EHCI USB 2.0 Controller (rev a1)
00:06.0 IDE interface: nVidia Corporation MCP78S [GeForce 8200] IDE (rev a1)
00:07.0 Audio device: nVidia Corporation MCP72XE/MCP72P/MCP78U/MCP78S High Definition Audio (rev a1)
00:08.0 PCI bridge: nVidia Corporation MCP78S [GeForce 8200] PCI Bridge (rev a1)
00:09.0 SATA controller: nVidia Corporation MCP78S [GeForce 8200] AHCI Controller (rev a2)
00:0a.0 Ethernet controller: nVidia Corporation MCP77 Ethernet (rev a2)
00:0b.0 PCI bridge: nVidia Corporation MCP78S [GeForce 8200] PCI Express Bridge (rev a1)
00:10.0 PCI bridge: nVidia Corporation MCP78S [GeForce 8200] PCI Express Bridge (rev a1)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
02:00.0 VGA compatible controller: nVidia Corporation C77 [GeForce 8200] (rev a2)
03:00.0 VGA compatible controller: nVidia Corporation G96 [GeForce 9500 GT] (rev a1)

Using NVidia drivers NVIDIA-Linux-x86_64-195.36.24.

[der_vegi (m-may)]

Same problem here with Lucid all updates applied. If I start Kile normally, it is responsive. But switching the virtual desktop and back again, it gets really slow. Using

kile --graphicssystem raster

seems to fix this for me.

[geos (shapiro-math)]

not solved!

running Lucid with NVIDIA, totally updated. i can say Kile *still* has slow scrolling. it is particularly noticeable for large files ala WordPerfect from the 80's. "kile --graphicssystem raster" improves things.

[geos (shapiro-math)]

also, it is equally sluggish on my Atom/Intel 950 netbook and my AMD/Nvidia desktop.

[molecule-eye (niburu1)]

Typing and deleting characters, especially with automatic spell checking enabled, is very slow (Kubuntu 10.04, KDE 4.4.4). As per the Kile FAQ (http://kile.sourceforge.net/help.php#unresponsiv), I disabled autosave and (not per the FAQ) autocomplete and everything is smooth, except for highlighting large chunks of text. Using the "--graphicssystem raster" option speeds up highlighting especially in the upward direction.

I notice that with automatic spell checking, every time one scrolls the red underlining for incorrect words has to be redrawn by the screen. I suppose this is a katepart "problem" in general.

[Björn (bjoern-kde)]

I noticed that during the slow scrolling the LaTeX structure tree flickers. It looks like it's being updated way too often like once for each single scroll step.

Kile 2.0.85, KDE 4.4.2, Kubuntu 10.04

[Jorge Gustavo (jgr)]

It seems, to me, that this bug was related with nvidia drivers.

I was - finally - able to update nvidia to version 260.19.26 and this Kile performance problem disappear, cf. https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/657634/comments/33

Kile: 2.1.0~svn1112278beta4-2ubuntu1
Nvidia: 260.19.26 (from ppa:ubuntu-x-swat repository)

I would say that this bug should be reopen only if the problem remains with other X drivers.

[Grigory Rechistov (atakua)]

Seems that this issue is still repsent in Lucid x86_64. Kile is slow when working with large documents, to be precise, GUI responsiveness is low.

Starting Kile with '--graphicssystem raster' does help.

And yes, I have an NVIDIA videocard with dirvers (version like 195.36.24-0ubuntu1~10.04)

[Eric J Schwarzenbach (ericjs)]

I realize this issue is very old, but why was this issue resolved as invalid? The last comments do not seem to support "invalid", it seems to me.

I found this issue searching the bug tracker because I am running into painful slowdowns with long lines. I assume it is the same problem, but am unsure if I should comment on this issue or open a new.

[Søren Holm (sgh)]

I think this is still valid although it might be entirely QT reletated.

[anuszka (ochab)]

I still have this slow-down-when-typing problem in Kile.
Kubuntu 17.04, Plasma 5.9.4, "Kate Part Version 3.7 Using KDE Development Platform 4.14.30"

BTW should the fix option be "-graphicssystem raster" or "--graphicssystem raster"? At least when there is a single "-", I am still experiencing the slowdown.