Data buffer got shorter when switched to OpenGL ES 2.0

Using the latest libsmu: https://github.com/analogdevicesinc/libsmu/commit/4938852ad19d9877421f1e92d211c99a314c7cc4, the data buffer becomes shorter for some reason.
It worked with commit: https://github.com/analogdevicesinc/libsmu/commit/d52193467809baec67f43cb2fd75eb8832242852
@radhermit do you know what could cause this?
Glancing back through the git history, I don't recall merging anything on the master branch that would have affected something like that, but it could be an errant bug of a commit I made. Can you roll through a git bisect and see which commit causes it?
Sure. I will let you know if I find anything.
It's not libsmu. I must have made an error when I compared Pixelpulse2 against the two versions of libsmu. Sorry about that. I am still looking for the issue. It must be somewhere hidden in one of my recent commits.
The problem comes from the fact that I have switched Pixelpulse2 from using Desktop OpenGL to using OpenGL ES 2.0. I did that because it seemed to fix the compile errors I was having (no opengl call was recognized by the compiler) when using Qt 5.5 (or newer) libraries. The issue we're having exists because OpenGL ES 2.0 specification allows a maximum of 65535 for one set of vertices. I could go back to using Desktop OpenGL and add the opengl libs to a path to get rid of the compilation errors. Or I could stick with using OpenGL ES as it provides some advantages: it increases portability on embedded devices (most of them meet the OpenGL ES 2.0 specs) and might work on windows were users can't /don't want to install drivers for their graphics card (if one is available) by using ANGLE libraries that map OpenGL ES 2.0 API calls to DirectX API.