glColor3f overriding paint

[Matt-Esch]

glColor3f(1,1,0) sets the current color to yellow. If I create a red paint and set the paint before drawing, things still appear yellow.

In setup:

// create a paint
_paint = vgCreatePaint();
vgSetPaint(_paint, VG_FILL_PATH );
VGfloat color[4] = { 1.0f, 0.0f, 0.0f, 1.0f };
vgSetParameterfv(_paint, VG_PAINT_COLOR, 4, &color[0]);

// create a box path
_path = vgCreatePath(VG_PATH_FORMAT_STANDARD, VG_PATH_DATATYPE_F,1,0,0,0, VG_PATH_CAPABILITY_ALL);
vguRect( _path, 0, 0, 64.0f, 64.0f );

In render loop:

glColor3f(1, 1, 0);
vgSeti(VG_MATRIX_MODE, VG_MATRIX_PATH_USER_TO_SURFACE);
vgLoadIdentity();
vgTranslate( 0, 0 );

vgSetPaint( _paint, VG_FILL_PATH );
vgDrawPath( _path, VG_FILL_PATH );  // Square is yellow not red

[micahpearlman]

When mixing OpenGL with MonkVG you need to save off and restore the MonkVG OpenGL state. So for this example you will need to use glGet* in conjunction with GL_COLOR_ARRAY to store the MonkVG color state before you call your glColor and then you need to restore the MonkVG color using the stashed glColor. Does this make sense?

[Matt-Esch]

Is this generally how OpenVG works or is this a design decision? I suppose that OpenVG is separate from OpenGL and that there is no specification for how they should interact when you use the same context to do two different things. Perhaps I want to be using a separate OpenVG context and rendering to a shared texture. Also would you advise against using glPushAttrib and glPopAttrib to preserve the state of the context between OpenGL sprite rendering and OpenVG vector rendering?

[micahpearlman]

It was a design decision specifically for performance reasons. There was one point were MonkVG stored and the re-stored the OpenGL state at every path draw. As you can imagine that is a HUGE overhead and slowed things down considerably -- so I basically punted and left it upto the application developer to be responsible for storing and re-storing state. It would be nice if OpenVG specified a start and end render methods -- and there probably isn't any reason I (or you) couldn't create an extension to MonkVG to do just that.

Cheers, -Micah

~~ Micah Pearlman biz 415-997-8571 mob 415-637-6986 micahpearlman@gmail.com LinkedIn: http://www.linkedin.com/pub/micah-pearlman/16/7b6/193 ~~

On Mon, Jan 23, 2012 at 2:15 PM, Matt-Esch reply@reply.github.com wrote:

Is this generally how OpenVG works or is this a design decision? I suppose that OpenVG is separate from OpenGL and that there is no specification for how they should interact when you use the same context to do two different things. Perhaps I want to be using a separate OpenVG context and rendering to a shared texture.

---

Reply to this email directly or view it on GitHub: https://github.com/micahpearlman/MonkVG/issues/4#issuecomment-3623035

[Matt-Esch]

My confusion was that I thought if I set the paint, the state would be fully encapsulated in that object. So I can only conclude MonkVG must have some internal mechanism which only changes the OpenGL state when it looks like it needs to be changed (i.e if I am now drawing in blue instead of red). I was under the impression that this wasn't something that had to be taken care of and that OpenGL only updates state when a state change actually occurs, so there is no performance penalty when calling glColor3f twice if the colour hasn't changed between the two calls. Having a dig around on that issue, it seems to be down to the implementation and not part of the specification as to whether or not changing a state will yield a performance overhead when it actually changes nothing. It seems like implementing this yourself is a sensible idea. I will play with it and see what I can come up with. I like the idea of a separate context with immediate rasterisation to a shared texture, but I have no idea how slow or fast this is likely to be without trying it.

~Matt

[micahpearlman]

Yeap, you have the issue pretty much nailed -- MonkVG keeps track of state changes and only does a change when necessary. Calling glColor3f was actually a pretty big overhead on iOS devices -- not sure on other platforms.

A lot of end users seem to go down the road of rendering OpenVG to a texture. For a lot of applications that would yield a lot of performance gains if the application only updates when it is necessary. Also, applications can do post processing on the rendered texture.

~~ Micah Pearlman biz 415-997-8571 mob 415-637-6986 micahpearlman@gmail.com LinkedIn: http://www.linkedin.com/pub/micah-pearlman/16/7b6/193 ~~

On Mon, Jan 23, 2012 at 4:11 PM, Matt-Esch reply@reply.github.com wrote:

My confusion was that I thought if I set the paint, the state would be fully encapsulated in that object. So I can only conclude MonkVG must have some internal mechanism which only changes the OpenGL state when it looks like it needs to be changed (i.e if I am now drawing in blue instead of red). I was under the impression that this wasn't something that had to be taken care of and that OpenGL only updates state when a state change actually occurs, so there is no performance penalty when calling glColor3f twice if the colour hasn't changed between the two calls. Having a dig around on that issue, it seems to be down to the implementation and not part of the specification as to whether or not changing a state will yield a performance overhead when it actually changes nothing. It seems like implementing this yourself is a sensible idea. I will play with it and see what I can come up with. I like the idea of a separate context with immediate rasterisation to a shared texture, bu  t I have no idea how slow or fast this is likely to be without trying it.

~Matt

---

Reply to this email directly or view it on GitHub: https://github.com/micahpearlman/MonkVG/issues/4#issuecomment-3624877