Nathan Meyers wrote:

> Rob Clark wrote:
> >
> > For what it is worth, I see the same problem under xfree86 at 16bpp,
> > so I am not sure that it is an Xvnc problem.
> >
> > What is involved in adding support for new color depths?  I would like
> > to drop support for older versions of JDK for an application that I am
> > developing that I would be willing to volunteer to help, if possible.
>
> If you can solve your immediate problems by running your X server in an
> 8-bit mode, do it.
>
> The JDK is not open source, and you'll need to jump through some hoops
> to contribute to the Blackdown port. If it's really, really important to
> your work that you fix the JDK, be prepared to dive into Java2D code
> that is, I'm sure, nice and hairy.
>

Well I did and extensive review of Java2D and yes its very hairy.
There are mutiple pipelines and its not very clear to me at least which one
gets
used when. Plus the are many cases where there is way to many object getting
created.

I think the Java2D implementation  illustrates a basic weakness with the java
language
how do you operate on a "primitive" type such as color wich can be defined many
diffrent ways.

If the java language had the ability to define new primitive types based on the
current ones then
I think it would be much easier to implement Java2D.

If you could  even just  transform and array of ints into a array of bytes and
vice versa then it would be great!

Classes like this should compile in java.

public class byteInt[] extends int[] {

    /**
     * Provides a view of a int array as and array of bytes
     * data is shared between int and byte view
      **/
    native byte[] asByteArray();
}

byteInt[]  myInts = new byteInt[10];

byte[] myByte = myInts.asByteArray();  //   views a byteInt as a byte array
"big endian"

You can do this by shifting and copying  but its very inefficient.  There are
many more "Array" operations needed for graphics  that
there missing or  impossible to implement efficiently directly  in the java
language.

Some of these issues could be fixed by special optimizations for loops wich
perform operations on primitive data.
There is no reason such loops cannot run at native speeds.

Mike




But once you get through how it works adding yet  another bit depth is not that
hard.



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

Reply via email to