jEdit Community - Resources for users of the jEdit Text Editor
Slow paints
Submitted by JMNorris on Friday, 10 April, 2009 - 16:18
I have a new computer and my new installation of jEdit has SLOW window paints/refreshes. My old computer did not have this problem. Refreshes (on opening a new file, scrolling, etc.) snap up with my old installation.

The problem does not occur with at least some other Java apps (eg., Eclipse, SmartSVN) suggesting (but of course not proving) that the problem is not with the JRE. The difference between the two computers does seem to show up with ArgoUML, but I haven't used it enough to know that for sure.

The old compter is a Lenovo T61, the new a Lenovo T400. Both computers are Windows XP, all service packs and other Windows update fixes installed.

Both jEdit installations are v. 4.3pre16. I just upgraded the new computer JRE from 1.6.0, update 11 to update 12. IIRC, the old computer is at update 11.

I tried copying both by ApplicatonData/.jEdit (or, in Micrsoft lingo, ApplicatonData\.jedit) and my Pogram Files/jEdit directories from the old computer to the new computer. It didn't help.

My current Utilities->Global Options->Text Area options include:
Electric (auto scroll) borders [whatever that is]: Off.
Anti Aliased smooth text: none.
Fractional font metrics (for better smooth text display): Off.

At some point, the slowness problem mysteriously (apparently not in response to a settings change) disappeared. However, the slowness reappeared on my next reboot. (I usually try to avoid reboots, preferring stanbys and hibernates. However, this preference is ofeten foiled by the fact that it is Windows.) Could this perhaps suggest that the some setting (fractional font metrics, perhaps) is often ignored???

Any ideas would be greatly appreciated.
Comment viewing options
Select your preferred way to display the comments and click 'Save settings' to activate your changes.
RE: Slow paints
by JMNorris on Wed, 15/04/2009 - 04:28
My problem has been cleared up by backleveling to
Update 7. Not the best of fixes--there have been security updates since then. But it's what I've got.
Are both machines 32 bit? or
by elberry on Fri, 10/04/2009 - 16:57
Are both machines 32 bit? or is the new one 64 bit? Did you increase the heapsize on the old installation, but not on the new one? I'm not quite sure this would get pulled over if you just copied the Program Files directory.


Also, I'm not sure about SmartSVN, but Eclipse runs on SWT which uses a lot more native code to improve performance.

Learn from the past. Live in the present. Plan for the future.
11101000
Blog
 
RE: Slow paints
by JMNorris on Sun, 12/04/2009 - 04:49
Both are 32-bit laptops. If it helps(which I rather doubt), the old one has an nVidia display chip, while the new one has an ATI.

What's REALLY puzzling is that the problem went away briefly for no apparent reason (no configuration changes since the previous slow use) and then reappeared on the next reboot. It would be the best clue I had if I had any idea whatsoever where it leads. Smiling

I'm not sure, but I think SmartSVN uses Swing. ArgoUML, a Swing app, is also fast on the old computer and slow on the new one. The Swing v. SWT suggestion still leaves a few things unexplained. Why then do these Swing do well one the old computer? Why did jEdit briefly work well on the new computer?
 
threads?
by Robert Schwenn on Sun, 12/04/2009 - 10:10
I got the feeling that more and more users are running into problems of slowness. Mostly new hardware (many cores) and/or Windows Vista (even 64 bit) are in the game. But the problem descriptions are not the same.

So, I'm just wondering if it could be a kind of threading issue?
 
Yeah, I've noticed this as we
by elberry on Mon, 13/04/2009 - 21:41
Yeah, I've noticed this as well, there's been more and more complaints regarding slowness.

But from what I've seen they've been more on the 64 bit side.

Could definitely be threading, but in this case considering both machines are set up exactly the same (JVM, etc..) I'm not quite sure what it could be.

As for the Swing vs. SWT thing, I was merely pointing out that Eclipse uses SWT and so is not a good comparison.

Heap sizes are the same right? One thing I can think of is one JVM is running in server mode vs. desktop mode, which the JVM determines based on the number of cores and amount of memory on the machine.
http://java.sun.com/j2se/1.5.0/docs/guide/vm/server-class.html

But from those docs, all windows machines default to client mode.

Learn from the past. Live in the present. Plan for the future.
11101000
Blog
User login
Browse archives
« November 2024  
MoTuWeThFrSaSu
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
 
Poll
Are you interested in language packs for jEdit?
Yes, and I could help maintain translations
26%
Yes, I'd like to have translations
32%
Indifferent
35%
No, that'd be bad (please comment)
7%
Total votes: 1093
Syndication
file   ver   dls
German Localization light   4.4.2.1   101634
Context Free Art (*.cfdg)   0.31   46062
BBEdit scheme   1.0   18601
JBuilder scheme   .001   18502
ColdFusion scheme   1.0   18031
R Edit Mode - extensive version   0.1   17481
Advanced HTML edit mode   1.0   16213
Matlab Edit Mode   1.0   16075
jEdit XP icons   1.0   15236
XP icons for jEdit   1.1   14300