Posted: Sun Aug 14, 2005 4:02 pm Post subject: NeoOffice/J 1.2 Alpha
I've finished building NeoOffice/J 1.2 Alpha and found a problem with the marking of the insertation prompt. It is not there. Just one small thing to look at.
Ok. It is taking a real long time to load and run, too.
You've ran into the Tiger JVM bug that I have been working on for the last few days. Seems that Apple, in their haste to get Tiger out the door, made some shortcuts in the JVM with graphics accelerated images. I am in the process of refactor all of the image drawing code to work around this Tige bug.
Ok. It is taking a real long time to load and run, too.
You've ran into the Tiger JVM bug that I have been working on for the last few days. Seems that Apple, in their haste to get Tiger out the door, made some shortcuts in the JVM with graphics accelerated images. I am in the process of refactor all of the image drawing code to work around this Tige bug.
Thank you for the update, Patrick. I look forward to a solution. Maybe this is why the prompt did not appear correctly in writer and calc.
I see over at the ADC site (connect.apple.com) that Apple is preparing a 1.3.1 and 1.4.2 JVM update for 10.4; maybe this has a fix for the image bug?
I read the release notes and it doesn't look like they are changing the graphics acceleration features in Java 1.4.2 on Tiger. The good news is that I have already made changes to the code to handle this issue. The key is that graphics acceleration is always on in Java 1.4.2 (with Java 1.3.1 I explicitly turned it off) so I just needed to be more careful about accessing an images bits directly.
I see over at the ADC site (connect.apple.com) that Apple is preparing a 1.3.1 and 1.4.2 JVM update for 10.4; maybe this has a fix for the image bug?
I read the release notes and it doesn't look like they are changing the graphics acceleration features in Java 1.4.2 on Tiger. The good news is that I have already made changes to the code to handle this issue. The key is that graphics acceleration is always on in Java 1.4.2 (with Java 1.3.1 I explicitly turned it off) so I just needed to be more careful about accessing an images bits directly.
Patrick:
Has this made it to HEAD?
Also, does disabling graphics acceleration make NeoJ faster? This was the case with some of the graphics cards that I worked with on the Intel side of life (really poorly writted graphics card driver interfaces through OpenGL made life a nightmare when testing OS/2.)
Yes, the changes are in HEAD. I even committed some small improvements today.
Note that I do commits nearly every day as I hate holding massive amount of code on my local disk for very long. Some developers don't like this approach, but I have found that it is easier to aggregate my many, frequent, small commits than it is to disaggregate a big massive commit. Plus, my develop steps, both good and bad, get saved for perpetuity.
So, if you want to keep up with the latest code, here's some shortcut steps that I use so that you don't require rebuilding entire modules:
1. cd into the "neojava" directory within your workspace and execute "cvs update -d". Do *not* go into the "neojava/build" directory as that is the OOo build and that is not changing.
2. Execute "source build/MacosxEnvJava.Set" to set the required build environment variables.
3. cd into a Neo/J module with any updates (i.e. "vcl" and "dtrans") and invoke build to recompile any updated files.
4. Rebuild the patch installer (note: your full installer won't be fully updated, but who cares at this stage) by executing "rm build.patch_package ; make build.patch_package"
jjmckenzie51 wrote:
Also, does disabling graphics acceleration make NeoJ faster? This was the case with some of the graphics cards that I worked with on the Intel side of life (really poorly writted graphics card driver interfaces through OpenGL made life a nightmare when testing OS/2.)
In some areas yes and some no. In general, with all my refactoring of the code, Neo/J is about as fast as it was with Java 1.3.1. Realistically, the biggest problem with speed is not Java but is XORing. OOo expects XOR of the window's pixels to be very fast. However, this is very slow with Mac OS X's Quartz2D graphics contexts so XORing is done the slow way: iterate through the bounding rectangle that is being XORed and XOR each pixel.
Yes, the changes are in HEAD. I even committed some small improvements today.
Thank you. I don't want to do daily builds, but I can do what you suggested.
pluby wrote:
Note that I do commits nearly every day as I hate holding massive amount of code on my local disk for very long. Some developers don't like this approach, but I have found that it is easier to aggregate my many, frequent, small commits than it is to disaggregate a big massive commit. Plus, my develop steps, both good and bad, get saved for perpetuity.
So, if you want to keep up with the latest code, here's some shortcut steps that I use so that you don't require rebuilding entire modules:
1. cd into the "neojava" directory within your workspace and execute "cvs update -d". Do *not* go into the "neojava/build" directory as that is the OOo build and that is not changing.
2. Execute "source build/MacosxEnvJava.Set" to set the required build environment variables.
3. cd into a Neo/J module with any updates (i.e. "vcl" and "dtrans") and invoke build to recompile any updated files.
4. Rebuild the patch installer (note: your full installer won't be fully updated, but who cares at this stage) by executing "rm build.patch_package ; make build.patch_package"
Thanks for these suggestions.
pluby wrote:
jjmckenzie51 wrote:
Also, does disabling graphics acceleration make NeoJ faster? This was the case with some of the graphics cards that I worked with on the Intel side of life (really poorly writted graphics card driver interfaces through OpenGL made life a nightmare when testing OS/2.)
In some areas yes and some no. In general, with all my refactoring of the code, Neo/J is about as fast as it was with Java 1.3.1. Realistically, the biggest problem with speed is not Java but is XORing. OOo expects XOR of the window's pixels to be very fast. However, this is very slow with Mac OS X's Quartz2D graphics contexts so XORing is done the slow way: iterate through the bounding rectangle that is being XORed and XOR each pixel.
Blame this on the way that Windows does a repaint of the screen. It is amazingly slow however.
In some areas yes and some no. In general, with all my refactoring of the code, Neo/J is about as fast as it was with Java 1.3.1. Realistically, the biggest problem with speed is not Java but is XORing. OOo expects XOR of the window's pixels to be very fast. However, this is very slow with Mac OS X's Quartz2D graphics contexts so XORing is done the slow way: iterate through the bounding rectangle that is being XORed and XOR each pixel.
Has that changed with the new Tiger graphics methods or is Tiger equally slow? _________________ "What do you think of Western Civilization?"
"I think it would be a good idea!"
- Mohandas Karamchand Gandhi
Has that changed with the new Tiger graphics methods or is Tiger equally slow?
What Jim is seeing (which is before I fixed that problem) happens only on Tiger. Last week I was working on Panther and happy that the Java 1.4 code was drawing about as fast as the Java 1.3.1 code. Then, I booted into Tiger and ran my code and I was horrified to see that it took at least 10 times as long for any painting operation to execute on Tiger than on Panther!
Fortunately, the hardest part was finding what the idiosyncracy in Java 1.4 on Tiger was. Once I found that, fixing the bug wasn't too hard and with today's commits, the speed on Tiger is back to about the same as on Panther.
I don't know if this applies only to applet GUI or to any sort of drawing in Java (the majority of the drawing is not what I'd call "GUI" per se), but http://segal.org/java/CanvasTable3/index.html claims that Java 1.4/1.5 is about 4x slower on Mac OS X than Java 1.3.1.
Smokey _________________ "[...] whether the duck drinks hot chocolate or coffee is irrelevant." -- ovvldc and sardisson in the NeoWiki
Has that changed with the new Tiger graphics methods or is Tiger equally slow?
What Jim is seeing (which is before I fixed that problem) happens only on Tiger. Last week I was working on Panther and happy that the Java 1.4 code was drawing about as fast as the Java 1.3.1 code. Then, I booted into Tiger and ran my code and I was horrified to see that it took at least 10 times as long for any painting operation to execute on Tiger than on Panther!
Fortunately, the hardest part was finding what the idiosyncracy in Java 1.4 on Tiger was. Once I found that, fixing the bug wasn't too hard and with today's commits, the speed on Tiger is back to about the same as on Panther.
Thanks for the fix, Patrick. However, the insertation marker in calc is still not 'there'. Also, there are drawing anomolies, like the lines around the highlighted row/column are not straight. However, the colors do change!
I guess I will have to look at the Bugs area and see if I can find/confirm bugs.
And I did build it with SRX645_m57, which Eric B. is having problems committing your changes to. I guess it is time to print out the JCA and send it in. I'll have to pay for the fax at about USD 1 per page unless I can find a less expensive place to work with. I will be travelling to the University of Arizona tonight/tomorrow as the SO is attending there. Classes start on Monday and she is looking forward to starting them.
The line is: My wife and my money go to the U of A.
Thanks for the fix, Patrick. However, the insertation marker in calc is still not 'there'. Also, there are drawing anomolies, like the lines around the highlighted row/column are not straight. However, the colors do change!
I guess I will have to look at the Bugs area and see if I can find/confirm bugs.
I suspect that you didn't get a full update of the code in the vcl module. When you invoke "cvs update -d" in the neojava/vcl directory, do you get any files listed with a status of "M" or "C"? If so, these files aren't being updated as "M" means modified and "C" means conflict and cvs will bypass those files. If you get any of these, delete those files, reinvoke "cvs update -d", and rebuild.
BTW, there are no bugs for the Java 1.4.2 code in Bugzilla yet as you and I are the only people who have used the new code.
jjmckenzie51 wrote:
And I did build it with SRX645_m57, which Eric B. is having problems committing your changes to. I guess it is time to print out the JCA and send it in.
That's not surprising. I may be wrong, but I have had the impression that Eric B. and Eric H. are good at fixing OOo build breakages, but they haven't been doing any substantial amount of coding in the year that they have been working on OOo.
All times are GMT - 7 Hours Goto page 1, 2, 3, 4, 5, 6, 7Next
Page 1 of 7
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
)