The solutions are very OS specific.  
Author Message
Jeff Relf





PostPosted: 2004-6-18 8:30:00 Top

java-programmer, The solutions are very OS specific. Hi Mark Thornton,

You wrote,
" The rough equivalent to an HDC is
a java.awt.Graphics object,
extended ( since Java 1.2 ) to java.awt.Graphics2D.
These are used for drawing to screens, printers
or into a BufferedImage. "

That's quit impressive,
But my bank simulation currently requires Excel,
which precludes Linux.

Also, if I ever moved my simulations to Direct Draw 7,
or even Direct 3D 9 ( instead of the GDI )
once again I'd be forced to use C++,
as DD7's interaction with MS windows is very tricky
and very OS specific.

For example,
Windows' taskbar hoards it's mouse messages.
The taskbar also turns on the system cursor,
which blocks VRAM-to-VRAM blts.
The solutions are very OS specific.

Would the bankers pay for that ? I doubt it.

 
Mark Thornton





PostPosted: 2004-6-19 5:21:00 Top

java-programmer >> The solutions are very OS specific. Jeff Relf wrote:
> Hi Mark Thornton,
>
> You wrote,
> " The rough equivalent to an HDC is
> a java.awt.Graphics object,
> extended ( since Java 1.2 ) to java.awt.Graphics2D.
> These are used for drawing to screens, printers
> or into a BufferedImage. "
>
> That's quit impressive,
> But my bank simulation currently requires Excel,
> which precludes Linux.
>
> Also, if I ever moved my simulations to Direct Draw 7,
> or even Direct 3D 9 ( instead of the GDI )
> once again I'd be forced to use C++,
> as DD7's interaction with MS windows is very tricky
> and very OS specific.
>

The current Sun JVM will use GDI, DirectDraw or Direct 3D as it deems
appropriate (when running on Windows). There are command line switches
which can control which option is used. The next version adds OpenGL to
the collection of options. When running on Unix or Linux it will select
between another set of OS api. Apart from speed all this is invisible to
the Java programmer.

Mark Thornton