From: SourceForge.net <no...@so...> - 2009-04-16 20:52:00
|
Bugs item #2634478, was opened at 2009-02-24 10:28 Message generated for change (Comment added) made by ezust You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100588&aid=2634478&group_id=588 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: editor core Group: Regressive (new to devel) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Lukas Jirkovsky (stativ) >Assigned to: Kazutoshi Satoda (k_satoda) Summary: 4.3pre16: slowdown with antialiased text Initial Comment: If text is set to be antialiased scrolling in jEdit becomes significatly slow and cpu utilization jumps to 100%. Everything was tested with clear .jedit directory and all plugins disabled (first time from plugin manager, then with -noplugins). This doesn't occur with no anti aliasing and subpixel hinting. Disabling fractional font metrics doesn't make any change as all other setting in Text Area settings. OS Archlinux current. Sun's java 1.6 u11. Architecture is i686. ---------------------------------------------------------------------- >Comment By: Alan Ezust (ezust) Date: 2009-04-16 13:51 Message: I think perhaps we need to revert the change which removes the FastRepaintManager and make it an option one can switch on/off, don't you agree Kazutoshi? ---------------------------------------------------------------------- Comment By: Jocelyn Turcotte (jturcotte) Date: 2009-03-15 19:05 Message: I did a dichotomic revert on the trunk to find the source of this problem. The problem starts when updating to revision 13533 or higher. This fast repaint manager did seem to improve something after all. This bug is really more noticeable on my ubuntu machine (especially when there is a lot of text on the screen). On windows I can operate with 4.3r17 without noticing it. ---------------------------------------------------------------------- Comment By: Lukas Jirkovsky (stativ) Date: 2009-03-07 00:40 Message: voituk, If you have nVidia graphics card, you should try their latest beta release. Quote from the changelog: "Fixed a problem that could cause Xid errors and display corruption in certain cases when OpenGL is used to render to redirected windows, for example when Java2D is used with the -Dsun.java2d.opengl=true option." ---------------------------------------------------------------------- Comment By: Voituk Vadim (voituk) Date: 2009-03-02 14:30 Message: Alan, just tried few game from java2k contest - works fine. Except of jEdit. :( Anyway, i don`t think that it is common problem - seems like problems related to my laptop or my OS. ---------------------------------------------------------------------- Comment By: Alan Ezust (ezust) Date: 2009-03-02 07:43 Message: voituk, does anything else using GL work for you? If not, it might be a problem with your video driver. ---------------------------------------------------------------------- Comment By: Lukas Jirkovsky (stativ) Date: 2009-02-28 01:36 Message: Thanks, using OpenGL helped me. current svn without the patch – scrolling as fast again with cpu utilization around 30% (exactly it was 28%-31%) current svn with your patch – scrolling is fast, CPU utilization varies from 8% to 35%, most of the time it was less than 15%) ---------------------------------------------------------------------- Comment By: Voituk Vadim (voituk) Date: 2009-02-27 15:00 Message: I`ve just tried to start jEdit with -Dsun.java2d.opengl=true option - nothing renders except of window border + title. Windows Vista 32bit + jEdit rev.14407 + JDK 1.6u11 ---------------------------------------------------------------------- Comment By: Kazutoshi Satoda (k_satoda) Date: 2009-02-27 10:45 Message: Comparing the reports and my local profiling, I remembered that I have a JVM option "-Dsun.java2d.opengl=true" in my environment. http://java.sun.com/javase/6/docs/technotes/guides/2d/flags.html#opengl This option seems to move the bottleneck from painting to layoutGlyphVector(). Thus, my patch works much better with this option. Could you please test the performance with this option? (and, with both this option and my patch?) ---------------------------------------------------------------------- Comment By: Lukas Jirkovsky (stativ) Date: 2009-02-26 09:24 Message: I've just tested it and it may be a bit faster, but compared to the other settings (none/subpixel) it's still terribly slow. It's possible that it's more visible on my computer because it's quite old (Pentium4 northwood @2GHz, graphics Nvidia 6200LE (drivers 180.35)). If I can do some testing to help you fix it, I'll be glad to do it (if it's possible). Just ask. ---------------------------------------------------------------------- Comment By: Jocelyn Turcotte (jturcotte) Date: 2009-02-25 19:41 Message: Forget my last comment, I probably ended using the wrong version when I verified. Sorry about that. I attached a quick jvisualvm profile difference between trunk r14663 and 4.3pre15 while scrolling. Hope this gives a hint. File Added: jvisualvm_pre15vsTrunk.png ---------------------------------------------------------------------- Comment By: Jocelyn Turcotte (jturcotte) Date: 2009-02-25 18:38 Message: This patch does correct the problem. Without: laggy during heavy scrolling using 100% of one core With: smooth during heavy scrolling using around 40% of one core on Ubuntu with Sun java 1.6.0_10 ---------------------------------------------------------------------- Comment By: Kazutoshi Satoda (k_satoda) Date: 2009-02-25 09:49 Message: If this didn't happen on 4.3pre15, it is likely caused by removal of FastRepaintManager. http://jedit.svn.sourceforge.net/jedit/?view=rev&rev=13533 While I can't reproduce the serious performance problem on my machine (Windows XP + JDK 6u11), jProfiler shows that layoutGlyphVector() is consuming much CPU. So I made a experimental patch to introduce a cache of GlyphVector instances. Could someone please test the patch? File Added: cache_GlyphVector.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100588&aid=2634478&group_id=588 |