(Solved) Draw time of SpriteBatch with attached attribute Mesh affected by mesh:setVertex() index
Posted: Tue Dec 28, 2021 1:15 pm
Not sure where to post this, sorry if it's already a known thing.
I've been experimenting with SpriteBatches and attached attribute meshes. I'm trying out an effect where a single vertex in a tilemap is updated per-frame (going from first to last vertex, wrapping around.) On my system, it seems like the higher the index of the changed vertex, the longer it takes for the subsequent batch draw operation to complete. (Specifically: it happens with 'static' and 'dynamic' usage hints. 'stream' appears to take a consistent amount of time for any index.) While the impact is modest, in my use case, it's compounded by writing to multiple Batch+Mesh pairs representing different tilemap layers.
In the attached test program, one vertex is updated per frame. You can change the vertex index by moving the mouse across the window horizontally (left is lower.)
I'm currently using LÖVE 11.3. I tested on a recent 11.4 artifact (cee8f8ae4854f4a7f7067b7a4b200e991a05c66f) and found the same thing occurs. I checked the source and found in src/modules/graphics/opengl/Buffer.cpp that 'modified_offset' is always set to 0, or to std::min(modified_offset, ...) which always evaluates to 0. I tried adding an 'is_modified' bool to the Buffer class and an if/else branch to handle the case of the first range being set. This seems to eliminate the performance degradation in my test, but I don't really know what I'm doing with C++ and OpenGL, or if this is occurring on other systems.
My system specs:
CPU: Intel® Core™ i5-4430 CPU @ 3.00GHz × 4
GPU: NVIDIA Corporation GM107 [GeForce GTX 750] / GPU Driver Version: 495.44 CUDA Version: 11.5
OS: Fedora Linux 35 (Workstation Edition) 64-bit
RAM: 24 GB
I've been experimenting with SpriteBatches and attached attribute meshes. I'm trying out an effect where a single vertex in a tilemap is updated per-frame (going from first to last vertex, wrapping around.) On my system, it seems like the higher the index of the changed vertex, the longer it takes for the subsequent batch draw operation to complete. (Specifically: it happens with 'static' and 'dynamic' usage hints. 'stream' appears to take a consistent amount of time for any index.) While the impact is modest, in my use case, it's compounded by writing to multiple Batch+Mesh pairs representing different tilemap layers.
In the attached test program, one vertex is updated per frame. You can change the vertex index by moving the mouse across the window horizontally (left is lower.)
I'm currently using LÖVE 11.3. I tested on a recent 11.4 artifact (cee8f8ae4854f4a7f7067b7a4b200e991a05c66f) and found the same thing occurs. I checked the source and found in src/modules/graphics/opengl/Buffer.cpp that 'modified_offset' is always set to 0, or to std::min(modified_offset, ...) which always evaluates to 0. I tried adding an 'is_modified' bool to the Buffer class and an if/else branch to handle the case of the first range being set. This seems to eliminate the performance degradation in my test, but I don't really know what I'm doing with C++ and OpenGL, or if this is occurring on other systems.
My system specs:
CPU: Intel® Core™ i5-4430 CPU @ 3.00GHz × 4
GPU: NVIDIA Corporation GM107 [GeForce GTX 750] / GPU Driver Version: 495.44 CUDA Version: 11.5
OS: Fedora Linux 35 (Workstation Edition) 64-bit
RAM: 24 GB