Hi Laurent, Thanks for your interest in tuning the pipelines and all the work you did in this regard with Marlin.
> I read again the source code and wanted to add metrics like wait_ratio and make some new heuristics to auto tune the buffer capacity. > I was also tempted to rewrite the buffer overflow strategy: swap buffer or use a larger one... > Apparently you made another approach (double buffer) to reduce the wait latency in awt threads... and allow gl thread to run concurently: excellent ! > Could you share your patch to let me study it and try improving it ? Sure, I've forked openjdk at: https://github.com/ceisserer/jdk However please keep in mind this is still very much a proof-of-concept hack done in one day only: - There are some places in native code which do not expect the pointer to the buffer to change after a flush, which are still not modified. - I guess it would be better to return the new RenderBuffer from ensureCapacity and flushnow, instead of relying on callers to re-fetch it after calling those methods - I am not 100% convinced the rewritten locking in the OglRenderQueue flusher thread is correct under all circumstances. This code would need a rewrite/clean-up and error-handling, now that it has to take into account two different operating modes (sync / async flush). As this has to fit into AWT's existing locking scheme, it took me some time to get it working. - there are still rough edges and issues/bugs: when flushNow in OGLBlitLoops.IsoBlit is changed to flush async, I get crashes etc - so some places somewhere are either not aware of the buffer change, or expect certain behaviour I don't know about. (with async flush I get GLX errors and other strange issues). just to be curious, are you running the proprietary nvidia opengl driver? Best regards, Clemens
