> Why cant you use the same approach
> in JDK 1.2 for NON-Graphics2D versions of drawImage. The current
> approach (software rendering) leads to horrible performance for
> existing 1.1 applications on REMOTE displays. JDK 1.1 was fast
> because the XPixmap held on the X-Server avoided transfer of
> the pixel data every time you call drawImage with the same Image.
We are working on non read/write/modify loops for various needs. We
also need such loops for cases like win32 printing where the printer
cannot read back pixels from the PDL stream and cannot give us a pointer
to the destination pixels as with DirectDraw on a screen device.
Unfortunately, until the new architecture is available, each such loop
that is added strains the rubber bands and bailing wire that are holding
the current implementation together and we don't want them to snap. The
new architecture abstracts the handling of destination surfaces in a way
that cleans this all up considerably, but won't be in place for Kestrel
so we are gently and carefully considering which cases are a priority
to get working for the current release.
There are several bugs already submitted about remote X performance...
...jim
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
