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!)
Suitable for simple 'pixel art'. Draws 8x8 pixel rectangles on
a grid across the canvas.
Sound effect created via a small Atari BASIC program sampled in
the open source 'Atari800' emulator (emulating the POKEY sound
chip), and trimmed in Audacity.
The 'Resources' directory is used in macOS development to test the binary
without building TuxPaint.app bundle, which is helpful for rapid application
development since creating the app bundle takes a long time.
It's been reported that the symlink in the Resources directory was causing the
'release' target to copy the files in the 'data' directory twice into the
source release tarball.
This change removes the static Resources directory but creates it dynamically
when the 'tuxpaint' target is built and removes it via 'clean' target so the
'release' target does not copy the files in the 'data' directory into the
source release tarball twice.
The `echo` command built into the default macOS shell doesn't understand -n.
This commit changes it to use "printf" instead which should be fairly portable
across other OS's. Feel free to change it back if it breaks anything.
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.
