using externally managed textures with NanoVG

[svenevs]

Hello, I'm trying to track down a bug that seems to only appear on OSX. The brief version of this question:

what exactly is the purpose of glActiveTexture(GL_TEXTURE0), e.g. in glnvg__renderFlush? I'm simply trying to understand how textures are being used (e.g., for image icons only?).

The longer version: I'm working with a nanogui::GLCanvas widget. The way that widget works is it ends the frame, does some scissor calculation, then calls drawGl, which subclasses override to perform the actual drawing.

In my particular subclass, I'm trying to display textures. The actual application is basically just streaming in stuff from an active camera feeding in new data each frame, but the details aren't very important. I've spent a lot of time digging around the nanogui code and don't think there's anything wrong going on there. I started looking into what the implication of nvgEndframe is, and that seems to be why things are getting a little screwy. I don't understand how, though. Consider having two of these widgets, the calls would look something like

// first feed
nvgEndFrame(ctx);
    // goes through and triggers a GL_TEXTURE0 to be active
this->drawGl();
    // goes through my code, which basically amounts to
    glActiveTexture(GL_TEXTURE1);
    glBindTexture(...);
    // draw some stuff via a shader after setting uniforms for which sampler to use

// rinse lather and repeat for second feed

The reason I'm getting turned around is because as far as I can tell, it really doesn't matter if nvgEndFrame is setting the active texture to GL_TEXTURE0, since in my own code I'm explicitly setting the texture unit I want, right? Is there anything I'm overlooking in terms of what nvgEndFrame triggers, and how that might be blocking / interfering with my own texture setting / usage?

Thanks for any consideration, I'm only about 60% confident this has anything to do with NanoVG. The extra 10% because if I just glViewport these and don't have it associated with anything related to NanoVG, there's no flickering.

[memononen]

glActiveTexture(GL_TEXTURE0) means that you (or nanovg) is changing stuff in texture unit 0. For multitexturing (i.e texture + normal mapping), you could have something like:

glActiveTexture(GL_TEXTURE0);
glBindTexture(...); // Albedo
...
glActiveTexture(GL_TEXTURE1);
glBindTexture(...); // Normal map
...

// shader stuff
glUniform1i(glGetUniformLocation(shader->prog, "albedoSampler"), 0); // these ase the unit numbers above
glUniform1i(glGetUniformLocation(shader->prog, "normalSampler"), 1);

In the readme there's a list of GL state that nanovg changes. Make sure you set those each frame too after nanovg, and not just at init.

[svenevs]

Hi @memononen, thanks for the response. I investigated restoring state / ensuring everything is consistent, and I believe I have discovered it is a me problem. I added a large delay between loading in new frames and changed the number of buffers (4 to 8). The flicker interval is directly correlated to the number of buffers I have...

Sorry for the noise, thanks again for the response!

[svenevs]

Revisited after finally finding a solution. The below may be helpful to you if you are encountering texture problems while drawing with NanoVG. This issue remains closed as I was looking in the wrong spot, it was definitely not a problem with NanoVG.

Problem: I'm having trouble with textures.

In the reduced conflict, it turned out it was a bit of a misdirection when I changed the number of buffers. I was foolishly using way too many texture units, the instance in which GL_TEXTURE0 was being used was still the problem. It's very likely I was missing some nuanced detail of resetting texture parameters, but in the end I couldn't figure it out. In contrast, to my knowledge the nanogui::GLCanvas widget is the only one that explicitly needs to nvgEndFrame. When this widget is not in play, all widgets are drawn between a single nvgBegin and nvgEnd. This leads me to believe that is why nanogui::ImageView can use GL_TEXTURE0).

This suggests that nvgEndFrame may play a direct role in this (especially if you look at the source code), but this instance falls more into an "improper usage" scenario (by the downstream nanogui::GLCanvas).

Solution: given that NanoVG makes explicit claims about modifying GL_TEXTURE0 and related state, just don't use that.

In the end, I was needing to display two textures. So instead of GL_TEXTURE0 and GL_TEXTURE1, the fix that worked for me was to use GL_TEXTURE1 and GL_TEXTURE2. I suspect finding the actual root cause of this is an exercise in futility, given how simple the solution is.

[memononen]

I'm not familiar enough with nanoGUI that I could comment on it's workings. NanoVG should be used so that you call nvg command between nvgBeginFrame()and nvgEndFrame(). During that time nvg may change the GL state, but generally it buffers the draw calls and draws them all in nvgEndFrame(). If you call nvgEndFrame() too early, the rest of the nvg commans will just be discarded.

You can use your own OpenGL texture to draw with nvg. There are nvglCreateImageFromHandlexxx() (each platform as it's own function. i.e. xxx=GL2) function which take OpenGL texture handle, width/height, and some parameters and return nvg image handle, which can be used with nvgImagePattern(). That way you don' need to interrupt the nvg draw context if you want to draw your own texture.