Details
-
Enhancement
-
Resolution: Won't Fix
-
P4
-
None
-
1.4.0
-
sparc
-
solaris_8
Description
customer would like to have the font rendering performance that was achieved using drawByte in 1.1.8 to be the same in 1.4.x using drawString.
See this email:
The case emerged from a discussion our developers had with Munich based Sun
support at our site about two weeks agao. Our developers raised the topic that
font rendering performance has been reduced since 1.1.8 and over the course of
1.2, 1.3 and 1.4 has not returned to the levels they achieved (using drawByte())
with 1.1.8. Their observation was based on their experience writing Java code
over the past years, both with Deutsche Börse applications as well as with their
own productus they have on the market. In the days of 1.1.8 they looked for a
fast way of rendering or displaying simple text strings. They evaluated
different functions and found drawByte offered the best performance. This is why
they chose drawByte. When 1.2 got introduced they realized drawByte was modified
to call a drawString, hence the performance gain which drawByte gave over
drawString was lost. I am not a developer myself but as far as I understand
drawByte was implemented in a way talking to the OS in a more or less direct
fashion, whereas all other calls are using Java 2D (offering benefits like
platform independent look and feel we admit) which take more time to complete.
To discuss this issue we came up with the test case and checked all four
versions 1.1.8, 1.2 , 1.3 and 1.4. We were surprised to see both the actual
difference between 1.1.8 and 1.4 but also the actual difference between 1.3 and
1.4, hence we raised the call. So the call was not (primarily) raised because
profiling the current GUIs (which do not use drawByte because there is nothing
to gain using drawByte) showed a bottleneck drawing text but rather because
developers were unhappy the performance drawByte offered has been taken away
since Java 1.2 and they may not choose between a slower drawString offering some
Java 2D benefits and a quick drawByte offering less functionality any more. The
second reason to raise the call was because of the difference we saw between 1.3
and 1.4.
See this email:
The case emerged from a discussion our developers had with Munich based Sun
support at our site about two weeks agao. Our developers raised the topic that
font rendering performance has been reduced since 1.1.8 and over the course of
1.2, 1.3 and 1.4 has not returned to the levels they achieved (using drawByte())
with 1.1.8. Their observation was based on their experience writing Java code
over the past years, both with Deutsche Börse applications as well as with their
own productus they have on the market. In the days of 1.1.8 they looked for a
fast way of rendering or displaying simple text strings. They evaluated
different functions and found drawByte offered the best performance. This is why
they chose drawByte. When 1.2 got introduced they realized drawByte was modified
to call a drawString, hence the performance gain which drawByte gave over
drawString was lost. I am not a developer myself but as far as I understand
drawByte was implemented in a way talking to the OS in a more or less direct
fashion, whereas all other calls are using Java 2D (offering benefits like
platform independent look and feel we admit) which take more time to complete.
To discuss this issue we came up with the test case and checked all four
versions 1.1.8, 1.2 , 1.3 and 1.4. We were surprised to see both the actual
difference between 1.1.8 and 1.4 but also the actual difference between 1.3 and
1.4, hence we raised the call. So the call was not (primarily) raised because
profiling the current GUIs (which do not use drawByte because there is nothing
to gain using drawByte) showed a bottleneck drawing text but rather because
developers were unhappy the performance drawByte offered has been taken away
since Java 1.2 and they may not choose between a slower drawString offering some
Java 2D benefits and a quick drawByte offering less functionality any more. The
second reason to raise the call was because of the difference we saw between 1.3
and 1.4.