Future Development
Short-term goal:
The short-term goal for me is to improve correctness and performance and accalerate as many operations as possible, working on the tasks mentioned in TODO.
Mid-term goal:
The mid-term goal includes some changes which introduce broader re-structuring of the pipeline's design.
The current design is quite similar to the X11 pipeline. Pipeline-Validation and configuration happen on the Java side, and for configuring the native resources JNI calls are done.
However the XRender pipeline probably does more JNI calls, because there are more properties which have to be validated / adjusted.
A simple trick would be some "buffered rendering light" design - buffer all configuration commands into a native ByteBuffer, and pass that buffer down with every rendering command.
This way at least configuration overhead could be minimized, with a JNI call only when rendering has to be done.
Furthermore processing the configuration-instruction-stream could be tuned to hit less mis-predicted branches, because there are way less possible branch targets.
Another mid-term goal would be to improve the mask-buffer. Under some circumstances many primitives can buffered in the buffer before doing the composition which should improve performance quite a lot, a lot for rects but even more for lines.
However this would also introduce the need for a periodical flush, as its done with the STR pipelines.
Possible long term goal:
A possible long-term goal would be to implement the whole pipeline in Java, replacing the hard dependency on the native side with a well defined interface.
This would have several benefits:
- Easier maintenance, less native code which has to be kept compatible with different C compilers on different platforms.
- Better performance and ...
- Less implementation specific stuff in the core logic:
The core of the pipeline could kept
backend independent, only communicating with the native libraries
through an well defined interface.
That would allow a buffered pipeline design, where e.g. all operations are written to a command stream.
By replacing the native backend with one written completly in java (like caciocavallo), the whole JNI and command-stream interpreting could be removed and the protocol would be directly generated with pure Java, which I believe will be faster than going all layers through xlib/xcb - especially after tuning Escher a bit.
- More room and options for optimizationsThat would allow a buffered pipeline design, where e.g. all operations are written to a command stream.
By replacing the native backend with one written completly in java (like caciocavallo), the whole JNI and command-stream interpreting could be removed and the protocol would be directly generated with pure Java, which I believe will be faster than going all layers through xlib/xcb - especially after tuning Escher a bit.
- Absolutly no dependency on native code
However the drawbacks would be that most likely the existing native could not be shared with the X11 pipeline.
