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 - Future direction brainstorming...
Future direction brainstorming...
 
   NeoOffice Forum Index -> NeoOffice Development
View previous topic :: View next topic  
Author Message
OPENSTEP
The One
The One


Joined: May 25, 2003
Posts: 4752
Location: Santa Barbara, CA

PostPosted: Tue Jul 29, 2003 8:45 pm    Post subject:

Oh frig. Yup, with Cocoa all the Yields need to be in the main thread. If you poke inside of the Aqua vcl_HandleEvent() function inside of Neo (I think that's the right one), you'll see all kinds of convoluted mutex guards and communication to try and dispatch yields to the main thread to fetch the event, pass the event back to the yielding thread, then continue on in the thread. Watch out doing this, however, as some AppKit calls also need to be called from the main thread, so continuing to handle the event off of the main thread can lead to further thread safety issues. Unfortunately, Apple hasn't documented what parts of AppKit are thread safe and which are absolutely required to be invoked on the main thread...it's all kind of trial and error. But definitely things that are poking around with the event queues need to be on the main thread from my experience.

The good news for 1.0.3 over 638C is that most, but not all, of the SalApp::Yields tend to be on the same thread, so if you can find a way to finesse the event handling onto the main thread then you may be golden.

There was an easy way to schedule calls to execute on the main thread synchronously in Carbon with the MPRemoteCall() function (that is a link). I'm not sure if it could be helpful for you.

This is another reason why, for really nitty gritty work, I've still received some "off-hook" advice that it's somewhat easier to stick with carbon Mad

ed
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Tue Aug 05, 2003 11:11 am    Post subject:

Ed,

Well I finally figured out how to get Java 1.4.1 to work within NeoJ (and OOo). Unfortunately, it really messes up OOo. As you probably know, OOo tends to have an expectation of which thread follows which thread. As a result, the OOo threads have a tendency to yield only to each other and, as result, the Java event dispatching thread never runs or runs too infrequently.

Also, I found that most of the problems with Java 1.4.1 were due to incompatibilities arising from loading the JavaVM framework in a library loaded via UNO. I finally figured out that this loading of the JVM in UNO causes the Cocoa code within the JVM to not be able to find the functions that are registered for the java.awt.* native methods.

Not suprisingly, if you make an executable that is linked to both the Cocoa and the JavaVM frameworks, you can use the Java Invocation API to create a JVM and you can draw simulatenously in multiple pthreads. Of course, I still need to start the Cocoa run loop first, but it never crashes.

Lastly, I found that even if I hack up NeoJ to load Java without going through UNO, it works but the Font.layoutGlyphVector() method does not do any ligature or style replacement. Of course, if you do this in test program that I mentioned above, liguture and style replacement work perfectly. I suspect that this is due to lazy binding of Cocoa since in OOo main() is in a shared library.

So what does all of this mean? Well, it basically means that Java 1.4.1 is no longer the easy way to enable ligature and style replacement in text drawing. In fact, I have found that Mac OS X's Java 1.4.1 implementation is so fussy when run via Java Invocation API, that I am abondoning work on it and redirecting my time to something more useful: printing.

The good news is that just because we cannot use Java 1.4.1 on Mac OS X does not mean we can't support ligature and style replacement. When we upgrade to the OOo 1.1 code, we can use ICU's text layout engine. ICU is a required component in OOo 1.1 and so their layout engine comes at a very minimal cost and is platform independent. The only downside is that ICU will probably not handle the style replacement for fonts like Apple Chancery but ICU should be able to handle language dependent ligature and style replacement (i.e. Arabic).

I did leave the stoc and vcl code in the neojava cvs module for those that are interested in Java 1.4.1 on Mac OS X. However, since stoc modifications are not part of the build, NeoJ will still load Java 1.3.1.

Patrick
Back to top
Display posts from previous:   
   NeoOffice Forum Index -> NeoOffice Development All times are GMT - 7 Hours
Goto page Previous  1, 2
Page 2 of 2

 
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.