<div dir="ltr">On 30 August 2013 10:36, Eric Anholt <span dir="ltr"><<a href="mailto:eric@anholt.net" target="_blank">eric@anholt.net</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">Kenneth Graunke <<a href="mailto:kenneth@whitecape.org">kenneth@whitecape.org</a>> writes:<br>
<br>
> can_cut_index_handle_prims() was passed an array of _mesa_prim objects<br>
> and a count, and runs a loop for that many iterations.  However, it<br>
> treats the array like a pointer, repeatedly checking the first element.<br>
><br>
> This is wasteful and bizarre.<br>
><br>
> The VBO module will never call us with multiple primitives of different<br>
> topologies, so it's actually reasonable to just check the first element.<br>
<br>
</div>I'm pretty sure it will.  I don't see anything in vbo_exec_Begin()<br>
making sure the new primitive is the same type as the last.<br></blockquote><div><br>Yeah, I agree.  Although I wasn't able to construct a failing case using primitive restart, I did verify by experiment that this sequence of calls causes the VBO module to call us with multiple primitives of different types:<br>
<br></div><div>glBegin(GL_LINE_STRIP);<br></div><div>glArrayElement(...);<br>...<br></div><div>glEnd();<br></div><div>glBegin(GL_LINE_LOOP);<br></div><div>glArrayElement(...);<br>...<br></div><div>glEnd();<br><br></div><div>
Given that nr_prims only gets large when glBegin/glEnd is in use, I don't think we have to worry about performance in the loop.  Let's just correct the loop to check all prims, which was almost certainly the original intent.<br>
</div></div></div></div>