This vector implementation does is optimized for the case of having only a small number of elements, which are stored directly on the vector object rather than being allocated from the heap. If the capacity exceeds this small number, then a heap allocation is done.
This should improve performance in a couple of cases where vectors typically store 1 element and rarely more than that.
The order of arguments is now the same as in Python (with the callable first), sort and priority arguments have been added, and new tasks can be added directly to a chain
It's unfortunate that we now have three maps on EventHandler for three different types of functions. I'd love to unify them all under std::function, but the fact that it doesn't support comparison means the behavior would be different.
Perhaps in the future we can create a new interface or deprecate the existing behaviors and unify everything under std::function.
See #981. Setting `vertex-colors-prefer-packed` to false will make Panda default to OpenGL-style vertex colors, which is useful if are targeting OpenGL and not DirectX 9, avoiding a potential performance cost.
The symbols moved aren't used in any headers, so they don't
have to be in the installed dtool_config.h. Removing them
keeps the recompiling to a minimum when an optional feature
is toggled.
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 changes the target_link_libraries() declarations so they only
go directly to a component library if it's in the same metalib.
If it's outside of the metalib, the correct thing to do is link against
the metalib. CMake takes care of the transitive linking for us, so
there isn't actually any big change here.
This can happen when a system event (eg. on macOS) triggers a terminate from within process_events.
This is a workaround for a common error; the proper fix is not to put PandaFramework in the global scope.
This is designed to sanity-check the buildsystem, ensuring that the
expected BUILDING_ macros are defined at the expected time. It
also helps catch cases where the wrong BUILDING_/EXPCL_ macros
are used.