They were rendering very large, and shorter strings were
being shrunk down less horizontally, so appearing stretched out
(and touching the edges of the button needlessly).
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.
