Feature Requests item #521298, was opened at 2002-02-21 19:17
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=438938&aid=521298&group_id=44253
Category: Definitions (source editor)
Group: None
Status: Open
Priority: 5
Submitted By: Peter Centgraf (centgraf)
Assigned to: Peter Centgraf (centgraf)
Summary: Speed Issues under OS X
Initial Comment:
The comments for this feature request are compiled from the mailing list:
Peter Centgraf says:
I know this may not be a popular suggestion, but could we make
it a feature/improvement project to speed up the main editor?
Right now speed is the primary reason why I cannot use Dr. Java
for real programming. According to several online tests, I type
at approximately 60 wpm. This is certainly not expert typing
performance by clerical standards, but it is above average. I
believe it is reasonable to expect Dr. Java to be able to keep
up with this rate of input. Unfortunately, I can type "public
static int" in less time than it takes Dr. Java to display
"public static" with proper coloring. This is simply
unacceptable. Keep in mind that this is running on a reasonably
up to date 500 MHz machine with all Swing acceleration features
turned on.
For comparison, I played with various other Java text
environments. The plain-vanilla text box in MRJAppBuilder had
no trouble keeping up with me. BlueJ will fall behind if I
pound arbitrary characters, and it is clear that some lag is
occurring, but I was not able to produce any "stutter" in my
text input. By the time I raised my finger from the last letter
of a word, BlueJ had always rendered that word. I also played
with JBuilder 6. It was even more responsive. Even pounding
random keys as fast as I could manage, JBuilder still produced
virtually instant response. Both of the last two examples
perform fairly complex syntax coloring. I think that if they
can do this, we can too.
Later:
I attempted the performance workaround that Brian suggested in
class. I commented out the entire body of the
DefinitionsDocument._styleChanged() method and then rebuilt with
ant. It is hard to tell if there is any real change in
performance. Using the same test as before, Dr. Java was able
to update "public static int" fast enough to start drawing "int"
by the time I stopped typing, but it was still several
characters behind what I was currently typing. If I wrote a
larger block of text, like would happen in a comment block,
sometimes entire words of 6-8 characters would lag and seem to
appear all at once. It feels subjectively like there was an
improvement, but I might also be typing slightly slower than I
was earlier today. The window still seems to flicker while I
type, but I think most of that effect is caused by the selection
on the list of open documents. I don't think this "fix" is a
panacea for Dr. Java's performance problems on OS X.
From Brian Stoler:
Here's another speed experiment: Try commenting out the overridden
getViewFactory() in model/definitions/DefinitionsEditorKit. This will turn
off our colored display, but it will still leave the underlying model
implementation going. So, the model will be maintained, but not the color
information will be ignored for the UI.
From Charlie Reis:
Wow-- I can confirm the need to work on speed on OS X. As a CCA, I
have one of the older iBooks (the ugly orange handbag-looking thing),
with OS X 10.0.4 installed. Granted, it's not the fastest machine, but
I can get done typing an entire line before it has shown the first word.
One thing worth noting is that the Interactions pane has acceptable
performance (it's _much_ faster than the Definitions pane). I haven't
tried the suggested fix, but it's worth poking around to see what can be
done...
And the latest installment:
Commenting out getViewFactory succeeds in disabling all drawing in the definitions pane whatsoever. Now all I get is the OS X striped-background where the definitions should be. I'll keep investigating this, however. I agree that it would be very helpful if we can disable the style routines only and keep the reduced model running.
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=438938&aid=521298&group_id=44253
|
