Hi All,
I tried to rewrite Gremlin - make new widget based on existing code and contribute it. It made with using of recent OpenGL ES API (shaders/vertex buffers/etc.). The code is not ready to show yet, but I got all parts working and it is possible to make it handling bigger g-code files and do it fast enough. Currently big files simply excluded from preview. At first look, the problem is large Python trajectory arrays that filled one-by-one and then handled in Python again with lot of iterations. I rewrote it to use number of continous memory buffers (fixed size each) and it made a big change immediately. That is not the question, I hope I can show results soon. Just want to ask if anyone have interest in this new widget?
Another big deal is number of calls between C++ code and Python code. I did not measure it yet, but
gcodemodule.cc does calls like this for any point in trajectory:
Code:
PyObject *result =
callmethod(callback, "straight_feed", "fffffffff", x, y, z, a, b, c, u, v, w); // gcodemodule.cc:340
When it repeated n*thousand times, it becomes a bottleneck for sure. My idea is to modify method
Code:
static PyObject *parse_file(PyObject *self, PyObject *args) {
and add an optional parameter for this to accept C method pointers for "straight_feed", "traverse", etc. So when this parameter passed, it will call C callbacks instead of python methods and do not do all this Python variable conversion back and forth. Something like this
Code:
if (straight_feed_callback) {
(*straight_feed_callback)(x, y, z, a, b, c, u, v, w);
} else {
PyObject *result =
callmethod(callback, "straight_feed", "fffffffff",
x, y, z, a, b, c, u, v, w);
if(result == NULL) interp_error ++;
Py_XDECREF(result);
}
I believe this may be a huge performance win and I hope it does not violate any LinuxCNC development guidelines.
My question is to project maintainers. If I make this change and submit to Github to merge, will it be accepted?
