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.
AM_PATH_GLIB_2_0 m4 macro actually computes this value using
$PKG_CONFIG. Yet $PKG_CONFIG variable is the pkg-config tool looking for
target libraries (not host), hence it would return the executable
`glib-compile-resources` built for the target.
Also using the same variable name invalidates our test: our own
AC_PATH_PROG was never run as the variable was already set. And no
environment variable could override this test anymore either. This is
why I rename the test variable to HOST_GLIB_COMPILE_RESOURCES.
They are not perfect (not a designer here!) but a bit less packed than
the previous one. So hopefully more understandable.
(cherry picked from commit e326faa77c)
Squashed commit of the following:
commit ee1ff7d502658cfa1248a13a3f0348495db07eda
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Sun Jul 29 00:31:47 2018 +0900
Fixed that gimp-text-dir-ttb-* icons are lacked in Symbolic.
commit d87d012d697628da28fe90199cc04b95b72ba8ef
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Sat Jul 28 16:23:10 2018 +0900
Fix a typo.
commit cf0238bf7df56c384cdf3b7ec69557d14740f853
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Sat Jul 28 15:50:57 2018 +0900
Fixed seg fault error.
commit b07f60d06fa1a753fda5b4d46af01698c344154e
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Fri Jul 27 17:15:34 2018 +0900
Add support for vertical text writing.
https://gitlab.gnome.org/GNOME/gimp/issues/641
(cherry picked from commit 587d9bbb03)
It should now be possible to fully export our symbolic icons from a
single central file.
My long-standing bug of librsvg#250 is still opened and unfixed, but it
turns out most issues I encountered are anyway also problems when
recoloring symbolic icons in GTK+ (like using strokes instead of
fills!). So let's just bypass all problems at once by accounting for
these issues in the design.
(cherry picked from commit 4c68d5dfc9)
I tried to fix all the icons I could see which had issues regarding all
recoloring matters (using fill not stroke, change circle/ellipses to
paths, etc.) when looking at a blank canvas.
I'm sure I still miss a lot but that will do for now.
(cherry picked from commit 8811b0d916)
Sometimes even within symbolic icons, parts of the design must keep
fixed colors, when they are semantic. For instance this is the case for
the color-picker-(black|gray|white) icons or the gimp-default-colors.
The trick used by GTK+ to recolor is by supplying an additional CSS
style to icons which overrides inline CSS thanks to "! important"
keyword. Our own trick to circumvent this trick is to set "!important"
in inline CSS when one wishes not to have it overrided by the general
colors.
Right now I am doing the edit by hand with vim because Inkscape doesn't
seem to validate this keyword if I add it manually in its XML editor. So
what I did is add the "color-important" label on such object, and I will
later modify my SVG export tool to add !important on such object "fill"
values at export time.
(cherry picked from commit 5d5bbeb88b)
The current recolorization code only recolors paths and rectangles. In
particular it leaves circles and ellipses as-is.
I opened the merge request gtk!214 for this issue. But in the meantime,
it is quite easy to change circles and ellipses into path with "object
to path" in Inkscape.
A second problem is that it only recolors fills, not strokes, as
previously stated. So I need to remove strokes from icons, or transform
them to paths.
(cherry picked from commit fd46018203)
It seems not wide enough to differentiate easily the broken and
non-broken chains. So let's make this gap bigger.
(cherry picked from commit a5afb04501)
This time, 2 icons still had problems because of visible rectangles.
Fixing "gimp-prefs-folders" and "gimp-prefs-folders-mypaint-brushes".
(cherry picked from commit 2bb8afd119)
For anyone wishing to help me fix icons, here is the trick: apparently
GTK+ would fill the paths with CSS colors, not stroke them. So when we
have icon drawing based on path-stroking, they don't end up as expected.
In Inkscape, just run "Stroke to Path" to transform a stroke design in a
fill design.
I am fixing "gimp-tool-cage", "document-revert", "gimp-image-reload",
"gimp-reset" and "view-refresh". More to follow as we discover them, I
guess.
(cherry picked from commit 4b6869dd67)
With the symbolic-awareness of GTK+, vector icons are recolored (using
fg, success, warning and error colors). Unfortunately it was also
recoloring some rectangles with neither fill nor stroke, which were
using only to get appropriate icon size (these icons were therefore
displayed as just a square).
I made a quick pass in our icons to "fix" these. I expect I may have
missed some icons, or at the opposite, I may have broken other icons by
removing rectangles which should not have been removed. If you find any
such icon, please fix.
Also some icons do not look quite right just now. We will have to create
new guidelines on how to make symbolic icons and fix/redesign some, I
guess.
(cherry picked from commit 0c3659c5f1)
These are simple on purpose since the smaller size they are displayed at
is 12 px (in overlay dialogs) so it needs to be simple shapes.
Note by Jehan: gimpicons.h and Makefile.am not updated yet. Waiting for
the color icons first.
The dashboard dockable shows the current GEGL cache and swap sizes,
and their recent history. It has options to control the update
rate and history duration of the data, and an option to warn (by
raising/blinking the dialog) when the swap size approaches its
limit.
It's not finished yet, but I have already added all the individual
Freedesktop and GTK+ icons. The goal will be to have all the Symbolic
icons in this one file so that in the future we can just extract
individual SVG files from object IDs.
This was the original plan but librsvg was just too buggy and would not
extract the proper viewbox for some icons. Fortunately it seems that the
bug reports I made are finally starting to be taken into account so I am
hoping for a usable librsvg soon and starts the work which should have
been done from the start.
Try to sort all GIMP_ICON_* defines into FDO categories like in
https://specifications.freedesktop.org/icon-naming-spec/latest/ar01s04.html
Add defines for all icons we override, rename some icons to their FDO
standard names, and mark the ones we duplicate with a comment so we
don't forget to rename those to standard names in 3.0.
The 24 and 48 versions are slightly different, with the arrow on the
smaller version being bigger.
Preferences icon are also stored in all kind of size, like 16 and 22.
It may become necessary to make an alternative version for these smaller
sizes.
Freedesktop's "Thumbnail Managing Standard" defines 2 standard sizes
for thumbnails: 128x128 and 256x256 (section 5.3. Thumbnail Size).
Since the "folder" icon is used in-place of thumbnail when selecting a
folder in the GTK+ file dialog, it should also provide these default
sizes.
Commit 82737bf got rid of the only pieces of code where these icons were
used. Since they were never available in any version release of GIMP,
let's delete them from libgimpwidgets API as well.
Based off icons from Klaus Staedtler, who proposed separate icons for
layers, channels and paths. I only extracted the "cross" part for a
generate delete icon.
... and GIMP_STOCK_BUFFER redefined to "edit-paste", half-reverting
commit cb7d93d (except we use standard Freedesktop icon naming instead
of the GTK stock name).
The gimp-buffer icon was indeed definitely looking like a typical copy
icon, which was missing, and this has priority over a buffer icon.
These icons were massively renamed by Jehan, from a feature branch, in
order to fit either into Freedesktop's "Icon Naming Specification", or
as standard GTK+ icons.
