Summary: | Poor performance with long lines | ||
---|---|---|---|
Product: | [Applications] kate | Reporter: | Bram Schoenmakers <me> |
Component: | part | Assignee: | KWrite Developers <kwrite-bugs-null> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | ac_z01, annma, cullmann, dev, diego.ml, ietc, joao.eiras, kde, martinkunev, matt, nt1277, ria.freelander, samchim |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: | Page source of Google News, making Katepart slow |
Description
Bram Schoenmakers
2008-08-21 21:34:48 UTC
Created attachment 26966 [details]
Page source of Google News, making Katepart slow
No chance to fix, this is a 1xxxxx long line, there is no way to handle that fast, for bidi text rendering all must be layouted of one line, no speedup possible, perhaps google should at least put in some newlines somewhere :) OK, I missed the fact that it was only one line. Thanks for your time, though. *** Bug 170322 has been marked as a duplicate of this bug. *** Bug 170322 however does not occur with a one-line file, but a file with several lines with line length of about 700 *** Bug 177773 has been marked as a duplicate of this bug. *** *** Bug 180850 has been marked as a duplicate of this bug. *** *** Bug 189787 has been marked as a duplicate of this bug. *** *** Bug 191467 has been marked as a duplicate of this bug. *** *** Bug 195971 has been marked as a duplicate of this bug. *** This happens on lines of even 300 characters. I admit that 10^5 characters is excessive, but 300 characters is definitely a bug. Any reasonable block of text will have at least that many. (For comparison, this comment is ~200.) *** Bug 200049 has been marked as a duplicate of this bug. *** *** Bug 200707 has been marked as a duplicate of this bug. *** Resolving as wontfix is not a solution for this severe performance problem. There is so much content online that fits lots of content in single lines, for instance http://jqueryjs.googlecode.com/files/jquery-1.3.2.min.js So, people cannot rely on kate/kwrite/konq to text files because it might randomly freeze. (In reply to comment #14) > Resolving as wontfix is not a solution for this severe performance problem. Well, we didn't have the 'upstream' resolution yet back then (I think), else this would be an that. Reason is (as far as I understood kate devs) that kate doesn't provide much room for improvements, the slowness thus mostly comes from our base libraries (i.e. font-rendering with freetype, Qt's rendering, X11, graphics driver). > There is so much content online that fits lots of content in single lines, for > instance > http://jqueryjs.googlecode.com/files/jquery-1.3.2.min.js > > So, people cannot rely on kate/kwrite/konq to text files because it might > randomly freeze. I suggest to try running kate with -graphicssystem raster if you have Qt4.5 or later. That improves rendering speed quite a bit apparently (without it KDevelop is hardly useable on 1 year old laptops due to the extensive highlighting) (In reply to comment #15) > (In reply to comment #14) > > Resolving as wontfix is not a solution for this severe performance problem. > > Well, we didn't have the 'upstream' resolution yet back then (I think), else > this would be an that. Reason is (as far as I understood kate devs) that kate > doesn't provide much room for improvements, the slowness thus mostly comes from > our base libraries (i.e. font-rendering with freetype, Qt's rendering, X11, > graphics driver). It must be a Qt thing though, because this doesn't happen with Gnome. > > There is so much content online that fits lots of content in single lines, for > > instance > > http://jqueryjs.googlecode.com/files/jquery-1.3.2.min.js > > > > So, people cannot rely on kate/kwrite/konq to text files because it might > > randomly freeze. > > I suggest to try running kate with -graphicssystem raster if you have Qt4.5 or > later. That improves rendering speed quite a bit apparently (without it > KDevelop is hardly useable on 1 year old laptops due to the extensive > highlighting) Wow! That is amazing. -graphicssystem raster really makes a big difference. I was using Kile (which just embeds Kate) and it basically removed the lag. Perhaps that should be a default or something? Just to make this clear again: What Christoph said in comment #2 is actually the real problem. If you have a really long line, in bidirectional languages there can be embedded text from left to right and right to left. Drawing a line means we (Qt) *have* to layout the complete line. If the line is very long, this takes time - and quite a lot it seems. Fixing this is mostly a Qt issue iiuc. Pure Qt apps like Qt-Creator seem to work fine with long lines. If the bidi support is really the case of this slowdown, maybe it should be disabled by default so that the minority of users who need it can activate it. Too bad, as I said GEdit deals with this :( Is there a Qt testcase and a Qt bug tracker number? Should this really be UPSTREAM rather than WONTFIX then? The latter probably gives the wrong impression when this is a rather aggravating bug. By the way, -graphicssystem opengl works for me, too, and even better than raster (for systems that support opengl, of course). Come to think of it, I think Konsole exhibits the same behavior. Difference is, I can only use -graphicssystem raster (which does improve performance) not opengl (which causes a strange issue where everything black -- including the menu and dialog texts -- to be transparent). Is this also related to the bidirectional language rendering? Maybe there is a bug already open for Konsole, too. *** Bug 222437 has been marked as a duplicate of this bug. *** *** Bug 210464 has been marked as a duplicate of this bug. *** I created a bug report upstream: http://bugreports.qt.nokia.com/browse/QTBUG-8389 merging bug as the other one has more votes *** This bug has been marked as a duplicate of bug 225228 *** |