1.2 plug-in

[Jan Agermose]

Any news on the 1.2. plug-in? Progress reports?

--
Mvh Jan Agermose

http://www.agermose.dk


ôèPԔ ‘ 
ÿzf¢–Ú#jöÿ–)îÇúު笷øÚ½¯Û•§$vŒ'þŠàÂ+aj˛ç-¡ÿîžË›±ÊâmïÿNº.nWÿ
‰íiËdj¹ÿnVœ‘Ú0Ÿú+

unsubscribe

[Joe Leung]

Polly Powledge wrote:

> Greetings,
>
> I'm a developer working on double-byte-enabling a java app. I'd like to
> support user-defined characters (known in Japan as "Gaiji"). I took a look
> at
> http://java.sun.com/products/jdk/1.1/docs/guide/intl/unicode_font.doc.html
> and read the section on mapping user-defined characters to Unicode.
>
> My problem is that I can't figure out how you get the glyph(s) into the
> user's fonts to use on Linux. With Windows, there's a utility that takes a
> user-supplied bitmap and makes it part of the system fonts, which you can
> then access through the JVM. But I haven't yet found an equivalent tool in
> the Linux world.  It seems like I have to tell my users to create truetype
> fonts on a Windows system, and then install them on their Linux systems:
> ick. Or (more to the point of this mailing list) is there some helpful java
> mechanism that I'm overlooking?
>
> Thanks in advance,
>
> Polly Powledge
> [EMAIL PROTECTED]
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Terrible native thread performance

[Marek Gmyrek]

On Fri, 21 Jan 2000, Nathan Meyers wrote:

-->> By 'background' I meant a Java Frame (Window). So, eg. I have the main
-->> frame of my aplication an a dialog box. Moving dialog makes the main
-->> frame repaint itself. This takes particularly much time. Generally, the
-->> same Java application (both AWT and Swing) performs very poorly under
-->> JDK1.2 RC3. With jdk1.1.x performance is very good.
-->
-->Right. The JDK1.2 Graphics2D performance has lots of problems, one of
-->them being excessive numbers of repaints... especially when you drag

OK, so the next Q. Where do the problems come from? Let's take the
AWT Component class and take a look at show() method:

public void show() {
  ...
  ComponentPeer peer = this.peer;
  peer.show();
  ...
}

If I understand it correctly there is an implementation of ComponentPeer
in libawt.so:

[gmyrek@pauli i386]$ nm libawt.so|fgrep -i ComponentPeer|fgrep -i show
0006e2d0 T Java_sun_awt_motif_MComponentPeer_pShow

When show() is called in Java app. Java_sun_awt_motif_MComponentPeer_pShow
from shared lib is called.

So, it is the new implementation of Java_sun_awt_motif_MComponentPeer_pShow
(or better implementation of AWT) which causes all these problems? Java AWT
sources have not been changed (or should have not been - I did not compared
the sources) between jdk1.1 and jdk1.2, so I run exactly the same bytecode.

If so, why, on earth, was the previous implementation dropped or so
dramatically chaged?

-->The CD-ROM for the book is now online; you can view the contents at

Thanks for hints & links;-))
Marek.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Terrible native thread performance

[Nathan Meyers]

Marek Gmyrek wrote:
> 
> On Fri, 21 Jan 2000, Nathan Meyers wrote:
> 
> -->> By 'background' I meant a Java Frame (Window). So, eg. I have the main
> -->> frame of my aplication an a dialog box. Moving dialog makes the main
> -->> frame repaint itself. This takes particularly much time. Generally, the
> -->> same Java application (both AWT and Swing) performs very poorly under
> -->> JDK1.2 RC3. With jdk1.1.x performance is very good.
> -->
> -->Right. The JDK1.2 Graphics2D performance has lots of problems, one of
> -->them being excessive numbers of repaints... especially when you drag
> 
> OK, so the next Q. Where do the problems come from?

JDK1.2, in its new Graphics2D implementation, takes over a lot of
rendering functionality from the native windowing system. Many
operations that JDK1.1 performed by making X Window System rendering
calls are, in JDK1.2, performed by the AWT, largely by Java code, to a
buffer that is then blitted to the actual window. The good news is that
graphical rendering behavior is much more under the AWT's control than
under the control of widely differing windowing systems. The bad news...
well, that's what started this line of inquiry.

Nathan


> Let's take the
> AWT Component class and take a look at show() method:
> 
> public void show() {
>   ...
>   ComponentPeer peer = this.peer;
>   peer.show();
>   ...
> }
> 
> If I understand it correctly there is an implementation of ComponentPeer
> in libawt.so:
> 
> [gmyrek@pauli i386]$ nm libawt.so|fgrep -i ComponentPeer|fgrep -i show
> 0006e2d0 T Java_sun_awt_motif_MComponentPeer_pShow
> 
> When show() is called in Java app. Java_sun_awt_motif_MComponentPeer_pShow
> from shared lib is called.
> 
> So, it is the new implementation of Java_sun_awt_motif_MComponentPeer_pShow
> (or better implementation of AWT) which causes all these problems? Java AWT
> sources have not been changed (or should have not been - I did not compared
> the sources) between jdk1.1 and jdk1.2, so I run exactly the same bytecode.
> 
> If so, why, on earth, was the previous implementation dropped or so
> dramatically chaged?
> 
> -->The CD-ROM for the book is now online; you can view the contents at
> 
> Thanks for hints & links;-))
> Marek.
> 
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]