Issue 164 in los-cocos: ZoomTransition scene can misbehave with some hardware

[codesite...@google.com]

Status: New
Owner: ccanepacc

New issue 164 by ccanepacc: ZoomTransition scene can misbehave with some
hardware
http://code.google.com/p/los-cocos/issues/detail?id=164

What steps will reproduce the problem?
1. run the stock test_transition_zoom.py

What is the expected output? What do you see instead?
Expected:
The src scene (grossini over blue background) going more transparent,
the dst scene going more visible,
ending with the dst scene in full view

Seen with gpu nvidia gforce 6200:
seems that the dst scene is also going more transparent, transition ends
with a full black window.

Seen with ati 3200 integrated gpu:
works as expected

cocos 0.3 , 0.4, r1064

win xp 32 bits, python 2.6.5, pyglet 1.1.4

Additional notes:
I need to recheck this in both machines, I noticed the problem while
working on issue 159 out of town.

[codesite...@google.com]

Updates:
Status: Started
Labels: Type-Defect

Comment #1 on issue 164 by ccan...@gmail.com: ZoomTransition scene can

misbehave with some hardware
http://code.google.com/p/los-cocos/issues/detail?id=164

integrated nvidia 6150SE shows the defect
integrated intel 945G don't shows the defect

The problem is not in the library code, it is in the test code:

The BackgroundLayer defined there don't sets the current gl color, hence it
could pick up the one set for another nodes (here an auxiliar node used in
the transition).

Other related situation with bad behavior happens adding a particle system
or a tinted sprite over the background layer: the layer would be tinted
with the current open gl color (including alpha).

The fix is easy: add a
glColor4ub(255, 255, 255, 255)

as the first line in the 'draw' method of BackgroundLayer.

But, there is another thing to consider:
BackgroundLayer appears aprox 60 times in the test_*
With four implementations
. the simplest one does not call transform in the draw method,
hence it would behave like a peculiar CocosNode (not
following .rotation, .position, .scale)
. the next applies transform but have this color leak problem
. two special cases

Being that the test_*.py can and should be used to experiment by library
users, it should expose 'good' objects, not quirky ones.

So I think the fix for this issue should be backported to the other
appearances.

I will fix in a few commits by

. change the special cases to use another name / become a common case
( test_custom_on_resize.py , test\test_transform.py )

. add a script to bulk upgrade the common cases to good behaved one
( tools\uniform.py )

. bulk upgrade, retesting

[codesite...@google.com]

Updates:
Status: Fixed

Comment #2 on issue 164 by ccan...@gmail.com: ZoomTransition scene can

misbehave with some hardware
http://code.google.com/p/los-cocos/issues/detail?id=164

This issue was closed by revision r1208.

[codesite...@google.com]

Updates:
Status: TrunkFixed

Comment #3 on issue 164 by ccan...@gmail.com: ZoomTransition scene can

misbehave with some hardware
http://code.google.com/p/los-cocos/issues/detail?id=164

Fixed for all scripts with the defect at r1208
snapcompare tell rendered images don't changed when running in a good
behaved tesbed.

We should have care to not introduce same weakness in new tests

[codesite...@google.com]

Updates:
Status: Fixed

Comment #4 on issue 164 by ccan...@gmail.com: ZoomTransition scene can

misbehave with some hardware
http://code.google.com/p/los-cocos/issues/detail?id=164

fixed in cocos 0.5.5, closing