Add a new "Messages" boolean parameter to performance logs, which,
when set, records GLIB log messages in the performance log as
markers, with an accompanying sample capturing their backtrace.
This option is enabled by default.
Add an option to record progressive performance logs. Progressive
logs contain complete information after each recorded sample, by
writing partial address maps at each sample, containing all new
addresses introduced by the sample. Furthermore, when recording a
progressive log, the output stream is flushed after each sample.
This allows recording complete logs even in cases where they can't
be properly terminated, such as when GIMP crashes or freezes in the
middle of the log.
Progressive logs are disabled by default, since they potentially
increase the sampling cost. They can be enabled through a toggle
in the log file-dialog, or through the
GIMP_PERFORMANCE_LOG_PROGRESSIVE environment varaible.
When recording a performance log, allow setting the log parametrs
through the file dialog. Currently, this includes the sample
frequency, and the option to include backtraces.
These options are still controllable through the
GIMP_PERFORMANCE_LOG_SAMPLE_FREQUENCY and
GIMP_PERFORMANCE_LOG_BACKTRACE environment variables. When set,
the variables override the values entered through the UI.
When building (at least on 32-bit), fixes this warning:
> app/widgets/gimpdashboard.c:3840:58: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
Unsigned long long is specified in the C99 standard to be at least
64-bit. So it's normal that the compiler complains, as a cast from
unsigned long long to a pointer has chances to go very wrong.
Yet gimp_backtrace_get_frame_address() actually returns a guintptr which
is type-compatible with gpointer so let's not give the compiler false
information and just use this type. Then cast it to unsigned long long
just for printing to dashboard log.
Add an assigned-threads variable to the dashboard's misc group,
showing the number of worker threads which currently have work
assigned. See commit
gegl@fc532f06773bd292c86abee31ac18f62e26d39df.
Add an active-thread variable to the dashboard's misc group,
showing the number of active worker threads. See commit
gegl@6a3a6314d4d4cd668e0f6164afc0fde8b9c7c001.
Step one: get rid of all those deprecation warnings that make
it hard to see any other warnings:
- add a lot of dummy API to GimpAction, GimpActionGroup, GimpUIManager
etc. which simply forwards to the deprecated GTK functions, they
will all go away again later
- rename GimpAction to GimpActionImpl
- add interface GimpAction that is implemented by all action classes,
creates a common interface and allows to remove some duplicated
logic from GimpToggleAction and GimpRadioAction, and at the same
time adds more features
Add a tile-alloc-total varaible to the dashboard's memory and misc
groups, showing the total amount of memory used by the tile
allocator (see commit
gegl@137e66e45138e8316f6403e53e8aa9a02ad523e7.)
The scratch allocator has been moved to GEGL (commit
gegl@b99032d799dda3436ffa8c1cc28f8b0d34fb965d). Remove gimp-
scratch, and replace all its uses with gegl-scratch.
Update the definition of the "cache-compressed" and "swap-
compressed" dashboard variables, to reflect the changes made by
GEGL commit gegl@dc22e997757ab91c180244d5290d094d2ea8572f.
When an error occurs, we want to prevent overwriting any previous
version of the file by incomplete contents. So run
g_output_stream_close() with a cancelled GCancellable to do so.
See also discussion in #2565.
Include instrumentation-variable descriptions in the var-defs
section of performance logs, so that they can be displayed
alongside their names when viewing the log.
... and G_TYPE_INSTANCE_GET_PRIVATE()
g_type_class_add_private() and G_TYPE_INSTANCE_GET_PRIVATE() were
deprecated in GLib 2.58. Instead, use
G_DEFINE_[ABSTRACT_]TYPE_WITH_PRIVATE(), and
G_ADD_PRIVATE[_DYNAMIC](), and the implictly-defined
foo_get_instance_private() functions, all of which are available in
the GLib versions we depend on.
This commit only covers types registered using one of the
G_DEFINE_FOO() macros (i.e., most types), but not types with a
custom registration function, of which we still have a few -- GLib
currently only provides a (non-deprecated) public API for adding a
private struct using the G_DEFINE_FOO() macros.
Note that this commit was 99% auto-generated (because I'm not
*that* crazy :), so if there are any style mismatches... we'll have
to live with them for now.
In addition to the verbose GIMP version, include in performance
logs the values of all environment variables beginning with BABL_,
GEGL_, or GIMP_, and of all the GEGL config options.
The "running" attribute (readable through
gimp_backtrace_is_thread_running(), and recorded in the performance
log) specifies if the thread was in a running or suspended state at
the time the backtrace was taken. It is accurate on Linux, but
only approximated on Windows.
Adapt the performance-log-expand.py tool to maintain this attribute
(and any future thread attributes we might add).
Add source filename and line number fields to the
GimpBacktraceAddressInfo struct, populated through
gimp_backtrace_get_address_info(). This is not currently supported
by the Linux backend, but is supported by the Windows backend,
which we'll be added in the next commit.
This function returns information about the given address, which
is currently mostly limited to the corresponding symbol
information, but we might want to add address-specific information
in the future, such as a line number.
Add an option to record a performance log through the dashboard.
The log contains a series of samples of the dashboard variables, as
well as the full program backtrace, when available. As such, it
essentially acts as a built-in profiler, which allows us to
correlate program execution with the information available through
the dashboard. It is meant to be used for creating logs to
accompany perofrmance-related bug reports, as well as for profiling
GIMP during development.
The sample frequency defaults to 10 samples per second, but can be
overridden using the GIMP_PERFORMANCE_LOG_SAMPLE_FREQUENCY
environment variable. Backtraces are included by default when
available, but can be suppressed using the
GIMP_PERFORMANCE_LOG_NO_BACKTRACE environment variable.
Logs are created through the new "record" button at the bottom of
the dashboard dialog. When pressed, a file dialog is opened to
select the log file, and, once confirmed, data is being recorded to
the selected file. Recording is stopped by pressing the "record"
button again (we use a highlight to indicate that recording is
active.)
While recording, the "reset" button is replaced with an "add marker"
button, which can be used to add event markers to the log. These
can be used to mark events of interest, such as "started painting"
and "stopped painting", which then appear in the log as part of the
sample stream. Markers are numbered sequentually, and the number
of the next (to-be-added) marker appears on the button. Shift-
clicking the button adds an empty (description-less) marker, which
is only identified by its number; this can be used when markers
need to be added quickly.
The log is an XML file, containing some extra information (such as
the output of "$ gimp -v", and symbol information) in addition to
the samples. The data in the file is delta-encoded to reduce the
file size, meaning that samples (as well as some other elements)
only specify the changes since the previous sample. This adds a
necessary decoding step before data can be processed; the next
commit adds a tool that does that.
There are currently no tools to actually analyze the data -- that's
still TBD -- but at least we can start gathering it.
... which reports the amount of data queued for writing to the
swap (see GEGL commit 64021786ee067cf66c038622719acc590e6341db.)
When the swap queue is full, a yellow color underlay is shown in
the history graph.
The "compression" field reports the ratio between the total size of
the data in the swap, and the total size the data would have had if
all tiles in the swap occupied a unique data block.
See GEGL commit 185f4450f2a51690b39112973c61f894c1ec3e41.
Add an "async" field to the dashboard's "misc" group, showing the
number of async operations currently in the "running" state (i.e.,
all those GimpAsync objects for which gimp_async_finish[_full]() or
gimp_async_abort() haven't been called yet).
When defining a dashboard group, allow specifying multiple
variables as input to the group meter's LED. The LED is active
when any of the specified variables evaluates to TRUE, and its
color is the combination of the active variable colors.
Remove the swap-busy variable, and use swap-reading and
swap-writing as inputs to the swap group's LED instead, so that the
LED's color indicates whether the swap is currently being read-
from, written-to, or both.
... to satisfy the inter-variable dependencies, so that the READING/
WRITING variables are based on the READ/WRITTEN values of the
current sample, and not the previous one.
Add "read" and "written" fields to the dashboard swap group, which
report the total amount of data read-from/written-to the tile swap,
respetively. These fields are non-active by default. When these
fields are active, show a color underlay in the swap group's meter,
indicating when data was beging read-from/written-to the swap.
Improve the swap busy indicator (used as the meter's LED), so that
it's active whenever data has been read-from/written-to the swap
during the last sampling interval, rather than at the point of
sampling.
Marc Espie