Recently there's a lot of interesting work going on in XCB, which is used indirectly by the XRender pipeline via Xlib.
1. Output Buffer enlarged:
In one of my last posts I complained that the output buffer was limited to 4kb, now the default was raised to 16k. Although I had hoped for some API-adjustable buffer size, thats way better than the 4kb and its furthermore adjustable at compile time. So chances are good that desktop distributions will set it to ~64k to squeeze out some additional performance for their users.
Beside the fact that this will improve performance a bit, this will allow applications to write directly to xcb's socket, instead of having to go through xcb's protocol generator. (as far as I've understood).
This would really be *extremly* helpful for the pipeline rewrite.
I would like to write the pipeline in pure java, but instead of going through JNI for each primitive I would prefer to buffer it, very much like the D3D/OGL pipelines do.
The new pipelines however have to generate an opcode stream which is later re-interpreted at the native side (somthing like switch(getNextOpcode(buffer))) - and without the socket-handof-mechanism we would have to do exactly the same.
With the socket-handoff stuff in place, it should be possible to directly write X11-protocol to a large (NIO?) Buffer, and when its time we flush that data directly through xcb's socket, which means:
- No per-primitive JNI cost
- No additional command-stream generation / interpretation
- The buffer is ours, so we can size the buffer ;) (really?)
One thing I am not sure about is how the IDs could be synchronized with xcb, like the IDs of server-side resources, hopefully there's a solution.
Well, for now ... university has me again *argh!*, and there are a few things I would like to fix in the old pipeline - in order to test dirver compatibility and submit bug-reports, before I can start working on that stuff.