AssertionErrors in graphics.IMMEDIATE tests

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Running the test suite
2. Log file captures many AssertionError exceptions in graphics.IMMEDIATE 
tests

What is the expected output? What do you see instead?

I'm not sure.  Need to look into it more.

Please use labels and text to provide additional information.

Original issue reported on code.google.com by benjamin...@gmail.com on 18 Aug 2009 at 6:50

[GoogleCodeExporter]

Does not occur on OSX Leopard intel python 2.6 pyglet 1.1.3.

Original comment by benjamin...@gmail.com on 18 Aug 2009 at 8:15

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Found this at the bottom of tests/graphics/graphics_common.py:

print >> sys.stderr, 'Note: Graphics tests fail with recent nvidia drivers'
print >> sys.stderr, '      due to reordering and optimisation of vertices'
print >> sys.stderr, '      before they are placed in the feedback queue.'

This could be what the issue is.

Original comment by benjamin...@gmail.com on 19 Aug 2009 at 10:24

[GoogleCodeExporter]

I see this on my ATI card as well.  

Original comment by benjamin...@gmail.com on 19 Aug 2009 at 11:47

[GoogleCodeExporter]

I studied this problem, and the insight is the following:

In drawing a polygon (which are what we are testing),
there can be a reorganization of the vertices, but if there is one, at most it 
must be a shift of the data multiple of the number of components of the 
vertices.

E.g. a data of the form 

[v1x, v1y,
 v2x, v2y,
 v3x, v3y]

of two components (e.g. 'v2i'), can only become

[v3x, v3y,
 v1x, v1y,
 v2x, v2y]

or

[v2x, v2y,
 v3x, v3y,
 v1x, v1y]

The easiest way to see this is to imagine that those points constitute a 
triangle. Any other transformation on the list except the one of shifting a 
multiple of the number of components will create a different object.

This is intrinsic to any polygon because you can start drawing it from any 
point.

However, notice that if you switch any two vertices, even though you still draw 
a triangle, the order on which you visit each point changes, which is a 
different triangle in openGL because the orientation of the polygon matters.

I made a couple of tests which corroborate this reasoning.

#####

Given this, in the function "check", we have to compare every possible shift 
multiple of "dimensions" of the "result" list with the "expected" list. If none 
of the shifts work, we assert the test failed.

Given my familiarity with the the code at this moment, if no one opposes, I 
offer myself to fix this section of Pyglet test suite.

Original comment by jorgecar...@gmail.com on 28 Dec 2013 at 9:24

[GoogleCodeExporter]

Your comment makes sense, go for it Jorge!

Original comment by useboxnet on 3 Jan 2014 at 2:39

[GoogleCodeExporter]

Issue 519 has been merged into this issue.

Original comment by useboxnet on 3 Jan 2014 at 5:22

[GoogleCodeExporter]

I have a pull request with a fix of this issue, found here: 
https://code.google.com/r/jorgecarleitao-pyglet-graphics/source/detail?r=7a0e997
f8d2d779b937478c5093b69a1fa441e0f

I Implemented what I explained in my comment, and improved the common code for 
graphics such that there was a lot of repeated code that was removed.

I modified 1 test: in indexed data tests, the initial data is now tested 
against random ordering AND vertices repetition.

The tests pass, and this change is backward compatible, i.e., it also works in 
graphic cards that don't change the vertices ordering.

Original comment by jorgecar...@gmail.com on 5 Jan 2014 at 8:34

[GoogleCodeExporter]

Original comment by useboxnet on 5 Jan 2014 at 11:11

• Added labels: Type-Patch
• Removed labels: 1.1Maintenance, Type-Defect

[GoogleCodeExporter]

graphics.RETAINED_INDEXED ends in a segmentation fault in my system, but it's 
the same with the code BEFORE the patch :)

It's probably is just an issue with my hardware/drivers.

Thanks for the patch Jorge!

Original comment by useboxnet on 20 Mar 2014 at 7:36

[GoogleCodeExporter]

This issue was closed by revision 0a75c2e7c35d.

Original comment by useboxnet on 20 Mar 2014 at 7:36

• Changed state: Fixed