[Mesa-dev] [PATCH] vbo: fix another GL_LINE_LOOP bug

[Charmaine Lee]

>________________________________________
>From: Brian Paul <brianp at vmware.com>
>Sent: Wednesday, November 4, 2015 12:03 PM
>To: Charmaine Lee; mesa-dev at lists.freedesktop.org
>Subject: Re: [Mesa-dev] [PATCH] vbo: fix another GL_LINE_LOOP bug

>On 11/04/2015 12:40 PM, Charmaine Lee wrote:
>>
>> I concur with Sinclair and Roland that the vbo code is quite tricky.
>> I do have a question, so when the line loop spans multiple vertex buffers,
>> where is 0th vertex stored exactly?

>It depends.  If the line loop started in a new/empty VB, the 0th vertex
>is at the start of the buffer.  But if the line loop started later in
>the buffer (because another primitive before it), the 0th vertex will be
>at the prim->start position.

>I didn't find the bug that this patch fixes earlier, because my test
>programs all hit the first case.  We have to draw at least two
>primitives to hit some of the corner cases.


>> In vbo_exec_End,  you are changing src = exec->vtx.buffer_map + last_prim->start * exec->vtx.vertex_size;
>> If the 0th vertex is always copied to the beginning of the buffer, why do you need this change?

>To account for the second case, above.


>> If it was not copied to the beginning of the buffer, couldn't it be overwritten by the subsequent vertices?

>This patch actually fixes a case where subsequent vertices _were_
>overwriting previous vertices when another primitive followed the line
>loop.  That's the change at line 846.


So if last_prim->start is 100, and if the line loop spans 3 vertex buffers,
so at the second vbo_exec_wrap_buffers(), can't the original vertex 0 which
is at buffer_map + 100 * vertex_size be already overwritten by the
vertices that are now in the second vertex buffer?

-Charmaine