Add native rendering support by supporting WritableImages backed by NIO ByteBuffers

A DESCRIPTION OF THE REQUEST :
The current WritableImage API does not allow for WritableImages backed by NIO ByteBuffers, i.e., DirectBuffers that are used in native code. This makes it impossible to efficiently render native buffers. Another issue is the fact that multiple WritableImages cannot explicitly share memory.

Therefore, we propose the following extension to the current API:

/**
     * Construct an image of the specified dimensions, backed by the indicated
     * region of the {@link java.nio.ByteBuffer}.
     *
     * If the indicated region exceeds the capacity of the buffer an
     * {@link ArrayIndexOutOfBoundsException} will be thrown.
     * Images constructed this way will always be readable and writable
     * so the corresponding getPixelReader() and getPixelWriter() will
     * always return valid objects.
     * The dimensions must both be positive numbers <code>(&gt;&nbsp;0)</code>.
     *
     * @param ByteBuffer bb byte buffer that backs this image
     *
     * @param offset the offset from where to start accessing the buffer
     *
     * @param width the desired width of the writable image and the
     * width of the region to be read from the {@code reader}
     * @param height the desired height of the desired image and the
     * width of the region to be read from the {@code reader}
     *
     * @param wpf writable pixel format that describes the representation
     *
     * @throws ArrayIndexOutOfBoundsException if the {@code reader} does
     * not access a surface containing at least the indicated region
     * @throws IllegalArgumentException if either dimension is negative or zero.
     */
    public WritableImage(ByteBuffer bb, int offset, int w, int h, WritablePixelFormat<ByteBuffer> wpf)

JUSTIFICATION :
For each and every major UI toolkit it is necessary to integrate powerful visualization capabilities. This includes native rendering. Many proposals for extending JavaFX have been formulated, e.g., WebGL, OpenGL etc.

For the community it is hardly possible to add these features since it involves a huge amount of code and knowledge about internal, undocumented and potentially changing infrastructure.

To prevent that a common native buffer could be used to circumvent this strong dependency on internal implementation details. However, current solutions have to copy memory manually from the native renderer into a WritableImage via the PixelReader/PixelWriter API. Since manual copying of the buffer increases the CPU load significantly, we cannot use PixelReaders and Writers.

Adding the proposed constructor, will solve many problems and allows the community to contribute WebGL, OpenGL and Qt-based WebGL nodes without knowledge of internal implementation details. The scientific community would highly benefit from the possibility to render native buffers. JavaFX is an ideal API for many applications. But since we cannot add highly advanced visualization nodes the current situation is unsatisfying.