Artur Biesiadowski wrote:
> Michael Emmel wrote:
>
> [...]
> > Also Check out
> > http://www.ishtek.com/ishtek2d.htm
> >
> > Its not exactly complete and there seems not to have a license.
> > Can this be contributed to Classpath. Its worth having IMHO.
>
> It is pure java. From one side, it would be great to have 100% pure
> implementation of Java2D, but I wonder if it is possible to get anything
> even remotely useable in terms of speed without use of hardware
> acceleration. Do anybody here knows both Java2D and current
> possibilities of 2d graphics card acceleration and can say if it is
> possible to heavily optimize Java2D operations with it ? (I'm not
> talking about clipping, but about automatic apply of AffineTransforms,
> alpha compisites etc).
>
First I don't think this is a simple question of C vs Java.
Sun made a huge mistake not designing a plugin api for second stage
render in java2D.
First the rendering engine is basically broken into two parts.
The "high" level path definition which contain complex curves and the
Low level rendered path which consists of uncrossed closed paths defined
only with line segments.
Regardless the implementation method is dependent more on what JVM/OS
/Hardware its running on.
Well there are good reason to have 100% java rendering engines where
absolute speed is not
important. Basically anywhere your not rendering for interactive Screen
use.
Also the quality of the jit or optimizing compiler would determine of a
100% java engine was
adequate. Most of the rendering equation are basically pure math so any
good jit with inline abilities
should produce code equal or better than a C based engine. I say better
because the jit could inline
move code where the C based one would probably not be able to inline
across the JNI interface.
So if you don't have a good jit you need to write one before considering
optimization java2D.
Next the next question is can you get direct access to the hardware
framebuffer and or
acceleration routines ?
If so then you need to design you low level api to take advantage of it.
Note XFree86 supports some direct framebuffer access. It would be nice if
the also exposed the
acceleration routines in a "standard" way if possible. Plus you can roll
you own driver.
I've written display drivers almost entirely in java. For the X86 on linux
I had C code for
inb outb and mmap the display buffer. I have not used the code with a good
jit but simply
doing some loop unrolling in java gave surprisingly good performance. Say
10 times slower than native code.
This was about three years ago before the "modern" VMs : ) Before java1.1
for that matter.
Any way the code with unrolled loops seem to be slowed only by the
interpreter.
If you don't have access to the frame buffer then regardless of how much
of java2D is implemented in C it will be slower than the "native" system
for direct on screen drawing.
For Open Source operating systems this is not really and issue.
Now the issue of high vs low level by splitting the rendering between these
two api's it is possible
to get the low level rendering engine on a fairly small device. This
requires the Shapes be pre rendered to the
Data Structure used by the low level engine but it's easily doable. Such a
design is very interesting for
devices which are small but connected to a network. For example the other
day I was at a gas pump
at a Shell gas station. The display for the computer was in color but it
looked horrible especially the Shell
emblem. Pre rendering such emblems and even the text to a low level vector
format would enhance such
displays quit a bit. And ATM for example would also benefit from having a
low level vector engine.
Again you need to define a good api between the two stages of the
rendering engines.
The correct implementation the best implementation of the second stage
rendering engine is
very dependent on the platform. Sun made a huge mistake not designing a
plugin api for java2D.
Now the way I plan on dealing with java2D after defining a plugin api is
quit different from the
normal C vs Java approach. What I plan to do is move the implementation
decision where it belongs
not in the Java2D classes but leave it up to the JVM/OS/Jit.
I call this jit a signature compiler.
Here is how it works.
You write a jit which hooks the JVM's jit api and watches for certain
classes to be loaded
in our case java2D. As the class is loaded it can use "special"
optimizations which depend on
the configuration of the particular machine. These include the OS, Video
Card, JVM , Processor.
A simple example would be the the use of vector instructions some of the
newer CPU's. Plus
the jit can not only cover the bytecode to processor instructions but also
replace them with and tuned
native code are direct hardware calls to acceleration function on the
graphics coprocessor.
Especially important would be if the card supports alpha values for
example.
Also you need too do gamma correction for the monitor.
A portable C implementation on top of a native windowing system is not
good enough by a long shot IMHO.
By moving the native implementation of the low-level graphics engine into
a jit. We have a slow but
portable java api. And the jitgc ( just in time graphics compiler : ) Can
produce the best graphics engine
possible. At worst it simply replaces the java implementation with pre
compiled native code. Which is almost equivalent to writing it in C to
the JNI api but you can still take advantage of a lot of runtime
information such as the exact video configuration processor main memory
etc Which methods are fastest and should be inlined. The screen
resolution would be useful for loop unrolling. And once the code is
inlined global optimizations can be used. And you can optimize the
translation of the remaining bytecode to native code. Maybe even using
special optimizations which only hold since you know the functional
requirments for the method from its signature.
You could also decide on buffering algorthims based on the amount for
graphics/main memory etc.
More important by moving behind the JIT interface as apposed to JNI these
decisions can be made
when the JVM is implemented or installed on the device. This is how the
X11 server are done.
You could of course load
I suspect that a lot of Sun's "Client" hotspot compiler is simply the
first incarnation of a jitgc.
Thus as far as I'm concerned the way to go is to write a good 100% java
java2D implementation
with the best algorithms that are also amenable to a jit and a killer
jitgc.
Mike
