So, in sum, Neo/J will be using Java 1.4.x even if you have 1.5 installed. But at least I have confirmed that 1.5 is not that different from Java 1.4.x.
Good to know. But there doesn't seem to be a Java 1.5 for Panther, and we have quite a few people still running Panther.
For this reason, I would suggest sticking to 1.4 as we should try not to leave too many people in the cold. _________________ "What do you think of Western Civilization?"
"I think it would be a good idea!"
- Mohandas Karamchand Gandhi
Hehe, I had to get at least one more post in that "ignored" you... I guess that this is a suck it and see thing for you. Basically, what you should see improved:
I can add:
- control form are a lot faster to be used now
- the draw module is slower to draw on screen images or object
Thanks for bringing back the old java... on my powerbook 667 going back to patch 3 makes screen drawing much much faster than the newer performance patch versions...
Posted: Wed Nov 16, 2005 9:49 pm Post subject: Found another thing that slows systems down
JKT wrote:
Haxies are the system hacks from Unsanity.com - people use them to add back OS 9 style features such as Windowshading, the classic Apple Menu, etc and for theming OS X. They use the APE (Application Enhancer) system to do this - from their website:
...
There are other system hacks such as Menu Cracker (I use this myself) which allow third-party menu bar items to be added (sorry, but I can't live without iAddressX!) etc, etc.
Add to the list: widgets!
I found this on Macintouch on 11/16/2005
"10:10 EST Dean Waterman tracked down a surprising performance problem:
In response to the people who say that their new PowerBooks are slow, mine was too. I had to get a new one to solve part of the problem, but the new one was still a little slow.
The problem? You would never guess...
My Genius at the Apple Store put the Activity Monitor on my dock so I could open it and see what was going on in the memory and hard drive. I was using the max CPU and memory and could not figure out why. That was until I found the culprit... widgets!
I thought, incorrectly I found out, that when you put widgets aside and cleared them off of the desktop they ceased to work, but that is not the case. Once they get fired up, they are always in the background updating and finding the latest info (if available). This caused many applications to run slow, especially Safari!
The solution, I got rid of most of my widgets. They are primarily a novelty anyway, so why not. If you are running 1GB or higher, you may not notice that much of a difference in getting rid of them, I don't know. But with the stock 512 RAM, you notice a significant difference when they are out of there.
Hope this helps someone. Special thanks goes out to my Mac Genius, Jeremy, at the Apple Store in the Mall of America. He is the best I have ever had. Will ties pretty close, though, in the same store. "
Hope this helps "reduce" the problems with running NeoOffice.
Joined: Sep 18, 2003 Posts: 434 Location: London, UK
Posted: Thu Nov 17, 2005 11:06 am Post subject:
Well, that person must have been using some badly written widgets. Using Dashboard per se will not suck up CPU. For example, I have 19 widgets open at a go and CPU usage is 0% to minimal (until you display Dashboard and then it is 70 to 80% as they become activated). What Dashboard can do is use quite a significant amount of your memory, but that also depends on the widgets you use, and we all know how that can have an impact on NeoOffice/J's performance.
However, knowing when you have a badly written widget installed is something that you'd have to diagnose yourself... so I guess it is another question to ask when troubleshooting. _________________ PBG4, 1.5GHz, SuperDrive, 1GB RAM, 128MB VRAM, 5400rpm 80GB HD, MacOS X 10.4.5
Hehe, I had to get at least one more post in that "ignored" you... I guess that this is a suck it and see thing for you. Basically, what you should see improved:
1. Speed of the interface - menus etc pop-up a lot faster and the overall UI feels faster.
2. Cocoa font system as opposed to the Carbon one of before (a blessing and a curse)
3. More bug fixes
4. Lower memory footprint (half what it used to be)
5. EPS printing support
6. Whatever else Patrick added to his list about the PTPs on the Home page of Trinity
The negatives:
1. Slower loading (perhaps - depends on your fonts) due to the change to the Cocoa font system (see this thread for more details).
2. You get to see the UI paint onto the screen - you get used to it though.
3. There is no 3 as far as I can recall at the moment... perhaps, because it is new and hasn't been as thoroughly tested as the standard patch 3 version, there may be some undiscovered issues...
FYI. After releasing NeoOffice/J 1.1 "Patch-3-With-Java-1.4.x" a couple days ago, I had two major breakthroughs that I felt were too good to not release so I have released I have posted "Patch-3-With-Java-1.4.x-Update-1". This patch includes the following major changes:
1. Startup time - I found that one part of the font loading process was taking at least 15 seconds! By minor reordering of the loading process, I have eliminated this unnecessary delay during startup.
2. Flickering - I finally found a fix for the frequent (and very annoying) toobar flickering that has existed since I first moved Neo/J to Java 1.4.x! This flickering, which was caused by Java 1.4.x's excessive flushing of pixels to the screen, has been nearly eliminated.
"Patch-3-With-Java-1.4.x-Update-1" can be downloaded from the following URL:
Joined: Feb 03, 2004 Posts: 241 Location: Scotland
Posted: Fri Nov 18, 2005 1:37 am Post subject:
Pretty exciting, Patrick, the latest patch! Flicker gone. Faster document load and fast overall loading of application: 33 sec cold on my mac mini. Thanks again for your determination.
On first launch with the latest patch, closing a doc with cmd-W the Save/Discard/Cancel dialogue was almost off the bottom of the screen, but after repositioning it, it displays in the normal place.
"Export to PDF" doesn't use System tools, I guess.
"Print" seems to work correctly until sending information to printer. And then you have to force the application to quit...
This bug was due to a "thread safety" change that I made today to the find a bold/italic version of the current font. I forgot that I on Panther I cannot run any native timers while Java is printing or it will cause a deadlock.
I have reverted this one change and posted "Patch-3-With-Java-1.4.x-Update-1.1". This patch can be downloaded from the following URL:
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
