Known Issues
------------
- No printing support.
- No typing support using the OS virtual keyboard. iOS needs to be signalled
to bring up the virtual keyboard when the text tool is active. We also may
need to do some finagling to make IM work with the virtual keyboard.
- OS language detection doesn't work yet.
- Quitting doesn't close the app. It just displays a black screen until it is
force-closed.
- Need to include cross-compilation instructions.
Possible Issues
---------------
- No text display. This is likely an issue with how pango and related
libraries were cross-compiled rather than an issue with Tux Paint code. From
the error output it appears to be a font rendering issue.
- SVG integration couldn't be tested because RSVG library has not yet be
cross-compiled successfully.
- Only tested under the iOS Simulator (and not on an actual iOS device yet.)
Usefull for people with coarse input devices that need bigger buttons but got color buttons too narrow.
Just added the option, all the support code where already in place.
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!)
