yes wmeissner, it's more or less the problem I have. Native threading without NIOBufferedImage() means more storage to allocate, more memcpy(), more attach/detachCurrentThread().
It is clear that threading issues with NIO backed BufferedImage would still be a (minor) problem, expecially if you're going to paint your image somewhere while some thread is updating it. But pixel-data locks would be an easy and viable solution. The BufferedImage API should not be affected at all by this new NIOBufferedImage(). This would have a positive impact for developers like us, aiming to integrate some native 3rd party bindings into their apps with a fast, clean and efficient design. [Message sent by forum member 'mikofclassx' (mikofclassx)] http://forums.java.net/jive/thread.jspa?messageID=261937 =========================================================================== 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".
