This might have only been an issue in some drivers (not sure, spec is a bit vague here).
Apparently we need to call glMaterial *after* the color material setting has been disabled for it to stick.
Fixes#369
This setting causes asserts when modifying certain material flags after they are assigned to a node, in case a shader has been generated that uses the materials, which cannot efficiently detect whether the material has changed. However, we already sort of have a (inefficient, but effective) solution for this in TextureStage (see #178) that we could just apply here as well: changing the material attributes after such a shader has been generated could call GraphicsStateGuardianBase::mark_rehash_generated_shaders().
In the future, we should replace the material model with one that does not require shader regeneration for such seemingly trivial property changes.
Fixes#370
Currently, the WeakPointerTo comparison operators compare the raw pointers, but this is not useful as it may cause a false equality if one weak pointer in the comparison is expired and points to memory that has since been reused.
Instead, we can define a comparison based on the control block pointer, which exists since the new weak pointer implementation in 0bb81a43c9. This is implemented in the owner_before method, matching C++11 std::weak_ptr semantics.
I would now recommend deprecating most comparison operators of WeakPointerTo or redefining them to make more sense, ie. comparing equal if they (once) referred to the same object and not if they simply point to the same memory address. This has not yet been done, though code that uses the comparison operators has been fixed in this commit.
Overloads of std::owner_less have been provided for creating a map or set with Weak(Const)PointerTo keys.
Some drivers would report the wrong internal format. But it's silly that we query the internal format anyway, since buffer textures have a fixed sized internal format.
This is inefficient because it induces an unnecessary ref()/unref() pair when we just need to move the pointer out of the function. Thanks to 23128e4695, we can now move between related pointer types, making the .p() hack unnecessary.
This makes it possible to implicitly convert a PT of a derived type to a (C)PT of a base type, without needing to first convert it to a regular pointer. This also applies to moves, which are now more efficient due to the lack of need for ref/unref pair even if the pointer type is not exactly the same.
I'm not sure why they were ifdeffed out, but they should certainly be available so that it is possible to compare WeakPointerTo in a thread-safe manner.
deflected
rdb
Mitchell Stokes