Size of queue structure (which contains 3 ints, so is 12 bytes on
my Linux laptop) before & after, when filling a few sample images
when running in a 3000x2000 window:
* a pattern i drew
queue: 855,040
stack: 287,744
* mosaic
queue: 908,288
stack: 398,336
* mosaic 4x via panel magic tool
queue: 1,451,008
stack: 734,208
The queue grows ever large, and should shrink itself once
as the queue gets consumed. In the meantime, it seems to help.
At 3000x2000, with starters/mosaic.svg cut into four via Panels
magic tool, I get a VERY complicated drawing, which no longer
causes a crash.
(It crashed for me, even after some other improvements -- globalizing
many of the unchanging args to the recursive function, calling the
progress bar animation and sound effects calls less frequently --
helped prevent crashing for me with that starter image as-is.)
* Rotating brush angle is now a double, not an int
* Don't draw once on click; require some motion
(does not affect directional brushes, which include
a "no movement" shape in the middle of the brush bitmap)
Attempt to void crashing (by blowing up the stack) when doing
a flood-fill of a complicated shape on a large canvas
(e.g., `tuxpaint --3000x2000` with `starters/mosaic.svg`).
Following warnings still remain so far.
src/tuxpaint.c:199:2: warning: #warning "Attempting to define strcasestr(); if errors, build with -DHAVE_STRCASESTR" [-Wcpp]
199 | #warning "Attempting to define strcasestr(); if errors, build with -DHAVE_STRCASESTR"
| ^~~~~~~
src/parse.gperf: In function 'parse_one_option':
src/parse.gperf:306:45: warning: argument to 'sizeof' in 'memcpy' call is the same pointer type 'char *' as the destination; expected 'char' or an explicit length [-Wsizeof-pointer-memaccess]
306 | memcpy(offset+(char*)tmpcfg, &opt, sizeof(char*)); /* FIXME: This causes a warning; should it be 'sizeof(char)', or do we need to have the warning suppressed? -bjk 2021.10.14 */
| ^~~~
src/dirwalk.c: In function 'tp_ftw':
src/dirwalk.c:348:2: warning: #warning Failed to see DT_UNKNOWN [-Wcpp]
348 | #warning Failed to see DT_UNKNOWN
| ^~~~~~~
src/get_fname.c: In function 'get_fname':
src/get_fname.c💯3: warning: 'dir' may be used uninitialized in this function [-Wmaybe-uninitialized]
100 | snprintf(f, sizeof(f),
| ^~~~~~~~~~~~~~~~~~~~~~
101 | "%s%c%s",
| ~~~~~~~~~
102 | dir, (*name) ? '/' : '\0', /* Some mkdir()'s don't like trailing slashes */
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
103 | name);
| ~~~~~
magic/src/cartoon.c:178:99: warning: unused parameter 'last' [-Wunused-parameter]
178 | static void do_cartoon(void *ptr, int which ATTRIBUTE_UNUSED, SDL_Surface * canvas, SDL_Surface * last, int x, int y)
| ~~~~~~~~~~~~~~^~~~
When assembling UTF-8 in render_text_w() (to send to SDL_Pango),
we assumed `wchar_t` could encompass the entirety of Unicode
(up to U+10FFFF); however, on Windows `wchar_t` is only 16-bits,
meaning the test for characters <= U+FFFF was always true.
This reworks the if/elseif/else block, via some "#ifndef WIN32"
tests, to avoid this warning.
In the end, we need to replace our internal use of `wchar_t`
with something 32-bit, to allow for higher Unicode code points
(e.g., to support Emoji via the Text and Label tools).
Additonally, some work will need to be done to ensure that
text stored as Labels within saved Tux Paint images (PNGs) continued
to work correctly, and could be traded between platforms.
(Untested, but right now I assume a picture drawn on Linux where
`wchar_t` is 32-bit would break if you attempt to load it on Windows,
and possibly vice-versa?)
See https://sourceforge.net/p/tuxpaint/feature-requests/210/
