Context:
https://web.archive.org/web/20180705002109/https://pplux.github.io/why_px_render.html
bgfx records render commands in global variables (or thread local variables), making impossible to use a task-based scheduler if you want to split your render between different tasks that might be executed from different threads.
bgfx does support submission from multiple threads via bgfx::Encoder interface:
"Encoder API can be obtained by calling bgfx::begin. bgfx by default allows 8 simultaneous threads to use encoders. This can be configured by changing Limits.maxEncoders init option of bgfx::Init structure." https://bkaradzic.github.io/bgfx/internals.html#encoder-api
API:
https://bkaradzic.github.io/bgfx/bgfx.html#encoder
bgfx relies on a command line tool to compile the shaders, and by the very nature of the backends, you end up by having to know in witch backend are you working with in other to load the proper precompiled shader.
This was intentional choice. It's not common to ship game with shaders in source code form, and on some platforms it's not even possible to compile shaders in runtime.
also this tool (shaderc) has massive hacks to make it work from GLSL to HLSL,GLES, etc... it is impressive though.
There is no good open source shader compiler that targets all shader languages supported by bgfx (GLSL, ESSL, HLSL DXBC, HLSL DX9BC, PSSL, Metal, SPIR-V), and I didn't write one... Yet! ;)
it is difficult to add a new feature, you have to make sure it works on all backends.
Don't get why "you have to make sure it works on all backends" is mentioned here... Difficulty of adding new feature depends on feature. But yes you have to add support for all renders because it makes no sense to have cross platform renderer if features will be randomly distributed over different rendering backends.
it is almost impossible to add a specific feature to a given backend (for example, we needed to use GL_OES_EGL_image_external on android, we ended up writing our own GL code, and then convert the resulting texture into a bgfx texture to use it.)
Choice is adding feature you need vs writing whole rendering library from scratch.
if you're planning on loading textures on your own, it would be nice not to compile bimg.
bimg is split into 3 different libraries. Default bimg library used by bgfx is used only to parse .ktx and .dds files which bgfx accepts directly, and transcoding compressed texture formats into uncompressed formats to be used on renderers that don't support particular texture compression in hardware.
bimg_decode is used to provide support for different image formats like .jpg, .png, .psd, .exr, .hdr, etc. to be used in tools like texturec (texture coverter), texturev (image/texture viewer) or in examples.
bimg_encode library is used only by texturec for converting textures to compressed formats.
Providing functionality like texture viewer or texture converter with library is convenient because you don't have to use 3-4 other different tools to add support for different texture compressions, or to view compressed textures, 3D textures or cubemaps.
you might or not, want to use bx either, but as with bimg, bgfx depends on it.
bgfx doesn't require user to use bx, or bimg, at all (only for linking). Once bgfx library is compiled it can be directly used by just few header files located inside include directory. Those header files don't depend on bx or bimg, and all functionality is tucked inside bgfx. So yes it's required to compile bgfx, but it's not required for use of bgfx.
Required headers to use bgfx are:
#include <stdarg.h> // va_list
#include <stdint.h> // uint32_t
#include <stdlib.h> // NULL