When moving a text layer using the text tool (through alt+drag),
don't change the layer's box mode to "fixed", which is unnecessary,
since the layer's size isn't affected.
While editing a text layer with the text tool, update the layer's
frame when the layer moves, which most notably happens when
undoing/redoing a move operation while the text tool is active.
The various functions of the text tool currently block and unblock
drawing (through gimp_text_tool_[un]block_drawing()) implicitly,
and in a non-symmetric fashion, which makes the tool's logic rather
fragile. Instead, require blocking/unblocking to be done
symmetrically, and explicitly block/unblock drawing as necessary in
all functions.
Improve out-of-range check in gimp_backtrace_find_thread_by_id().
Remove unnecessary #include <exchndl.h> in gimpbacktrace-windows.c,
and revert commit 644234e99d (the
DrMingw detection happens at runtime). The Windows backend can
work without DrMingw, it just can't find all the symbols, and
doesn't provide source-location information.
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).
The Windows backend produces full, multithreaded backtraces. When
DrMingw is available, it also provides full symbol and (where
available) source-location information. Otherwise, it provides
symbol information for most of our libraries, but not for the GIMP
binary itself.
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.
In all the selection tools, show an error (and a BAD cursor
modifier) wheh starting a selection, if the current selection is
empty, and the tool is in SUBTRACT or INTERSECT mode (in which
case, the selection has no effect).
performance-log-expand.py decodes a delta-encoded performance log
by expanding the deltas, producing a log where each sample (and
other relevant elements) contain complete information. Note that
the structure of expanded logs is identical to that of delta-
encoded logs, the expanded log simply has no deltas.
performance-log-resolve.py resolves symbol information in
backtraces. The logs produced by GIMP only specify the program
counter at each stack frame, providing an address-map to map
program-counter addresses to actual symbols separately. This tool
looks up each program-counter address in the address map,
incorporating the relevant symbol information directly into the
backtrace.
Both tools read their input from STDIN, and write their output to
STDOUT, and can be chained in a pipeline (with
gimp-performance-log-expand.py appearing first).
Note that these tools require Python 3.
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.
GimpBacktrace provides an interface for creating and traversing
multi-threaded backtraces, as well as querying symbol information.
While we already have some backtrace functionality, it relies on
external tools for the most part, and as such is rather expensive,
and is only meant for producing opaque backtraces. GimpBacktrace,
on the other hand, is meant to be relatively cheap (we're going to
use it for profiling,) and allow inspection of the backtrace data.
In the future, it might make sense to replace some, or all, of the
other backtrace functions with GimpBacktrace.
GimpBacktrace currently only supports Linux. By default, it uses
dladdr() to query symbol information, which is somewhat limited (in
particular, it doesn't work for static functions.) When libunwind
is installed, GimpBacktrace uses it to get more complete symbol
information. libunwind is currently an optional dependency, but it
might make sense to promote it to a mandatory, or opt-out,
dependency, as it's lightweight and widely available.
On other platforms, the GimpBacktrace interface can still be used,
but it always returns NULL backtraces.
Also remove '.' at end of some <li>. `appstream-util` does not like full
stops in item lists, when in `validate-strict` mode (we don't test in
this mode, but it is worth improving the warning list a bit).
The jpeg_save_markers API has existed since 27th March 1998! So it's
safe to assume that everybody has it, and there's no need to check for
it.
libjpeg-turbo has had a libjpeg.pc since 2016, and the IJG's software
has it too. Dropping support for old libraries is a small price to pay
for the benefits of a simpler build.
https://gitlab.gnome.org/GNOME/gimp/merge_requests/28
Move the call to gimp_filter_tool_disable_color_picking() from the
filter-tool's dialog "unmap" handler to gimp_filter_tool_halt().
Since commit ec80a88513, we
explicitly destroy the GUI when halting the filter tool, which
happens before the dialog's unmap handler is called, which could
potentially result in a dangling pointer to the active color-picker
widget in gimp_filter_tool_disable_color_picking().
This code was originally written by Thomas G. Lane and Todd Newman,
and proposed for inclusion in the Independent JPEG Group's software.
However, that fell through when Tom left the IJG. It was not written by
Marti Maria - Little cms only had a copy of that code.
This code has recently been merged into libjpeg-turbo, so it seems
reasonable to now consider libjpeg-turbo as the canonical source of
these files. However, since the GIMP carries the original version of
the code proposed for IJG's JPEG, and doesn't contain any of the more
recent and minor tweaks made during its inclusion in libjpeg-turbo,
only the original copyright holders (ie., Thomas G. Lane and Todd
Newman) are mentioned.
The relevant license text was lifted from the Independent JPEG Group's
software, similar to the way it's done in Chromium and other users of
this code.
https://gitlab.gnome.org/GNOME/gimp/issues/2119
... 100% position anymore
In GimpGuideTool, use a closed [0, max_position] range as the
allowable range for new/repositioned guides (where max_position is
either the image's width or height), so that guides can be placed
at the right/bottom edge of the image.
In gimp_image_merge_layers(), explicitly fetch the graph of the top
layer's parent layer (if exists), to make sure that the top layer's
graph has a parent node. We already fetch the image graph, which
takes care of top-level layers, however, if the top layer is a
child of an invisible layer group, as is the case in the wavelet-
decompose plug-in, this is not generally enough to guarantee that
the group's graph is constructed.
In gimp_filter_tool_halt(), explicitly clear the GUI container
before clearing filter_tool->config, since the tool might be halted
during the GUI dialog's delete event, in which case the GUI will
only be implicitly destroyed *after* the function returns. The
destruction of the GUI might fire signals whose handlers rely on
filter_tool->config, so we need to make sure it happens while it's
still alive.
In particular, this fixes a CRITICAL in the threshold tool, which
occurs due to the histogram view's "range-changhed" signal being
fired during its destruction, and its handler accessing
filter_tool->config.
