On Wed, 2009-09-30 at 10:48 -0600, Brian Paul wrote:
> Peter Clifton wrote:
> Do you have time to test the attached patch (a clean-up of your patch
> basically)?
I gave it a quick test, and whilst it cures the original rendering
artefact (which manifested as a failure to clear the main window, and
cross-hair trails everywhere), it did introduce other issues.
Now my screen fills yellow (cursor colour), as soon as I close my
secondary window. On other occasions, it seg-faults.
It has been a little while since I wrote the rendering code, so I can't
swear exactly to the steps, but basically, as the translucent PCB
primitives on a given layer (thick, rounded lines etc..) are drawn, they
mark a particular bit in the stencil buffer - such that I don't get
overlapping geometry on a given layer. (The rounded ends of the lines
overlap otherwise).
Other geometry is constructed in the stencil buffer first, then
overpainted with a solid fill - and I suspect that "might" be where the
solid background fill is coming from. Alternatively - it could be a
glClear to the wrong colour.
I also encountered this new artifact when I was writing my original
"fix". I'd experimented with which parts of the setup needed to be
executed once, and which had to be called every time the glClear was
run.
Sorry not to be of better technical help here!
Btw.. backtrace of a crash:
#0 memcpy () at ../sysdeps/i386/i686/memcpy.S:75
#1 0x00000001 in ?? ()
#2 0x046d420f in brw_prepare_vertices (brw=<value optimised out>)
at brw_draw_upload.c:476
#3 0x046e1067 in brw_validate_state (brw=0x863e3b8) at
brw_state_upload.c:322
#4 0x046d2f5c in brw_try_draw_prims (ctx=0x863e3b8, arrays=0x868069c,
prim=0xbfffe540, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001',
min_index=0, max_index=665) at brw_draw.c:371
#5 brw_draw_prims (ctx=0x863e3b8, arrays=0x868069c, prim=0xbfffe540,
nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0,
max_index=665) at brw_draw.c:454
#6 0x047981c9 in vbo_exec_DrawArrays (mode=4, start=0, count=666)
at vbo/vbo_exec_array.c:523
#7 0x0478cee2 in neutral_DrawArrays (mode=4, start=0, count=666)
at main/vtxfmt_tmp.h:328
#8 0x080ffc2f in hidgl_flush_triangles (buffer=0x81b3be0)
at hid/common/hidgl.c:75
#9 0x08103351 in ghid_set_color (gc=0x834a1d0, name=<value optimised
out>)
at hid/gtk/gtkhid-main.c:800
#10 0x08103612 in use_gc (gc=0x0) at hid/gtk/gtkhid-main.c:874
#11 0x081036ee in ghid_fill_circle (gc=0x834a1d0, cx=48000, cy=304000,
radius=1750) at hid/gtk/gtkhid-main.c:907
#12 0x08090075 in DrawHole (b=0x9028f60, cl=0x0) at draw.c:1184
Since primarily - with the exception of selected objects, each layer in
the PCB is made up of the same colour objects, I'm not uploading colour
data with each vertex. Whenever I change drawing colour, I hand to GL
(to render) any triangles accumulated internally by the drawing code.
The above note is to explain why the backtrace shows it "flushing"
triangles from inside a "set_color" routine.
Btw.. is there any "correctness" test I can apply to my own rendering
code to ensure I'm not provoking these issues by misuse /
misunderstanding of VBOs etc..?
Best wishes,
Peter C
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
