ShapeAtom.updateShaders(...) actually is called from Appearance.verifyChange(). This method is called from ShapeAtomPeer.renderAtom().
Yes, I see, and this explains why I get the result of "only one wrong frame just after the changes", so 2nd and other subsequent frames are OK.
Updating shaders in renderAtom() is too late - it should be updated BEFORE sorting pass. So if you check the changes I made to CVS now I placed this call immediately when atoms are collected (added) during re-cull.
I don't fully understand this shaderId thing.
This thing comes from very first versions of Xith3D, I think I have explained how it works a year or so on this forum. But with great pleasure I will explain you the idea and why updating shaders in renderAtom() is too late.
As you see, for each (in general words) appearance component type there is a shader. For each by-value-unique appearance component the core makes unique stateId which is assigned using a map (StateMap) - when creating a shader, map is looked up for the appearance component and if exactly equal shader has already been created, and if so, take its stateId (creating a new stateId otherwise).
Now, after stateIds are assigned, core on atom-by-atom basis executes the shaders and AFTER (!) calls renderAtom(), so if you update shaders there core will execute shaders at least once with old stateId's assigned before the change.
The problem is that the core can decide to skip actual shader execution if it sees that the shader of given type with specific stateId was already executed just before, so if two shaders with different characteristics will have the same stateId, one may be skipped while have to be applied in order to get correct rendering result.