We received a report of Tux Paint generating too much heat on a MacBook
Pro (15-inch, 2017 running macOS Mojave 10.14.6). The bug report
included a screenshot of Activity Monitor's Energy Tab showing Tux Paint
having an Enegy Impact of "23.4" and Avg Energy Impact of "3.94".
Although we weren't able to reproduce the same conditions exactly, we
did observe Tux Paint having an Energy Impact level of around ~15 even
when idle on both macOS Yosemite 10.10.5 and Big Sur 11.1. Energy
Impact leve of ~25 when in use was not uncommon, and spiked to ~55. The
MacBook Air used for testing (11-inch, Early 2014) did not become hot
"to the touch" as was originally reported, but it did become noticibly
warm.
An investigation found the cause to be in two places:
1. Tux Paint's main loop runs fairly tightly, yielding only a minimum
time slice to the kernel after each iteration using SDL_Delay(1)
(1 millisecond). This has been increasd to 10 millisecond to give
more slice back to the kernel. Increasing the 1ms yield to 10ms
should be only minimally noticible as Tux Paint is primarily a human
interaction software and human eyes perceive responses < ~100ms as
immediate, giving us over 90ms to accomplish what we need to after
each iteration as opposed to the previous 99ms.
2. Enabling SDL's timer subsystem (SDL_INIT_TIMER), even when not used
actively, has a high impact on the energy impact. Some testing
showed the timer subsystem, though supposedly a part of SDL_Delay() and
SDL_GetTicks(), is not required to be enabled to use those functions.
It does require to be enabled, however, to use SDL_AddTimer() which
is only used in Tux Paint when scrolling. Tux Paint therefore has
been modified to enable the timer subsystem only when scrolling
starts and disable it when not scrolling.
The solution to #2 is not an ideal approach but it did provide a quick
solution to the user having the problem. Issue #2 should get resolved
naturally when we upgrade to SDL2 where the timer subsystem does not
appear to have the energy impact issue.
Tux Paint's export features will fail if the parent
of the export directory didn't exist. e.g., using the
default (either via XDG or hard-coded fallback) of
"~/Pictures/TuxPaint/", Tux Paint could not export if
"~/Pictures/" didn't exist yet. It will now try to
mkdir it as well. h/t Tim Dickson
Updated OPTIONS documents to explain this.
Also, documenting --exportdir in manpage (was missing!)
I found current git tree does not compile on Windows because
struct dirent has no member "d_type" on MinGW/MSYS2.
(TOYAMA Shin-ich via Tuxpaint-devel list)
Mended bug where a personal Template could not be loaded
due to how we tracked which entry in the "New" dialog
was the first template image.
Also, don't track directories when searching for Starters and
Templates (e.g., ".", "..", and ".thumbs"), since it's just
a waste of time/space.
When using the new (on 0.9.25) corner-drag option for creating
a new shape, "shape-locked" (1:1 aspect ratio) shapes -- square
and octagon -- would only rotate in a few positions, based on the
angle of ther vertices.
Corrected this, with no apparent adverse effect on other shapes,
in either drag mode (classic "from-center", and new "from-corner").
Also, removed extranous whitespace before EOLs in src/tuxpaint.c.
While we weren't attempting to save thumbnail PNG files of the
starter and templates that are scanned in the system-wide Tux Paint
directory, we WERE trying to incorrectly `mkdir` such directories
within the user's personal directory.
(e.g., "/home/kendrick/.tuxpaint//usr/local/share/tuxpaint/templates")
Mended.
Avoid shapes flipping upside-down during rotation step,
when stretching from right-to-left -- also when using the
original, center-based shape stretching mode.
On-screen keyboard (visible when the feature is enabled, while
using the "Text" and "Label" tools) now appears with larger
(48x48 pixel, vs 24x24 pixel) buttons, when Tux Paint's window
(or fullscreen) size is large enough to fit them with the
chosen layout.
(h/t Anat & Aviv, who suggested it to help with users of
eye-tracking systems)
Also, on-screen keyboard buttons use a slightly larger font
(16pt vs 12pt, previously seen on the small keyboard;
32pt on the large keyboard).
(h/t Jackson Bray for the suggestion)
Also, slight improvements to how circular eraser size calculations
are handled, to allow for radius down to ERASER_MIN of 5.
Adding control buttons to the Shapes tool, allowing for shapes
to be drawn from the center (as before) or from a corner
(more like other paint packages). The controls do nothing
at this time, but are visible and can be clicked. This is a
work in progress.
The controls may be removed using a configuration option.
Tux Paint can export an animated GIF to the export directory
(e.g., ~/Pictures/TuxPaint) from the Open->Slideshow dialog.
To do -- GIF's animated speed should be based on speed slider
in Slideshow dialog.
To do -- Document this new feature (and single image (PNG) export)
in the README documentation.
WORK IN PROGRESS -- Attempting to mend an issue where stamp descriptions
are not loading.
Also, making things safer when a problem occurs.
Using gcc 9.3.0 compiler, this was happening in 0.9.25 during
development, but also affected 0.9.24 and 0.9.23, which worked
fine under earlier versions of gcc.
Created "safe_" variations of 'strncpy()', 'strncat()',
and 'snprintf()', to ensure a truncated source string doesn't
leave the destination buffer without a NUL termination character.
Replaced all calls (in "tuxpaint.c" only, so far) to the standard
functions with calls to the new safer versions.
Replaced most calls to plain 'strcpy()', 'strcat()' and
'sprintf()' (which can cause buffer overruns) with the new functions.
From "Open" dialog, select an image (single click, or use
arrow keys / etc., to highlight the image), then select the
"Export" button at the lower right.
The image will be saved in the export directory. By default
this will be based on the config found via the XDG_CONFIG_HOME
environment variable, which is scanned for a "XDG_PICTURES_DIR"
setting. If none is found, "Pictures" in the directory specified
by the HOME env. var. will be used. In both cases, a new
"TuxPaint" subdirectory will be created, and exports will be placed
there.
The export location may be overridden using the "--exportdir"
command-line option or "exportdir" config file option
(e.g., "--exportdir /path/to/dir" or "exportdir=/path/to/dir",
respectively). In this case, the directory is assumed to preexist,
and no "TuxPaint" subdirectory will be made.
There's currently no way to disable the export feature altogether.
If there's demand, we can add it as a simplification option.
Finally, this feature simply copies the PNG file (but no extra
data files) from Tux Paint's "saved" directory to the export dir.
Closes https://sourceforge.net/p/tuxpaint/feature-requests/192/
GIF export button now jumps to a process that iterates through the
chosen saved images, loading each (but not yet saving as a GIF).
It then returns to the Open->Slideshow dialog, and displays a
pop-up dialog that shows a success/fail message.
Also, adding an icon for a regular static image "Export" option,
to be added to the main Open dialog.
Using XDG's user dir settings to determine where pictures are
stored for a user (e.g., "~/Pictures" -- used as a fallback).
May be overridden using "--exportdir".
Also, while I was updating some docs, replace references to
"Mac OS X" with "macOS", the new name of that OS these days.
