The zone grouping was only taking into account the first zone for both its duration and width, which was wrong and could cause zones to "disappear" if the first zone of the group was really small.
Grouping now works by taking into account the size of the zone and not the clipped to screen size for grouping decisions, to avoid having zone groups popping at the beginning and end of the window.
In order to have consistent results and avoid popping, we're using the start of the last zone in a group as reference instead of its end. This means that it now includes the zone width, so that we make the same decisions wether we are in considering new zones in the loop or to start grouping zones.
Altogether, this seems to have fixed any zone popping when panning, at the cost of not grouping the first/last zone if it is clipped, which seems to be less of an issue to me.
There might have been new modules loaded by another thread between the `SymInitialize` and `EnumProcessModules` calls.
Since we register the enumerated modules into the cache, we need to make sure that symbols for this module are loaded.
The only way to do that is to call `SymLoadModuleEx`, just like we do when finding new modules after `InitCallstack`.
gcc error:
public/tracy/../client/TracyScoped.hpp:102:9: error: ‘___tracy_scoped_zone.tracy::ScopedZone::m_connectionId’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
if( GetProfiler().ConnectionId() != m_connectionId ) return;
^~
assert() in release configuration resolves to empty code, while abort() is marked as [[noreturn]] and always is available.
gcc error:
error: ‘type’ may be used uninitialized in this function [-Werror=maybe-uninitialized]:
public/tracy/../client/../common/TracyAlign.hpp: In function ‘void tracy::SysTraceWorker(void*)’:
public/tracy/../client/../common/TracyAlign.hpp:22:11: error: ‘type’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
memcpy( ptr, &val, sizeof( T ) );
~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from public/TracyClient.cpp:26,
from X.cpp:
public/client/TracySysTrace.cpp:1258:35: note: ‘type’ was declared here
QueueType type;
^~~~
Tracy worker resets the IsConnected to false when finishing the
capture. If it finishes too quick, the waiting loop in capture.cpp
might never see IsConnected = true.
Red and blue channels were mislabeled. Otherwise, coding and decoding was
performed correctly, as far as the color channel order described in the manual
is followed by the user.
No change to the binary protocol was made.
This enables discovery of target function names (and recursively, their
bodies), even if such function has no samples and is not present in any
callstack.
These functions are only defined when -DTRACY_FIBERS is set. However,
the function is declared regardless of this declaration, which seems
like it could lead to obscure linking errors. I haven’t encountered any
of these specifically, but in my case, this distinction makes it more
difficult to produce correctly auto-generated bindings.
