<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - Gallium: GL_LINE_LOOP broken with more than 512 points" href="https://bugs.freedesktop.org/show_bug.cgi?id=81174#c7">Comment # 7</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - Gallium: GL_LINE_LOOP broken with more than 512 points" href="https://bugs.freedesktop.org/show_bug.cgi?id=81174">bug 81174</a> from <a class="email" href="mailto:sroland@vmware.com" title="Roland Scheidegger <sroland@vmware.com>"> Roland Scheidegger</a> <pre>Hmm interesting. I thought more than 512 vertices would fit before it uses a new buffer (the buffer size is 64kB though I don't know what the vertex size ends up with). But if the bug is due to that I guess indeed changing the prim type (probably in vbo_exec_wrap_buffers()) and fixing up the copied vertices stuff (if it doesn't do the right thing already) would do the trick. But indeed closing the loop finally would be tricky (well I guess would need to keep the vertex around when doing the buffer wrap, then can simply emit it as another vertex last). I have no idea of the effects this has on things like line stippling but I guess it couldn't be worse than it is now... Also, things like GL_POLYGON with fill mode line probably has the same problem and can't be fixed that way really. Note that the draw module has its own decomposition of primitives into smaller chunks too which could also be buggy (vsplit stuff).</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>