Welcome to NeoOffice developer notes and announcements
NeoOffice
Developer notes and announcements
 
 

This website is an archive and is no longer active
NeoOffice announcements have moved to the NeoOffice News website


Support
· Forums
· NeoOffice Support
· NeoWiki


Announcements
· Twitter @NeoOffice


Downloads
· Download NeoOffice


  
NeoOffice :: View topic - NeoOffice/J 1.2 Alpha
NeoOffice/J 1.2 Alpha
 
   NeoOffice Forum Index -> NeoOffice Development
View previous topic :: View next topic  
Author Message
jjmckenzie51
The Anomaly


Joined: Apr 01, 2005
Posts: 1055
Location: Southeastern Arizona

PostPosted: 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.

James
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Sun Aug 14, 2005 5:13 pm    Post subject:

There are far, far more issues than that. If that is the only issue that you are seeing, then you aren't looking too closely. Wink

Patrick
Back to top
jjmckenzie51
The Anomaly


Joined: Apr 01, 2005
Posts: 1055
Location: Southeastern Arizona

PostPosted: Sun Aug 14, 2005 6:41 pm    Post subject:

pluby wrote:
There are far, far more issues than that. If that is the only issue that you are seeing, then you aren't looking too closely. Wink


Ok. It is taking a real long time to load and run, too.

I guess I'll have to look through the Bugs list, right?

James
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Sun Aug 14, 2005 8:22 pm    Post subject:

jjmckenzie51 wrote:
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.

Patrick
Back to top
jjmckenzie51
The Anomaly


Joined: Apr 01, 2005
Posts: 1055
Location: Southeastern Arizona

PostPosted: Sun Aug 14, 2005 9:20 pm    Post subject:

pluby wrote:
jjmckenzie51 wrote:
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.

James
Back to top
sardisson
Town Crier
Town Crier


Joined: Feb 01, 2004
Posts: 4588

PostPosted: Sun Aug 14, 2005 10:47 pm    Post subject:

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?

(One can dream, right? Smile)

Smokey

_________________
"[...] whether the duck drinks hot chocolate or coffee is irrelevant." -- ovvldc and sardisson in the NeoWiki
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Tue Aug 16, 2005 8:02 pm    Post subject:

sardisson wrote:
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
Back to top
jjmckenzie51
The Anomaly


Joined: Apr 01, 2005
Posts: 1055
Location: Southeastern Arizona

PostPosted: Wed Aug 17, 2005 7:22 am    Post subject:

pluby wrote:
sardisson wrote:
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.)

James


Patrick[/quote]
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Thu Aug 18, 2005 5:38 pm    Post subject:

jjmckenzie51 wrote:
Has this made it to HEAD?


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.

Patrick

Patrick
Back to top
jjmckenzie51
The Anomaly


Joined: Apr 01, 2005
Posts: 1055
Location: Southeastern Arizona

PostPosted: Thu Aug 18, 2005 6:52 pm    Post subject:

pluby wrote:
jjmckenzie51 wrote:
Has this made it to HEAD?


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.

James
Back to top
ovvldc
Captain Naiobi


Joined: Sep 13, 2004
Posts: 2352
Location: Zürich, CH

PostPosted: Thu Aug 18, 2005 10:34 pm    Post subject:

pluby wrote:
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
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Thu Aug 18, 2005 10:57 pm    Post subject:

ovvldc wrote:
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.

Patrick
Back to top
sardisson
Town Crier
Town Crier


Joined: Feb 01, 2004
Posts: 4588

PostPosted: Thu Aug 18, 2005 11:18 pm    Post subject:

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
Back to top
jjmckenzie51
The Anomaly


Joined: Apr 01, 2005
Posts: 1055
Location: Southeastern Arizona

PostPosted: Fri Aug 19, 2005 9:37 am    Post subject:

pluby wrote:
ovvldc wrote:
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.

James
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Fri Aug 19, 2005 10:56 am    Post subject:

jjmckenzie51 wrote:
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. Wink

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.

Patrick
Back to top
Display posts from previous:   
   NeoOffice Forum Index -> NeoOffice Development All times are GMT - 7 Hours
Goto page 1, 2, 3, 4, 5, 6, 7  Next
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

Powered by phpBB © 2001, 2005 phpBB Group

All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © Planamesa Inc.
NeoOffice is a registered trademark of Planamesa Inc. and may not be used without permission.
PHP-Nuke Copyright © 2005 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.