tuxpaint-devel Mailing List for Tux Paint

Oh, actually, the code is still there since we haven't migrated to SDL3
yet. I'm getting ahead of myself.

On Fri, Jun 5, 2026 at 10:47 PM Mark Kim <mar...@gm...> wrote:

> >  * Did you notice lag before this patch?
>
> No, but is the issue in question by any chance the same issue macOS saw
> with SDL2 for which I submitted this
> <https://sourceforge.net/p/tuxpaint/tuxpaint/ci/c1b2811bbf3898c02de5f0b4b9be70f6a3771b2a/> commit
> as a workaround? (FYI, that workaround for macOS has since been removed
> after the migration to SDL3.)
>
>
> On Fri, Jun 5, 2026 at 6:20 AM Bill Kendrick <nb...@so...> wrote:
>
>>
>> Hi all,
>>
>> Over in https://sourceforge.net/p/tuxpaint/bugs/302/ Chong Kai Xiong
>> reported "Bad input lag in GNOME Wayland when run in fullscreen".
>>
>> Please see that ticket for the research that Pere and they have done
>> over the past couple months.
>>
>> Pere recently posted a patch which changes how Tux Paint deals with
>> `SDL_UpdateRect()` calls.
>>
>> FYI, these days, that old SDL1.2-era function is now a wrapper
>> inside Tux Paint, which calls SDL2 functions (`SDL_UpdateTexture()`,
>> `SDL_RenderClear()`, `SDL_RenderCopy()`, and SDL_RenderPresent()`).
>>
>> With Pere's change, it simply calls `SDL_Flip()`, which once again
>> is our own function that wraps those same SDL2 function calls to
>> replicate what the old SDL1.2 function did.
>>
>> However, with Pere's patch, SDL_Flip() now IGNORES refresh requests
>> if they're arriving too quickly, to avoid updating the screen more
>> times than the physical screen (VSYNC).
>>
>> I wrapped Pere's changes in an `#ifdef VSYNC_WORKAROUND` test,
>> and committed it to master branch:
>>
>>
>> https://sourceforge.net/p/tuxpaint/tuxpaint/ci/d707ca93924f13fc4edca80c4939d89fa70ce4c1/
>>
>> I've asked Chong Kai Xiong to please test, but I'd also like others
>> here on the Tux Paint team to try it out as well, and report back.
>>
>>  * Did you notice lag before this patch?
>>    + Fullscreen only? Or windowed do? Only at certain resolutions?
>>  * If you noticed lag before, does this patch help?
>>  * Do you notice any side-effects with this patch?
>>  * Please share whatever hardware, OS, and library specs you can?
>>    (e.g., if Linux, which distro, what desktop environment, what
>>    version of Xorg or Wayland, and what version of libSDL2?)
>>
>> Thanks in advance!
>>
>> -bill!
>>
>>
>>
>> _______________________________________________
>> Tuxpaint-devel mailing list
>> Tux...@li...
>> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>>
>

>  * Did you notice lag before this patch?

No, but is the issue in question by any chance the same issue macOS saw
with SDL2 for which I submitted this
<https://sourceforge.net/p/tuxpaint/tuxpaint/ci/c1b2811bbf3898c02de5f0b4b9be70f6a3771b2a/>
commit
as a workaround? (FYI, that workaround for macOS has since been removed
after the migration to SDL3.)


On Fri, Jun 5, 2026 at 6:20 AM Bill Kendrick <nb...@so...> wrote:

>
> Hi all,
>
> Over in https://sourceforge.net/p/tuxpaint/bugs/302/ Chong Kai Xiong
> reported "Bad input lag in GNOME Wayland when run in fullscreen".
>
> Please see that ticket for the research that Pere and they have done
> over the past couple months.
>
> Pere recently posted a patch which changes how Tux Paint deals with
> `SDL_UpdateRect()` calls.
>
> FYI, these days, that old SDL1.2-era function is now a wrapper
> inside Tux Paint, which calls SDL2 functions (`SDL_UpdateTexture()`,
> `SDL_RenderClear()`, `SDL_RenderCopy()`, and SDL_RenderPresent()`).
>
> With Pere's change, it simply calls `SDL_Flip()`, which once again
> is our own function that wraps those same SDL2 function calls to
> replicate what the old SDL1.2 function did.
>
> However, with Pere's patch, SDL_Flip() now IGNORES refresh requests
> if they're arriving too quickly, to avoid updating the screen more
> times than the physical screen (VSYNC).
>
> I wrapped Pere's changes in an `#ifdef VSYNC_WORKAROUND` test,
> and committed it to master branch:
>
>
> https://sourceforge.net/p/tuxpaint/tuxpaint/ci/d707ca93924f13fc4edca80c4939d89fa70ce4c1/
>
> I've asked Chong Kai Xiong to please test, but I'd also like others
> here on the Tux Paint team to try it out as well, and report back.
>
>  * Did you notice lag before this patch?
>    + Fullscreen only? Or windowed do? Only at certain resolutions?
>  * If you noticed lag before, does this patch help?
>  * Do you notice any side-effects with this patch?
>  * Please share whatever hardware, OS, and library specs you can?
>    (e.g., if Linux, which distro, what desktop environment, what
>    version of Xorg or Wayland, and what version of libSDL2?)
>
> Thanks in advance!
>
> -bill!
>
>
>
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>

Hi all,

Over in https://sourceforge.net/p/tuxpaint/bugs/302/ Chong Kai Xiong
reported "Bad input lag in GNOME Wayland when run in fullscreen".

Please see that ticket for the research that Pere and they have done
over the past couple months.

Pere recently posted a patch which changes how Tux Paint deals with
`SDL_UpdateRect()` calls.

FYI, these days, that old SDL1.2-era function is now a wrapper
inside Tux Paint, which calls SDL2 functions (`SDL_UpdateTexture()`,
`SDL_RenderClear()`, `SDL_RenderCopy()`, and SDL_RenderPresent()`).

With Pere's change, it simply calls `SDL_Flip()`, which once again
is our own function that wraps those same SDL2 function calls to
replicate what the old SDL1.2 function did.

However, with Pere's patch, SDL_Flip() now IGNORES refresh requests
if they're arriving too quickly, to avoid updating the screen more
times than the physical screen (VSYNC).

I wrapped Pere's changes in an `#ifdef VSYNC_WORKAROUND` test,
and committed it to master branch:

  https://sourceforge.net/p/tuxpaint/tuxpaint/ci/d707ca93924f13fc4edca80c4939d89fa70ce4c1/

I've asked Chong Kai Xiong to please test, but I'd also like others
here on the Tux Paint team to try it out as well, and report back.

 * Did you notice lag before this patch?
   + Fullscreen only? Or windowed do? Only at certain resolutions?
 * If you noticed lag before, does this patch help?
 * Do you notice any side-effects with this patch?
 * Please share whatever hardware, OS, and library specs you can?
   (e.g., if Linux, which distro, what desktop environment, what
   version of Xorg or Wayland, and what version of libSDL2?)

Thanks in advance!

-bill!

Pushed it to the branch "feature/testsuite".

On Sun, Mar 15, 2026 at 6:35 PM Pere Pujal i Carabantes <per...@gm...>
wrote:

> El dg. 15 de 03 de 2026 a les 20:56 +0000, en/na Bill Kendrick va escriure:
> > On Sun, Mar 15, 2026 at 01:57:27PM -0400, Mark Kim wrote:
> > > Hi there,
> > >
> > > Would anyone be opposed to me committing some code written by AI
> (Claude
> > > Opus 4.6 model)?
> > >
> > > It's just some testing suite for now, and the diff is fairly clean:
> > >
> > >    - new folder tests/ containing test codes.
> >
> > I'm intrigued to see what kind of tests you (& Claude) have got!
> >
> >
> > >    - updated Makefile to build and run the test codes and report the
> > >    result. Lines are only added -- no existing lines are deleted or
> modified.
> > >    - new file CLAUDE.md for the AI to get a quick understanding of the
> > >    codebase without having to rescan the folder every time it starts.
> > >
> > > Also happy to push it to a separate branch if we want to review the
> code
> > > before merging it into the main branch.
> >
> > Let's start with a separate branch.  I have precisely zero experience
> > with AI (and have had pretty much no time or interest, on top of it),
> > so I have no idea what to expect. :-)
> >
> > Thanks!!!
> >
> > -bill!
>
> Hi, Last december I commited a patch with some parts made by Gemini to the
> Tuxpaint Android port at github.
>
> https://github.com/tux4kids/Tuxpaint-Android/pull/50
> so I guess I can't opose to AI as long as the person providing the change
> understands it :)
>
> Pere
>
>
> BTW, Worth uploading my personal sdl3 branch to an official sdl3 branch?
>
>
> Thanks
>
>
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>

El dg. 15 de 03 de 2026 a les 20:56 +0000, en/na Bill Kendrick va escriure:
> On Sun, Mar 15, 2026 at 01:57:27PM -0400, Mark Kim wrote:
> > Hi there,
> > 
> > Would anyone be opposed to me committing some code written by AI (Claude
> > Opus 4.6 model)?
> > 
> > It's just some testing suite for now, and the diff is fairly clean:
> > 
> >    - new folder tests/ containing test codes.
> 
> I'm intrigued to see what kind of tests you (& Claude) have got!
> 
> 
> >    - updated Makefile to build and run the test codes and report the
> >    result. Lines are only added -- no existing lines are deleted or modified.
> >    - new file CLAUDE.md for the AI to get a quick understanding of the
> >    codebase without having to rescan the folder every time it starts.
> > 
> > Also happy to push it to a separate branch if we want to review the code
> > before merging it into the main branch.
> 
> Let's start with a separate branch.  I have precisely zero experience
> with AI (and have had pretty much no time or interest, on top of it),
> so I have no idea what to expect. :-)
> 
> Thanks!!!
> 
> -bill!

Hi, Last december I commited a patch with some parts made by Gemini to the Tuxpaint Android port at github.

https://github.com/tux4kids/Tuxpaint-Android/pull/50
so I guess I can't opose to AI as long as the person providing the change understands it :)

Pere
 

BTW, Worth uploading my personal sdl3 branch to an official sdl3 branch?


Thanks

On Sun, Mar 15, 2026 at 01:57:27PM -0400, Mark Kim wrote:
> Hi there,
> 
> Would anyone be opposed to me committing some code written by AI (Claude
> Opus 4.6 model)?
> 
> It's just some testing suite for now, and the diff is fairly clean:
> 
>    - new folder tests/ containing test codes.

I'm intrigued to see what kind of tests you (& Claude) have got!


>    - updated Makefile to build and run the test codes and report the
>    result. Lines are only added -- no existing lines are deleted or modified.
>    - new file CLAUDE.md for the AI to get a quick understanding of the
>    codebase without having to rescan the folder every time it starts.
> 
> Also happy to push it to a separate branch if we want to review the code
> before merging it into the main branch.

Let's start with a separate branch.  I have precisely zero experience
with AI (and have had pretty much no time or interest, on top of it),
so I have no idea what to expect. :-)

Thanks!!!

-bill!

Hi there,

Would anyone be opposed to me committing some code written by AI (Claude
Opus 4.6 model)?

It's just some testing suite for now, and the diff is fairly clean:

   - new folder tests/ containing test codes.
   - updated Makefile to build and run the test codes and report the
   result. Lines are only added -- no existing lines are deleted or modified.
   - new file CLAUDE.md for the AI to get a quick understanding of the
   codebase without having to rescan the folder every time it starts.

Also happy to push it to a separate branch if we want to review the code
before merging it into the main branch.

Thanks,
Mark

It is undeniably most funny story.

On Mon, 12 Jan 2026 at 01:37, Bill Kendrick <nb...@so...> wrote:

>
> A friend spotted this on Hacker News and it's adorable :)
> https://news.ycombinator.com/item?id=46570440
>
>   One day, [my daughter is] playing in Tux Paint, and a print out of
>   her image falls from the sky. We had a desk with shelving. Two shelves
>   above the monitor was our printer. She'd clicked on the print button,
>   without knowing what it would do, or for that matter, even knowing
>   what a printer was or that we had one.
>
>   She was SO excited, "look, look, what I was drawing came out on paper
>   from the ceiling"
>
> :-D
>
> -bill!
>
>
>
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>

A friend spotted this on Hacker News and it's adorable :)
https://news.ycombinator.com/item?id=46570440

  One day, [my daughter is] playing in Tux Paint, and a print out of
  her image falls from the sky. We had a desk with shelving. Two shelves
  above the monitor was our printer. She'd clicked on the print button,
  without knowing what it would do, or for that matter, even knowing
  what a printer was or that we had one.

  She was SO excited, "look, look, what I was drawing came out on paper
  from the ceiling"

:-D

-bill!

El dv. 17 de 10 de 2025 a les 23:01 +0100, en/na Bill Kendrick va escriure:
> On Fri, Oct 17, 2025 at 11:35:07PM +0200, Pere Pujal i Carabantes wrote:
> > Hi all,
> > 
> > In the Tux Paint Android Github we have a pull request that implements an oversimplified interface for Tux Paint addressed to young children.
> > It also implements an increasing of the canvas via hide/show the color row and Tux row.
> > 
> > If you want to test it, there is an apk provided, and I've just made a small patch to allow compile it under Linux, so we can see it without having to compile it for Android.
> > 
> > The pull request by Ruben Barkow-Kuder, BTW, Ruben, Welcome if you come here :)
> > https://github.com/tux4kids/Tuxpaint-Android/pull/48
> 
> Hm, this is interesting, though it definitely seems to need some work
> before it's ready for prime time...  at least, based on the Linux desktop
> version you shared here, Pere:
> 
> > The Tux Paint's source code with that implementation copied back from the P.R.at 347c58a6a03f7cb46ea92c6173e9e210ad089b19 commit and with my patch:
> > https://provant.freeddns.org/pere/public_html/Tux%20Paint/devel/20251017/tuxpaint-Kids-by-Ruben-Barkow-Kuder.tar.gz
> 
> It compiles fine, though has many warnings.  Is it based off the
> latest code in master branch at SourceForge or in GitHub?
> (I'm down to a lovely zero compiler warnings when I run `make`
> against master :-) )

It is based on the 0.9.35 code we have at github


> 
> The UI seems to have a few issues.  When I switch back to default/classic
> mode, the icons on the buttons seem to be drawn twice, slightly offset,
> giving a double-vision effect.

Yep, not sure if this is my patch, it touches something related to loading images.


> 
> It seems in some situations, when the color buttons appear, they don't
> disappear, or the big button to call them up doesn't reappear.
> 
> Also, I have the ability to choose colors in unexpected situations,
> e.g. when using the Eraser.
> 
> A lot of things don't get removed properly (e.g., I end up with little
> chunks of Tux penguin at the bottom left, as he changes postures).

Thinking about expanding the canvas, it sounds more for advanced users?


> 
> The sound on/off mute button doesn't seem to work, unless the classic
> UI is shown.

Seems this is intended to avoid small children to play with sound, but then, why a button at all for them?


> 
> I tried running it in a 640x480, and see that the toolbar on the left
> has scroll buttons, but when I scrolled down, and then tried to scroll
> back up, my clicks on the up-arrow at the top were getting misinterpreted.
> It looks like the toggle button is being detected a lot lower than it's
> appearing visually (i.e., outside of the button graphic), and in fact
> within the scroll-up button's realm. :-(
> 
> Save never becomes available.  Undo doesn't seem to do anything
> (and therefore redo doesn't become available).  If I draw some things
> in classic mode, and then hit Undo, then go to child mode, the Redo
> button is STILL not available.  So I figure whatever's going on with
> these buttons is as-of-yet unfinished...?
> 
> 
> > Note that it differs somehow in Linux vs Android as in the original implementation there seems to be some behaviour exclusively implemented in Android, for example the 3 seconds lock for changing the
> > interface, the expert/kids button at the top left of the screen.
> > 
> > Are we interested in anything of this?
> 
> I find it an interesting idea, but I feel like it takes away a lot of
> what makes Tux Paint fun and special (stamps and magic, in particular)
> when the "child mode" is in place...  but then they're easily accessible
> by toggling back to normal mode.  So, IMO, why bother? :-)

Well, to toggle to normal mode in Android you have to hit the button for 3 seconds, this is one of the differences with the Linux version.
Another difference is that in Android it starts in child mode.


> 
> If there's a need for an app that only does paint, eraser, fill,
> undo/redo, then it probably makes sense to just create that simple
> tool from scratch.
> 
> If we need a way for the existing UI to become even simpler, then
> we can try and address that within the existing UI code (like we
> did when we added more scrollbars, larger button support, etc.)
> 
> 
> > Personally I don't like the interface changing on the fly, but I would like the simplified interface as result of a expertise setting in the config.
> > As for the increase of canvas I guess the same, let the users choose if they want it.
> 
> I tend to agree.
> 
> From a real-world-usage point of view, one of the things I see people
> most confused/annoyed by is Tux Paint's inability to resize on the fly.
> (Not realizing its a setting, which admittedly is an akward way of
> handling things.  But we started all this with SDL, a game library
> from a certain era, hehehe.)
> 
> So if I were to spend time on Tux Paint things right now, it would
> be (in no particular order):
> 
>  * brush sizing (to complement brush spacing)
>  * redoing all of the UI graphics (button icons, etc.) "in HD"


>  * on-the-fly window resizing

This needs some thinking, size of the drawing? I assume it will not change when resizing the window, at least not change lossy, but then we will need scrollbars if the canvas ends up smaller than the
drawing, and what to do if the canvas ends larger than the drawing?, let the drawing at its original size in a half empty canvas?, scale the _display_ of the drawing to fit the canvas?, expand the
drawing with empty space?, but then what about starters?
And if we make the canvas size independent of the drawing size then a setting like --drawing-size will make sense...

>  * SDL 3 port
>  * improved tablet support

In progress :)


>  * just, like, improving everything :-D

Ofc :)


Thanks!
Pere

> 
> 
> Thanks a lot for your efforts into making this accessible,
> and I'm happy to continue talking about it / considering things.
> Perhaps once it's all up and running _correctly_, I might be
> convinced that it'd be an interesting option to add.
> (It'd need to be worth the maintenance costs, of course!)
> 
> So far, though, I don't quite see the demand for this particular
> feature. :shrug:  I'm curious what others think, though!
> 
> -bill!
> 
> > Thanks for any comments :)
> > Pere
> > 
> > 
> > P.S. The small patch, already applied, that allows to compile and run under Linux
> > 
> > pere@lleopard:~/test/tuxpaint-tuxpaint-Kids-by-Ruben-Barkow-Kuder$ diff /mnt/nvme0n1p1/pere/tuxpaint/test/Tuxpaint-Kids/app/src/main/jni/tuxpaint/src /home/pere/test/tuxpaint-tuxpaint-Kids-by-Ruben-
> > Barkow-Kuder/src 
> > diff /mnt/nvme0n1p1/pere/tuxpaint/test/Tuxpaint-Kids/app/src/main/jni/tuxpaint/src/i18n.c /home/pere/test/tuxpaint-tuxpaint-Kids-by-Ruben-Barkow-Kuder/src/i18n.c
> > 1329,1332d1328
> > <     locale = android_locale();
> > < #endif
> > < 
> > <   if (locale == NULL)
> > 1334c1330,1331
> > < 
> > ---
> > > #endif
> > >   
> > diff /mnt/nvme0n1p1/pere/tuxpaint/test/Tuxpaint-Kids/app/src/main/jni/tuxpaint/src/tuxpaint.c /home/pere/test/tuxpaint-tuxpaint-Kids-by-Ruben-Barkow-Kuder/src/tuxpaint.c
> > 4298a4299
> > > #ifdef __ANDROID__
> > 4305a4307
> > > #endif /* #ifndef NOSOUND */
> > 4719a4722
> > > #ifdef __ANDROID__
> > 4721a4725
> > > #endif
> > 10064c10068,10069
> > <         
> > ---
> > >         if (strcasestr(fname, "handle_icons") && strcasestr(fname, ".png"))
> > > 	  {
> > 10066c10071
> > <         SDL_Surface *handle_icon = loadimage(handle_fname);
> > ---
> > >         SDL_Surface *handle_icon = loadimage(fname);
> > 10090c10095
> > <         }
> > ---
> > >         }}
> > 
> > 
> > _______________________________________________
> > Tuxpaint-devel mailing list
> > Tux...@li...
> > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
> > 
> 
> 
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

On Fri, Oct 17, 2025 at 11:35:07PM +0200, Pere Pujal i Carabantes wrote:
> Hi all,
> 
> In the Tux Paint Android Github we have a pull request that implements an oversimplified interface for Tux Paint addressed to young children.
> It also implements an increasing of the canvas via hide/show the color row and Tux row.
> 
> If you want to test it, there is an apk provided, and I've just made a small patch to allow compile it under Linux, so we can see it without having to compile it for Android.
> 
> The pull request by Ruben Barkow-Kuder, BTW, Ruben, Welcome if you come here :)
> https://github.com/tux4kids/Tuxpaint-Android/pull/48

Hm, this is interesting, though it definitely seems to need some work
before it's ready for prime time...  at least, based on the Linux desktop
version you shared here, Pere:

> The Tux Paint's source code with that implementation copied back from the P.R.at 347c58a6a03f7cb46ea92c6173e9e210ad089b19 commit and with my patch:
> https://provant.freeddns.org/pere/public_html/Tux%20Paint/devel/20251017/tuxpaint-Kids-by-Ruben-Barkow-Kuder.tar.gz

It compiles fine, though has many warnings.  Is it based off the
latest code in master branch at SourceForge or in GitHub?
(I'm down to a lovely zero compiler warnings when I run `make`
against master :-) )

The UI seems to have a few issues.  When I switch back to default/classic
mode, the icons on the buttons seem to be drawn twice, slightly offset,
giving a double-vision effect.

It seems in some situations, when the color buttons appear, they don't
disappear, or the big button to call them up doesn't reappear.

Also, I have the ability to choose colors in unexpected situations,
e.g. when using the Eraser.

A lot of things don't get removed properly (e.g., I end up with little
chunks of Tux penguin at the bottom left, as he changes postures).

The sound on/off mute button doesn't seem to work, unless the classic
UI is shown.

I tried running it in a 640x480, and see that the toolbar on the left
has scroll buttons, but when I scrolled down, and then tried to scroll
back up, my clicks on the up-arrow at the top were getting misinterpreted.
It looks like the toggle button is being detected a lot lower than it's
appearing visually (i.e., outside of the button graphic), and in fact
within the scroll-up button's realm. :-(

Save never becomes available.  Undo doesn't seem to do anything
(and therefore redo doesn't become available).  If I draw some things
in classic mode, and then hit Undo, then go to child mode, the Redo
button is STILL not available.  So I figure whatever's going on with
these buttons is as-of-yet unfinished...?


> Note that it differs somehow in Linux vs Android as in the original implementation there seems to be some behaviour exclusively implemented in Android, for example the 3 seconds lock for changing the
> interface, the expert/kids button at the top left of the screen.
> 
> Are we interested in anything of this?

I find it an interesting idea, but I feel like it takes away a lot of
what makes Tux Paint fun and special (stamps and magic, in particular)
when the "child mode" is in place...  but then they're easily accessible
by toggling back to normal mode.  So, IMO, why bother? :-)

If there's a need for an app that only does paint, eraser, fill,
undo/redo, then it probably makes sense to just create that simple
tool from scratch.

If we need a way for the existing UI to become even simpler, then
we can try and address that within the existing UI code (like we
did when we added more scrollbars, larger button support, etc.)


> Personally I don't like the interface changing on the fly, but I would like the simplified interface as result of a expertise setting in the config.
> As for the increase of canvas I guess the same, let the users choose if they want it.

I tend to agree.

>From a real-world-usage point of view, one of the things I see people
most confused/annoyed by is Tux Paint's inability to resize on the fly.
(Not realizing its a setting, which admittedly is an akward way of
handling things.  But we started all this with SDL, a game library
from a certain era, hehehe.)

So if I were to spend time on Tux Paint things right now, it would
be (in no particular order):

 * brush sizing (to complement brush spacing)
 * redoing all of the UI graphics (button icons, etc.) "in HD"
 * on-the-fly window resizing
 * SDL 3 port
 * improved tablet support
 * just, like, improving everything :-D


Thanks a lot for your efforts into making this accessible,
and I'm happy to continue talking about it / considering things.
Perhaps once it's all up and running _correctly_, I might be
convinced that it'd be an interesting option to add.
(It'd need to be worth the maintenance costs, of course!)

So far, though, I don't quite see the demand for this particular
feature. :shrug:  I'm curious what others think, though!

-bill!

> Thanks for any comments :)
> Pere
> 
> 
> P.S. The small patch, already applied, that allows to compile and run under Linux
> 
> pere@lleopard:~/test/tuxpaint-tuxpaint-Kids-by-Ruben-Barkow-Kuder$ diff /mnt/nvme0n1p1/pere/tuxpaint/test/Tuxpaint-Kids/app/src/main/jni/tuxpaint/src /home/pere/test/tuxpaint-tuxpaint-Kids-by-Ruben-
> Barkow-Kuder/src 
> diff /mnt/nvme0n1p1/pere/tuxpaint/test/Tuxpaint-Kids/app/src/main/jni/tuxpaint/src/i18n.c /home/pere/test/tuxpaint-tuxpaint-Kids-by-Ruben-Barkow-Kuder/src/i18n.c
> 1329,1332d1328
> <     locale = android_locale();
> < #endif
> < 
> <   if (locale == NULL)
> 1334c1330,1331
> < 
> ---
> > #endif
> >   
> diff /mnt/nvme0n1p1/pere/tuxpaint/test/Tuxpaint-Kids/app/src/main/jni/tuxpaint/src/tuxpaint.c /home/pere/test/tuxpaint-tuxpaint-Kids-by-Ruben-Barkow-Kuder/src/tuxpaint.c
> 4298a4299
> > #ifdef __ANDROID__
> 4305a4307
> > #endif /* #ifndef NOSOUND */
> 4719a4722
> > #ifdef __ANDROID__
> 4721a4725
> > #endif
> 10064c10068,10069
> <         
> ---
> >         if (strcasestr(fname, "handle_icons") && strcasestr(fname, ".png"))
> > 	  {
> 10066c10071
> <         SDL_Surface *handle_icon = loadimage(handle_fname);
> ---
> >         SDL_Surface *handle_icon = loadimage(fname);
> 10090c10095
> <         }
> ---
> >         }}
> 
> 
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
> 

Hi all,

In the Tux Paint Android Github we have a pull request that implements an oversimplified interface for Tux Paint addressed to young children.
It also implements an increasing of the canvas via hide/show the color row and Tux row.

If you want to test it, there is an apk provided, and I've just made a small patch to allow compile it under Linux, so we can see it without having to compile it for Android.

The pull request by Ruben Barkow-Kuder, BTW, Ruben, Welcome if you come here :)
https://github.com/tux4kids/Tuxpaint-Android/pull/48

The Tux Paint's source code with that implementation copied back from the P.R.at 347c58a6a03f7cb46ea92c6173e9e210ad089b19 commit and with my patch:
https://provant.freeddns.org/pere/public_html/Tux%20Paint/devel/20251017/tuxpaint-Kids-by-Ruben-Barkow-Kuder.tar.gz


Note that it differs somehow in Linux vs Android as in the original implementation there seems to be some behaviour exclusively implemented in Android, for example the 3 seconds lock for changing the
interface, the expert/kids button at the top left of the screen.

Are we interested in anything of this?
Personally I don't like the interface changing on the fly, but I would like the simplified interface as result of a expertise setting in the config.
As for the increase of canvas I guess the same, let the users choose if they want it.

Thanks for any comments :)
Pere


P.S. The small patch, already applied, that allows to compile and run under Linux

pere@lleopard:~/test/tuxpaint-tuxpaint-Kids-by-Ruben-Barkow-Kuder$ diff /mnt/nvme0n1p1/pere/tuxpaint/test/Tuxpaint-Kids/app/src/main/jni/tuxpaint/src /home/pere/test/tuxpaint-tuxpaint-Kids-by-Ruben-
Barkow-Kuder/src 
diff /mnt/nvme0n1p1/pere/tuxpaint/test/Tuxpaint-Kids/app/src/main/jni/tuxpaint/src/i18n.c /home/pere/test/tuxpaint-tuxpaint-Kids-by-Ruben-Barkow-Kuder/src/i18n.c
1329,1332d1328
<     locale = android_locale();
< #endif
< 
<   if (locale == NULL)
1334c1330,1331
< 
---
> #endif
>   
diff /mnt/nvme0n1p1/pere/tuxpaint/test/Tuxpaint-Kids/app/src/main/jni/tuxpaint/src/tuxpaint.c /home/pere/test/tuxpaint-tuxpaint-Kids-by-Ruben-Barkow-Kuder/src/tuxpaint.c
4298a4299
> #ifdef __ANDROID__
4305a4307
> #endif /* #ifndef NOSOUND */
4719a4722
> #ifdef __ANDROID__
4721a4725
> #endif
10064c10068,10069
<         
---
>         if (strcasestr(fname, "handle_icons") && strcasestr(fname, ".png"))
> 	  {
10066c10071
<         SDL_Surface *handle_icon = loadimage(handle_fname);
---
>         SDL_Surface *handle_icon = loadimage(fname);
10090c10095
<         }
---
>         }}

Hi sir, i am just 13 and i am not a coder. thanks so much for the detailed
reply! I really appreciate your feedback. I'm afraid I don't have any
specific patches or coding experience to help with the solutions I
proposed, but I'm glad to hear you agree with the direction of using
multithreading and optimized caching. I'd be happy to share a video of the
behaviors I mentioned, if that would be helpful for your team.



On Wed, 20 Aug 2025 at 06:21, Bill Kendrick <nb...@so...> wrote:

> On Sat, Aug 09, 2025 at 12:21:59PM +0530, sai krushna wrote:
> > *Subject:* Performance Issue: Sub-optimal resource utilization with
> growing
> > graphical asset library
>
> Hi Sai, thanks for the feedback.  Apologies for not responding myself
> until now.
>
>
> > *Hello Tux Paint Development Team,*
> >
> > I am writing to bring to your attention a performance issue I've observed
> > in recent versions of Tux Paint. I believe this is a more advanced,
> > architectural problem rather than a simple bug, and I wanted to explain
> my
> > findings in detail.
> >
> > *Problem Summary:*
> >
> > With each new version of Tux Paint, the collection of graphical assets
> > (stamps, brushes, magic tools) grows significantly. This is fantastic for
> > user creativity, but I've noticed that the software's performance,
> > particularly in terms of loading times and responsiveness when
> interacting
> > with these tools, appears to be capped. My observation is that even on
> > high-end hardware with a fast multi-core processor, a substantial amount
> of
> > RAM, and a fast SSD, Tux Paint does not seem to utilize the full system
> > potential to load these assets quickly. Instead, it seems to be limited
> to
> > a specific, lower amount of resources, which can lead to a
> less-than-ideal
> > user experience.
>
> I'm on a Thinkpad Ultrabook T480s running Ubuntu 24.04.
> I dug up my receipt, and it seems I purchased it new in May 2020,
> so it's just over 5 years old.
>
>  * Processor: 8th Generation Intel® Core™ i5-8250U Processor (1.60 GHz,
>    up to 3.40 GHz with Turbo Boost, 4 Cores, 8 Threads, 6 MB Cache)
>  * Memory: 8 GB DDR4 2400MHz (Soldered)
>  * Hard Drive: 256 GB PCIe SSD
>  * Graphics: Integrated Intel® UHD Graphics 620
>
> Some disk-inspecting tools on Linux shows the SSD drive is a WDC
> "PC SN730" (NVMe).  Basically, the computer & drive are 2018-2019 era,
> and my particular unit was from 2020.
>
> When I launch Tux Paint, it takes about 1-2 seconds (just based on counting
> in my head) before the splash screen indicates that it's done loading and
> ready to use.
>
>
> THAT SAID, I am certain there are more places where we can improve
> performance, which will especially help users running Tux Paint on even
> older hardware than mine!
>
>
> > *Specific Observations & Examples:*
> >
> >    -
> >
> >    *Loading Times:* When launching Tux Paint for the first time after an
> >    update, or when a large number of stamps are added, the initial load
> time
> >    is significant. This seems to be due to how the application handles
> and
> >    caches these files, rather than a limitation of the hardware.
> >    -
> >
> >    *Asset-Heavy Tools:* The "Stamps" and "Magic Tools" with extensive
> >    libraries can feel sluggish or have a noticeable delay when switching
> >    between different categories or applying them to the canvas.
> >    -
>
> I would love to see a video showing the behaviors mentioned above.
>
>
> >    *Hardware Underutilization:* Using system monitoring tools, I've
> >    observed that during these performance-intensive moments (like initial
> >    loading), CPU usage often remains low on a powerful multi-core
> machine, and
> >    disk I/O is not saturated. This suggests the bottleneck isn't the
> hardware
> >    itself, but a limitation in how the software is written to manage and
> >    process these assets. It's not taking advantage of parallel
> processing or
> >    other modern optimizations.
>
> Any parallelism would be handled under-the-hood (by libraries, e.g. libSDL,
> sound and graphics file format libraries, etc.)
>
> The closest we have to this is a separate thread that fires up when Tux
> Paint
> is launched, to allow FontConfig to do its necessary work (e.g., building
> a TrueType Font cache).  This allows everything else in Tux Paint, besides
> the Text and Label tools, to be available in the meantime.
>
>
> > *Proposed Solution:*
> >
> > I am not asking for changes to the user interface. My request is focused
> on
> > the core codebase. I would like to suggest that the development team
> > consider a refactoring of the code that handles the loading, caching, and
> > management of graphical assets. The goal would be to allow the software
> to
> > make better use of modern system resources, such as:
> >
> >    -
> >
> >    *Multithreading:* Using multiple CPU cores to load assets in parallel,
> >    dramatically reducing startup and tool-switching times.
> >    -
>
> When available and possible, yes I think this would be useful.
>
>
> >    *Optimized Caching:* Implementing a more efficient caching system that
> >    can handle a large volume of files and quickly retrieve them without
> >    hitting performance roadblocks.
> >    -
>
> Agreed.
>
>
> >    *Hardware Acceleration:* Exploring the use of hardware acceleration
> >    (GPU) for rendering and processing graphical tools, where
> appropriate, to
> >    offload work from the main CPU.
>
> I would want to be careful here, so that we don't end up making specific
> GPU specs a _requirement_ to using Tux Paint.
>
>
> > I understand that this is a significant and complex request, as it
> involves
> > fundamental changes to the software's architecture. However, as Tux Paint
> > continues to grow and add more wonderful content, these optimizations
> will
> > become increasingly important for maintaining a smooth and responsive
> > experience for all users, particularly those with powerful modern
> computers
> > who expect the software to run at its full potential.
>
> I admittedly don't have any particular experience in these topics,
> which is why Tux Paint has "Kept It Simple", code-wise, for the most part.
>
> Do you have any specific ideas or patches that you'd like to share, to help
> get the ball rolling? ;-)
>
>
> > Thank you for your time and for all the amazing work you do on Tux Paint.
>
> I'm curious whether or not you've had the time to try out Shin-ichi's
> test build (see
> https://sourceforge.net/p/tuxpaint/mailman/message/59218667/)
> and have any feedback.
>
> Thanks again,
>
> -bill!
>
>
>
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>

On Sat, Aug 09, 2025 at 12:21:59PM +0530, sai krushna wrote:
> *Subject:* Performance Issue: Sub-optimal resource utilization with growing
> graphical asset library

Hi Sai, thanks for the feedback.  Apologies for not responding myself
until now.


> *Hello Tux Paint Development Team,*
> 
> I am writing to bring to your attention a performance issue I've observed
> in recent versions of Tux Paint. I believe this is a more advanced,
> architectural problem rather than a simple bug, and I wanted to explain my
> findings in detail.
> 
> *Problem Summary:*
> 
> With each new version of Tux Paint, the collection of graphical assets
> (stamps, brushes, magic tools) grows significantly. This is fantastic for
> user creativity, but I've noticed that the software's performance,
> particularly in terms of loading times and responsiveness when interacting
> with these tools, appears to be capped. My observation is that even on
> high-end hardware with a fast multi-core processor, a substantial amount of
> RAM, and a fast SSD, Tux Paint does not seem to utilize the full system
> potential to load these assets quickly. Instead, it seems to be limited to
> a specific, lower amount of resources, which can lead to a less-than-ideal
> user experience.

I'm on a Thinkpad Ultrabook T480s running Ubuntu 24.04.
I dug up my receipt, and it seems I purchased it new in May 2020,
so it's just over 5 years old.

 * Processor: 8th Generation Intel® Core™ i5-8250U Processor (1.60 GHz,
   up to 3.40 GHz with Turbo Boost, 4 Cores, 8 Threads, 6 MB Cache)
 * Memory: 8 GB DDR4 2400MHz (Soldered)
 * Hard Drive: 256 GB PCIe SSD
 * Graphics: Integrated Intel® UHD Graphics 620

Some disk-inspecting tools on Linux shows the SSD drive is a WDC
"PC SN730" (NVMe).  Basically, the computer & drive are 2018-2019 era,
and my particular unit was from 2020.

When I launch Tux Paint, it takes about 1-2 seconds (just based on counting
in my head) before the splash screen indicates that it's done loading and
ready to use.


THAT SAID, I am certain there are more places where we can improve
performance, which will especially help users running Tux Paint on even
older hardware than mine!


> *Specific Observations & Examples:*
> 
>    -
> 
>    *Loading Times:* When launching Tux Paint for the first time after an
>    update, or when a large number of stamps are added, the initial load time
>    is significant. This seems to be due to how the application handles and
>    caches these files, rather than a limitation of the hardware.
>    -
> 
>    *Asset-Heavy Tools:* The "Stamps" and "Magic Tools" with extensive
>    libraries can feel sluggish or have a noticeable delay when switching
>    between different categories or applying them to the canvas.
>    -

I would love to see a video showing the behaviors mentioned above.


>    *Hardware Underutilization:* Using system monitoring tools, I've
>    observed that during these performance-intensive moments (like initial
>    loading), CPU usage often remains low on a powerful multi-core machine, and
>    disk I/O is not saturated. This suggests the bottleneck isn't the hardware
>    itself, but a limitation in how the software is written to manage and
>    process these assets. It's not taking advantage of parallel processing or
>    other modern optimizations.

Any parallelism would be handled under-the-hood (by libraries, e.g. libSDL,
sound and graphics file format libraries, etc.)

The closest we have to this is a separate thread that fires up when Tux Paint
is launched, to allow FontConfig to do its necessary work (e.g., building
a TrueType Font cache).  This allows everything else in Tux Paint, besides
the Text and Label tools, to be available in the meantime.


> *Proposed Solution:*
> 
> I am not asking for changes to the user interface. My request is focused on
> the core codebase. I would like to suggest that the development team
> consider a refactoring of the code that handles the loading, caching, and
> management of graphical assets. The goal would be to allow the software to
> make better use of modern system resources, such as:
> 
>    -
> 
>    *Multithreading:* Using multiple CPU cores to load assets in parallel,
>    dramatically reducing startup and tool-switching times.
>    -

When available and possible, yes I think this would be useful.

 
>    *Optimized Caching:* Implementing a more efficient caching system that
>    can handle a large volume of files and quickly retrieve them without
>    hitting performance roadblocks.
>    -

Agreed.

 
>    *Hardware Acceleration:* Exploring the use of hardware acceleration
>    (GPU) for rendering and processing graphical tools, where appropriate, to
>    offload work from the main CPU.

I would want to be careful here, so that we don't end up making specific
GPU specs a _requirement_ to using Tux Paint.

 
> I understand that this is a significant and complex request, as it involves
> fundamental changes to the software's architecture. However, as Tux Paint
> continues to grow and add more wonderful content, these optimizations will
> become increasingly important for maintaining a smooth and responsive
> experience for all users, particularly those with powerful modern computers
> who expect the software to run at its full potential.

I admittedly don't have any particular experience in these topics,
which is why Tux Paint has "Kept It Simple", code-wise, for the most part.

Do you have any specific ideas or patches that you'd like to share, to help
get the ball rolling? ;-)


> Thank you for your time and for all the amazing work you do on Tux Paint.

I'm curious whether or not you've had the time to try out Shin-ichi's
test build (see https://sourceforge.net/p/tuxpaint/mailman/message/59218667/)
and have any feedback.

Thanks again,

-bill!

El dg. 27 de 07 de 2025 a les 08:17 -0400, en/na Mark Kim va escriure:
> 
> The SDL3 branch of Tux Paint started crashing on macOS, too.  
> The cause appears to be commit 499630757dca284de759b86650879763784a94b8 of magic/src/emitter.c.  
> Reverting this one file to the prior commit allows Tux Paint to run on macOS without crashing once again.

I've just commited a small patch to cleanup emitters at exit, don't think it will solve the crash thouth.
In Linux, I can't see errors in valgrind about emitters, so I am lost here :(

Pere

Thank you for your detailed report.

I haven't experienced any notable delays on my laptop, which is a 
relatively new model, but it would be possible that older models may 
experience higher loads. 

By the way, did you conduct your investigation for the Windows version?

Assuming so...

Do you think that before making major architectural changes, would 
optimization using the gcc compiler be an effective temporary 
improvement measure?  

Currently, the optimization option -O2 is specified for the release
package, and no CPU optimization is applied.

As an experiment, I created a package with the optimization option set 
to -O3 and the CPU optimization option set to -march=x86-64-v4.

  https://z1.plala.jp/tuxpaint/testing/o3v4/

I would appreciate it if you could check whether any improvements are 
observed with it.

Thanks.


On Sat, 9 Aug 2025 12:21:59 +0530, sai krushna wrote:
>*Subject:* Performance Issue: Sub-optimal resource utilization with growing
>graphical asset library
>
>*Hello Tux Paint Development Team,*
>
>I am writing to bring to your attention a performance issue I've observed
>in recent versions of Tux Paint. I believe this is a more advanced,
>architectural problem rather than a simple bug, and I wanted to explain my
>findings in detail.
>
>*Problem Summary:*
>
>With each new version of Tux Paint, the collection of graphical assets
>(stamps, brushes, magic tools) grows significantly. This is fantastic for
>user creativity, but I've noticed that the software's performance,
>particularly in terms of loading times and responsiveness when interacting
>with these tools, appears to be capped. My observation is that even on
>high-end hardware with a fast multi-core processor, a substantial amount of
>RAM, and a fast SSD, Tux Paint does not seem to utilize the full system
>potential to load these assets quickly. Instead, it seems to be limited to
>a specific, lower amount of resources, which can lead to a less-than-ideal
>user experience.
>
>*Specific Observations & Examples:*
>
>   -
>
>   *Loading Times:* When launching Tux Paint for the first time after an
>   update, or when a large number of stamps are added, the initial load time
>   is significant. This seems to be due to how the application handles and
>   caches these files, rather than a limitation of the hardware.
>   -
>
>   *Asset-Heavy Tools:* The "Stamps" and "Magic Tools" with extensive
>   libraries can feel sluggish or have a noticeable delay when switching
>   between different categories or applying them to the canvas.
>   -
>
>   *Hardware Underutilization:* Using system monitoring tools, I've
>   observed that during these performance-intensive moments (like initial
>   loading), CPU usage often remains low on a powerful multi-core machine, and
>   disk I/O is not saturated. This suggests the bottleneck isn't the hardware
>   itself, but a limitation in how the software is written to manage and
>   process these assets. It's not taking advantage of parallel processing or
>   other modern optimizations.
>
>*Proposed Solution:*
>
>I am not asking for changes to the user interface. My request is focused on
>the core codebase. I would like to suggest that the development team
>consider a refactoring of the code that handles the loading, caching, and
>management of graphical assets. The goal would be to allow the software to
>make better use of modern system resources, such as:
>
>   -
>
>   *Multithreading:* Using multiple CPU cores to load assets in parallel,
>   dramatically reducing startup and tool-switching times.
>   -
>
>   *Optimized Caching:* Implementing a more efficient caching system that
>   can handle a large volume of files and quickly retrieve them without
>   hitting performance roadblocks.
>   -
>
>   *Hardware Acceleration:* Exploring the use of hardware acceleration
>   (GPU) for rendering and processing graphical tools, where appropriate, to
>   offload work from the main CPU.
>
>I understand that this is a significant and complex request, as it involves
>fundamental changes to the software's architecture. However, as Tux Paint
>continues to grow and add more wonderful content, these optimizations will
>become increasingly important for maintaining a smooth and responsive
>experience for all users, particularly those with powerful modern computers
>who expect the software to run at its full potential.
>
>Thank you for your time and for all the amazing work you do on Tux Paint.
>------------------------------


-- 
Shin-ichi TOYAMA <dol...@wm...>

*Subject:* Performance Issue: Sub-optimal resource utilization with growing
graphical asset library

*Hello Tux Paint Development Team,*

I am writing to bring to your attention a performance issue I've observed
in recent versions of Tux Paint. I believe this is a more advanced,
architectural problem rather than a simple bug, and I wanted to explain my
findings in detail.

*Problem Summary:*

With each new version of Tux Paint, the collection of graphical assets
(stamps, brushes, magic tools) grows significantly. This is fantastic for
user creativity, but I've noticed that the software's performance,
particularly in terms of loading times and responsiveness when interacting
with these tools, appears to be capped. My observation is that even on
high-end hardware with a fast multi-core processor, a substantial amount of
RAM, and a fast SSD, Tux Paint does not seem to utilize the full system
potential to load these assets quickly. Instead, it seems to be limited to
a specific, lower amount of resources, which can lead to a less-than-ideal
user experience.

*Specific Observations & Examples:*

   -

   *Loading Times:* When launching Tux Paint for the first time after an
   update, or when a large number of stamps are added, the initial load time
   is significant. This seems to be due to how the application handles and
   caches these files, rather than a limitation of the hardware.
   -

   *Asset-Heavy Tools:* The "Stamps" and "Magic Tools" with extensive
   libraries can feel sluggish or have a noticeable delay when switching
   between different categories or applying them to the canvas.
   -

   *Hardware Underutilization:* Using system monitoring tools, I've
   observed that during these performance-intensive moments (like initial
   loading), CPU usage often remains low on a powerful multi-core machine, and
   disk I/O is not saturated. This suggests the bottleneck isn't the hardware
   itself, but a limitation in how the software is written to manage and
   process these assets. It's not taking advantage of parallel processing or
   other modern optimizations.

*Proposed Solution:*

I am not asking for changes to the user interface. My request is focused on
the core codebase. I would like to suggest that the development team
consider a refactoring of the code that handles the loading, caching, and
management of graphical assets. The goal would be to allow the software to
make better use of modern system resources, such as:

   -

   *Multithreading:* Using multiple CPU cores to load assets in parallel,
   dramatically reducing startup and tool-switching times.
   -

   *Optimized Caching:* Implementing a more efficient caching system that
   can handle a large volume of files and quickly retrieve them without
   hitting performance roadblocks.
   -

   *Hardware Acceleration:* Exploring the use of hardware acceleration
   (GPU) for rendering and processing graphical tools, where appropriate, to
   offload work from the main CPU.

I understand that this is a significant and complex request, as it involves
fundamental changes to the software's architecture. However, as Tux Paint
continues to grow and add more wonderful content, these optimizations will
become increasingly important for maintaining a smooth and responsive
experience for all users, particularly those with powerful modern computers
who expect the software to run at its full potential.

Thank you for your time and for all the amazing work you do on Tux Paint.
------------------------------

El dg. 27 de 07 de 2025 a les 11:08 +0100, en/na Bill Kendrick va escriure:
> On Sun, Jul 27, 2025 at 11:46:04AM +0200, Pere Pujal i Carabantes wrote:
> > El dg. 27 de 07 de 2025 a les 08:23 +0900, en/na Shin-ichi TOYAMA va escriure:
> > > Hi!
> > > 
> <snip>
> > > > >   In file included from /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer.c:24:
> > > > >   /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer_internal.h:139:23: error: expected declaration specifiers or ‘...’ before numeric constant
> > > > >     139 |     float SDL_ALIGNED(16) position3d[4];   // we only need the X, Y, and Z coords, but the 4th element makes this SIMD-friendly.
> > > 
> > > SDL3_mixer seems to be under a very active work in progress.
> > > 
> > > I also once succeeded to build it but currently it fails with the same error bill mentioned.
> > > Then, confirmed that it could build until the commit "4e9a308a0daa63b6bd492b0ec616f86337500898".
> 
> That commit has a lot fewer source files.  MIX_Track doesn't yet
> exist; there's no "SDL_mixer_internal.h".  That said, it DID build. :-D
> 
> And Tux Paint builds (in its entirety) for me, with only this change
> to Makefile
> 
>   -SDL_LIBS+=$(shell $(PKG_CONFIG) sdl3-gfx --libs)
>   +SDL_LIBS+=-lSDL3_gfx
> 
> It knows it's built with SDL3:
> 
>   kendrick@bill-t480s:~/tuxpaint/perepujal-tuxpaint$ tuxpaint --verbose-version 
>   
>   Tux Paint
>     Version 0.9.36 (2025-07-27)
>   
>   Built with these options:
>     SDL version 3.2.18
> 
> However, it segfaults after the splash screen appears.
> (It was built WITH all magic tools, this time around.)
> 
> I'll keep investigating when I can :)
> 
> 
> > > I will wait for a while until it would be more stable.
> 
> We might need to, hehe.

I agree too.


> > 
> > Actually, with commit 59a2f77645404aee3ab541c6c860970da7572bed from July 26
> > builds fine for me.

The SDL3_mixer library builds fine, but after installed it,   
breaks the Tux Paint build, so Tux Paint would need to be adapted   
to the changes in the mixer lib.

For now, I am going to downgrade the mixer in my box to the  
4e9a308a0daa63b6bd492b0ec616f86337500898 commit until more people   
is able to compile the main branch of SDL3_Mixer.


> > 
> > Starting at the root of the source, rm the "build" directory if it has been created before, then:
> > mkdir build && cd build && cmake -S .. -B . && make
> 
> That commit continued to not build, due to `position3d` and `position`
> differences in the struct described in "SDL_mixer_internal.h", and how
> it was used elsewhere in the SDL_mixer sources.  (Even after a `git pull`
> on "master" branch.)


Strange, could be that a different compiler/make/whatever would not throw errors?  
It builds here with no complaints.  
In case of that helps:

gcc --version  
gcc (Debian 14.2.0-19) 14.2.0

make --version  
GNU Make 4.4.1

ldd --version  
ldd (Debian GLIBC 2.41-6) 2.41

cmake --version  
cmake version 3.18.4


HTH  
Pere

On Sun, Jul 27, 2025 at 6:08 AM Bill Kendrick <nb...@so...> wrote:
[snip]

> However, it segfaults after the splash screen appears.
> (It was built WITH all magic tools, this time around.)
>

The SDL3 branch of Tux Paint started crashing on macOS, too.  The cause
appears to be commit 499630757dca284de759b86650879763784a94b8 of
magic/src/emitter.c.  Reverting this one file to the prior commit allows
Tux Paint to run on macOS without crashing once again.  Deleting the
emitter.dylib shared library also allows Tux Paint to run on macOS again.

Can you see if the above workarounds for the macOS build also works for the
Linux build?


> I'll keep investigating when I can :)
>
>
> > > I will wait for a while until it would be more stable.
>
> We might need to, hehe.
>
>
> > > Just FYI.
> >
> > Actually, with commit 59a2f77645404aee3ab541c6c860970da7572bed from July
> 26
> > builds fine for me.
> >
> > Starting at the root of the source, rm the "build" directory if it has
> been created before, then:
> > mkdir build && cd build && cmake -S .. -B . && make
>
> That commit continued to not build, due to `position3d` and `position`
> differences in the struct described in "SDL_mixer_internal.h", and how
> it was used elsewhere in the SDL_mixer sources.  (Even after a `git pull`
> on "master" branch.)
>
> Strange!
>
> -bill!
>
>
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>

On Sun, Jul 27, 2025 at 11:46:04AM +0200, Pere Pujal i Carabantes wrote:
> El dg. 27 de 07 de 2025 a les 08:23 +0900, en/na Shin-ichi TOYAMA va escriure:
> > Hi!
> > 
<snip>
> > > >   In file included from /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer.c:24:
> > > >   /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer_internal.h:139:23: error: expected declaration specifiers or ‘...’ before numeric constant
> > > >     139 |     float SDL_ALIGNED(16) position3d[4];   // we only need the X, Y, and Z coords, but the 4th element makes this SIMD-friendly.
> > 
> > SDL3_mixer seems to be under a very active work in progress.
> > 
> > I also once succeeded to build it but currently it fails with the same error bill mentioned.
> > Then, confirmed that it could build until the commit "4e9a308a0daa63b6bd492b0ec616f86337500898".

That commit has a lot fewer source files.  MIX_Track doesn't yet
exist; there's no "SDL_mixer_internal.h".  That said, it DID build. :-D

And Tux Paint builds (in its entirety) for me, with only this change
to Makefile

  -SDL_LIBS+=$(shell $(PKG_CONFIG) sdl3-gfx --libs)
  +SDL_LIBS+=-lSDL3_gfx

It knows it's built with SDL3:

  kendrick@bill-t480s:~/tuxpaint/perepujal-tuxpaint$ tuxpaint --verbose-version 
  
  Tux Paint
    Version 0.9.36 (2025-07-27)
  
  Built with these options:
    SDL version 3.2.18

However, it segfaults after the splash screen appears.
(It was built WITH all magic tools, this time around.)

I'll keep investigating when I can :)


> > I will wait for a while until it would be more stable.

We might need to, hehe.


> > Just FYI.
> 
> Actually, with commit 59a2f77645404aee3ab541c6c860970da7572bed from July 26
> builds fine for me.
> 
> Starting at the root of the source, rm the "build" directory if it has been created before, then:
> mkdir build && cd build && cmake -S .. -B . && make

That commit continued to not build, due to `position3d` and `position`
differences in the struct described in "SDL_mixer_internal.h", and how
it was used elsewhere in the SDL_mixer sources.  (Even after a `git pull`
on "master" branch.)

Strange!

-bill!

El dg. 27 de 07 de 2025 a les 08:23 +0900, en/na Shin-ichi TOYAMA va escriure:
> Hi!
> 
> On Fri, 25 Jul 2025 09:47:22 +0200, Pere Pujal i Carabantes wrote:
> > El dv. 25 de 07 de 2025 a les 01:42 +0100, en/na Bill Kendrick va escriure:
> > > On Sun, Jun 29, 2025 at 02:03:11PM +0200, Pere Pujal i Carabantes wrote:
> > > There is not yet a release of SDL3_mixer, 
> > 
> > Ouch, yes it was missing too, Looking at my sources, I compiled it in March.
> > I don't  remember having to do anything special to build it.
> > commit 72a73339731a12c1002f9caca64f1ab924938102 if that helps.
> 
> <... snip ...>
> 
> On Fri, 25 Jul 2025 09:47:22 +0200, Pere Pujal i Carabantes wrote:
> > El dv. 25 de 07 de 2025 a les 01:42 +0100, en/na Bill Kendrick va escriure:
> > > so I cloned the repo
> > > (https://github.com/libsdl-org/SDL_mixer) but unfortunately
> > > cannot build it (`cmake --build build`) due to some compiler
> > > errors:
> > > 
> > >   [  3%] Building C object CMakeFiles/SDL3_mixer-shared.dir/src/SDL_mixer.c.o
> > >   In file included from /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer.c:24:
> > >   /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer_internal.h:139:23: error: expected declaration specifiers or ‘...’ before numeric constant
> > >     139 |     float SDL_ALIGNED(16) position3d[4];   // we only need the X, Y, and Z coords, but the 4th element makes this SIMD-friendly.
> 
> SDL3_mixer seems to be under a very active work in progress.
> 
> I also once succeeded to build it but currently it fails with the same error bill mentioned.
> Then, confirmed that it could build until the commit "4e9a308a0daa63b6bd492b0ec616f86337500898".
> 
> I will wait for a while until it would be more stable.
> 
> Just FYI.

Actually, with commit 59a2f77645404aee3ab541c6c860970da7572bed from July 26
builds fine for me.

Starting at the root of the source, rm the "build" directory if it has been created before, then:
mkdir build && cd build && cmake -S .. -B . && make

HTH
Pere

Hi!

On Fri, 25 Jul 2025 09:47:22 +0200, Pere Pujal i Carabantes wrote:
>El dv. 25 de 07 de 2025 a les 01:42 +0100, en/na Bill Kendrick va escriure:
>> On Sun, Jun 29, 2025 at 02:03:11PM +0200, Pere Pujal i Carabantes wrote:
>> There is not yet a release of SDL3_mixer, 
>
>Ouch, yes it was missing too, Looking at my sources, I compiled it in March.
>I don't  remember having to do anything special to build it.
>commit 72a73339731a12c1002f9caca64f1ab924938102 if that helps.

<... snip ...>

On Fri, 25 Jul 2025 09:47:22 +0200, Pere Pujal i Carabantes wrote:
>El dv. 25 de 07 de 2025 a les 01:42 +0100, en/na Bill Kendrick va escriure:
>> so I cloned the repo
>> (https://github.com/libsdl-org/SDL_mixer) but unfortunately
>> cannot build it (`cmake --build build`) due to some compiler
>> errors:
>> 
>>   [  3%] Building C object CMakeFiles/SDL3_mixer-shared.dir/src/SDL_mixer.c.o
>>   In file included from /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer.c:24:
>>   /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer_internal.h:139:23: error: expected declaration specifiers or ‘...’ before numeric constant
>>     139 |     float SDL_ALIGNED(16) position3d[4];   // we only need the X, Y, and Z coords, but the 4th element makes this SIMD-friendly.

SDL3_mixer seems to be under a very active work in progress.

I also once succeeded to build it but currently it fails with the same error bill mentioned.
Then, confirmed that it could build until the commit "4e9a308a0daa63b6bd492b0ec616f86337500898".

I will wait for a while until it would be more stable.

Just FYI.

-- 
Shin-ichi TOYAMA <dol...@wm...>

On Fri, Jul 25, 2025 at 09:47:22AM +0200, Pere Pujal i Carabantes wrote:
> El dv. 25 de 07 de 2025 a les 01:42 +0100, en/na Bill Kendrick va escriure:
<snip>
> > I can launch Tux Paint, and see the splash screen, but
> > then it seems to freeze.
> 
> Dropping all magic plugins resulted in a freeze splash screen.
> Is for that reason I kept at least one magic in commit 3cdeebe7ae5fe1a138772b4973b0f4015c2b14dc
> when I wanted to concentrate in other stuff.

Ah, another 'upstream' bug, I suppose! :-)

-bill!

El dv. 25 de 07 de 2025 a les 01:42 +0100, en/na Bill Kendrick va escriure:
> On Sun, Jun 29, 2025 at 02:03:11PM +0200, Pere Pujal i Carabantes wrote:
> > Hi all,
> > 
> > About three months ago I started that port, now after the release of 0.9.35 I am continuing it :)
> > 
> > The source code is currently inside the sdl3 branch in my personal fork at SourceForge
> > https://sourceforge.net/u/perepujal/tuxpaint/ci/master/tree/
> > 
> > It needs SDL3_gfx which is still not in my distro(Debian Sid), so I've picked this one:
> > https://github.com/sabdul-khabir/SDL3_gfx
> > 
> > And needs also SDL3_Pango wich I have working but needs a lot of cleaning 
> > before it gets ready for a merge request,
> > I blindly ran some sed scripts that affected tons of files. Sorry Mark :)
> > https://provant.freeddns.org/pere/public_html/Tux%20Paint/devel/20250629/
> > 
> > After installing them, and the SDL3* libraries that come in my distribution, 
> > I am able to compile and run Tux Paint in my box :)
> > Painting, lines, shapes, stamps, text, open, save, slideshow, erase and magic alien seems to work fine.
> > im and labels too but they are not tested hard.
> 
> There is not yet a release of SDL3_mixer, 
> 

Ouch, yes it was missing too, Looking at my sources, I compiled it in March.
I don't  remember having to do anything special to build it.
commit 72a73339731a12c1002f9caca64f1ab924938102 if that helps.



> so I cloned the repo
> (https://github.com/libsdl-org/SDL_mixer) but unfortunately
> cannot build it (`cmake --build build`) due to some compiler
> errors:
> 
>   [  3%] Building C object CMakeFiles/SDL3_mixer-shared.dir/src/SDL_mixer.c.o
>   In file included from /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer.c:24:
>   /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer_internal.h:139:23: error: expected declaration specifiers or ‘...’ before numeric constant
>     139 |     float SDL_ALIGNED(16) position3d[4];   // we only need the X, Y, and Z coords, but the 4th element makes this SIMD-friendly.
>         |                       ^~
>   /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer.c: In function ‘AudioDeviceChangeEventWatcher’:
>   /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer.c:218:66: error: ‘MIX_Track’ has no member named ‘position3d’; did you mean ‘position’?
>     218 |                     MIX_Spatialize(&track->mixer->vbap2d, track->position3d, track->spatialization_panning, track->spatialization_speakers);
>         |                                                                  ^~~~~~~~~~
>         |                                                                  position
>   [... plus more places where it complaints about `position3d` vs `position` ...]
> 
> 
> If I try to build Tux Paint without SDL_Mixer support (`make SDL_MIXER_LIB=`),
> I got a number of errors due to parts of the code trying to use the
> mixer library (e.g., #include it, or declare variables of type Mix_Chunk).
> 
> I believe these errors are 'upstream' (i.e., in the main `tuxpaint` project);
> it's just hard for me to notice them because I _have_ SDL_Mixer (version 2)
> installed. :-)  I'll need to sort that out.
> 
> 
> Beyond that, I'm also having trouble with SDL3_gfx.  When I run `make`
> to do _anything_, it seems to always show this:
> 
>   Package sdl3-gfx was not found in the pkg-config search path.
>   Perhaps you should add the directory containing `sdl3-gfx.pc'
>   to the PKG_CONFIG_PATH environment variable
>   Package 'sdl3-gfx', required by 'virtual:world', not found
>   Makefile:340: -lSDL3_Mixer failed, no sound for you!
>   Package sdl3-gfx was not found in the pkg-config search path.
>   Perhaps you should add the directory containing `sdl3-gfx.pc'
>   to the PKG_CONFIG_PATH environment variable
>   Package 'sdl3-gfx', required by 'virtual:world', not found
>   make: *** No rule to make target 'nosound'.  Stop.
> 
> And when I get it to compile, and it goes to link,
> it cannot find `zoomSurface` or `rotozoomSurface`,
> unsurprisingly:
> 
> 
>   ...Linking Tux Paint...
>   cc  -O2 -g -ffast-math -W -Wall -fno-common -ffloat-store -fvisibility=hidden -Wcast-align -Wredundant-decls -Wbad-function-cast -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wstrict-aliasing=2 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/libpng16 -pthread -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi -I/usr/include/cairo -I/usr/include/pixman-1  -I/usr/local/include -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/libpng16 -pthread -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi -I/usr/include/cairo -I/usr/include/pixman-1     -I/usr/local/include  -I/usr/include/fribidi  -I/usr/include/libxml2  -DVER_DATE=\"2025-07-25\" -DVER_VERSION=\"0.9.36\" -DDATA_PREFIX=\"/usr/local/share/tuxpaint/\" -DDOC_PREFIX=\"/usr/local/share/doc/tuxpaint-0.9.36/\" -DLOCALEDIR=\"/usr/local/share/locale/\" -DIMDIR=\"/usr/local/share/tuxpaint/im/\" -DCONFDIR=\"/usr/local/etc/tuxpaint/\" -DMAGIC_PREFIX=\"/usr/local/lib/tuxpaint/plugins/\" -DNOSOUND     \
>           -o tuxpaint obj/tuxpaint.o obj/i18n.o obj/im.o obj/cursor.o obj/pixels.o obj/rgblinear.o obj/playsound.o obj/fonts.o obj/parse.o obj/fill.o obj/progressbar.o obj/dirwalk.o obj/get_fname.o obj/onscreen_keyboard.o obj/gifenc.o obj/sounds.o obj/postscript_print.o \
>           -L/usr/local/lib -Wl,-rpath,/usr/local/lib -Wl,--enable-new-dtags -lSDL3  -lSDL3_image -lSDL3_ttf -lz  -lpng16   -L/usr/local/lib -lSDL3_Pango -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lharfbuzz  -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lharfbuzz  -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lharfbuzz -lfontconfig -lfreetype  -lrsvg-2 -lm -lgio-2.0 -lgdk_pixbuf-2.0 -lgobject-2.0 -lglib-2.0 -lcairo  -lpaper -lfribidi  -lxml2  -limagequant -lm
>   /usr/bin/ld: obj/tuxpaint.o: in function `blit_brush':
>   /home/kendrick/tuxpaint/perepujal-tuxpaint/src/tuxpaint.c:7582:(.text+0x750b): undefined reference to `rotozoomSurface'
>   /usr/bin/ld: /home/kendrick/tuxpaint/perepujal-tuxpaint/src/tuxpaint.c:7588:(.text+0x76c4): undefined reference to `rotozoomSurface'
>   /usr/bin/ld: obj/tuxpaint.o: in function `update_stamp_xor':
>   /home/kendrick/tuxpaint/perepujal-tuxpaint/src/tuxpaint.c:20234:(.text+0xff7f): undefined reference to `rotozoomSurface'
>   /usr/bin/ld: obj/tuxpaint.o: in function `stamp_draw':
>   /home/kendrick/tuxpaint/perepujal-tuxpaint/src/tuxpaint.c:8219:(.text+0x11ce0): undefined reference to `rotozoomSurface'
>   /usr/bin/ld: obj/tuxpaint.o: in function `magic_rotate_scale':
>   /home/kendrick/tuxpaint/perepujal-tuxpaint/src/tuxpaint.c:22747:(.text+0x4833): undefined reference to `rotozoomSurface'
>   /usr/bin/ld: obj/onscreen_keyboard.o: in function `osk_create':
>   /home/kendrick/tuxpaint/perepujal-tuxpaint/src/onscreen_keyboard.c:166:(.text+0x1dfd): undefined reference to `zoomSurface'
>   /usr/bin/ld: /home/kendrick/tuxpaint/perepujal-tuxpaint/src/onscreen_keyboard.c:167:(.text+0x1e21): undefined reference to `zoomSurface'
>   /usr/bin/ld: /home/kendrick/tuxpaint/perepujal-tuxpaint/src/onscreen_keyboard.c:168:(.text+0x1e47): undefined reference to `zoomSurface'
>   /usr/bin/ld: /home/kendrick/tuxpaint/perepujal-tuxpaint/src/onscreen_keyboard.c:169:(.text+0x1e6d): undefined reference to `zoomSurface'
>   /usr/bin/ld: /home/kendrick/tuxpaint/perepujal-tuxpaint/src/onscreen_keyboard.c:170:(.text+0x1e96): undefined reference to `zoomSurface'
>   /usr/bin/ld: obj/onscreen_keyboard.o:/home/kendrick/tuxpaint/perepujal-tuxpaint/src/onscreen_keyboard.c:171: more undefined references to `zoomSurface' follow
>   collect2: error: ld returned 1 exit status
>   make: *** [Makefile:1258: tuxpaint] Error 1
> 
> However, I see a comment in Makefile that you had trouble with SDL3_gfx pkgconfig.
> I just ended up hard-coding it, for now:
> 
> 
>   SDL_LIBS+=-lSDL3_gfx
> 
> Finally, the Magic tools all want SDL_Mixer too,
> so I just dropped "magic-plugins" from Makefile's "all"
> target, and it built!
> 
> I can launch Tux Paint, and see the splash screen, but
> then it seems to freeze.

Dropping all magic plugins resulted in a freeze splash screen.
Is for that reason I kept at least one magic in commit 3cdeebe7ae5fe1a138772b4973b0f4015c2b14dc
when I wanted to concentrate in other stuff.


> 
> Okay, it's very late so I need to stop for now.
> 
> -bill!
> 

On Sun, Jun 29, 2025 at 02:03:11PM +0200, Pere Pujal i Carabantes wrote:
> Hi all,
> 
> About three months ago I started that port, now after the release of 0.9.35 I am continuing it :)
> 
> The source code is currently inside the sdl3 branch in my personal fork at SourceForge
> https://sourceforge.net/u/perepujal/tuxpaint/ci/master/tree/
> 
> It needs SDL3_gfx which is still not in my distro(Debian Sid), so I've picked this one:
> https://github.com/sabdul-khabir/SDL3_gfx
> 
> And needs also SDL3_Pango wich I have working but needs a lot of cleaning 
> before it gets ready for a merge request,
> I blindly ran some sed scripts that affected tons of files. Sorry Mark :)
> https://provant.freeddns.org/pere/public_html/Tux%20Paint/devel/20250629/
> 
> After installing them, and the SDL3* libraries that come in my distribution, 
> I am able to compile and run Tux Paint in my box :)
> Painting, lines, shapes, stamps, text, open, save, slideshow, erase and magic alien seems to work fine.
> im and labels too but they are not tested hard.

There is not yet a release of SDL3_mixer, so I cloned the repo
(https://github.com/libsdl-org/SDL_mixer) but unfortunately
cannot build it (`cmake --build build`) due to some compiler
errors:

  [  3%] Building C object CMakeFiles/SDL3_mixer-shared.dir/src/SDL_mixer.c.o
  In file included from /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer.c:24:
  /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer_internal.h:139:23: error: expected declaration specifiers or ‘...’ before numeric constant
    139 |     float SDL_ALIGNED(16) position3d[4];   // we only need the X, Y, and Z coords, but the 4th element makes this SIMD-friendly.
        |                       ^~
  /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer.c: In function ‘AudioDeviceChangeEventWatcher’:
  /home/kendrick/tuxpaint/sdl3-libs/SDL_mixer/src/SDL_mixer.c:218:66: error: ‘MIX_Track’ has no member named ‘position3d’; did you mean ‘position’?
    218 |                     MIX_Spatialize(&track->mixer->vbap2d, track->position3d, track->spatialization_panning, track->spatialization_speakers);
        |                                                                  ^~~~~~~~~~
        |                                                                  position
  [... plus more places where it complaints about `position3d` vs `position` ...]


If I try to build Tux Paint without SDL_Mixer support (`make SDL_MIXER_LIB=`),
I got a number of errors due to parts of the code trying to use the
mixer library (e.g., #include it, or declare variables of type Mix_Chunk).

I believe these errors are 'upstream' (i.e., in the main `tuxpaint` project);
it's just hard for me to notice them because I _have_ SDL_Mixer (version 2)
installed. :-)  I'll need to sort that out.


Beyond that, I'm also having trouble with SDL3_gfx.  When I run `make`
to do _anything_, it seems to always show this:

  Package sdl3-gfx was not found in the pkg-config search path.
  Perhaps you should add the directory containing `sdl3-gfx.pc'
  to the PKG_CONFIG_PATH environment variable
  Package 'sdl3-gfx', required by 'virtual:world', not found
  Makefile:340: -lSDL3_Mixer failed, no sound for you!
  Package sdl3-gfx was not found in the pkg-config search path.
  Perhaps you should add the directory containing `sdl3-gfx.pc'
  to the PKG_CONFIG_PATH environment variable
  Package 'sdl3-gfx', required by 'virtual:world', not found
  make: *** No rule to make target 'nosound'.  Stop.

And when I get it to compile, and it goes to link,
it cannot find `zoomSurface` or `rotozoomSurface`,
unsurprisingly:


  ...Linking Tux Paint...
  cc  -O2 -g -ffast-math -W -Wall -fno-common -ffloat-store -fvisibility=hidden -Wcast-align -Wredundant-decls -Wbad-function-cast -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wstrict-aliasing=2 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/libpng16 -pthread -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi -I/usr/include/cairo -I/usr/include/pixman-1  -I/usr/local/include -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/libpng16 -pthread -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi -I/usr/include/cairo -I/usr/include/pixman-1     -I/usr/local/include  -I/usr/include/fribidi  -I/usr/include/libxml2  -DVER_DATE=\"2025-07-25\" -DVER_VERSION=\"0.9.36\" -DDATA_PREFIX=\"/usr/local/share/tuxpaint/\" -DDOC_PREFIX=\"/usr/local/share/doc/tuxpaint-0.9.36/\" -DLOCALEDIR=\"/usr/local/share/locale/\" -DIMDIR=\"/usr/local/share/tuxpaint/im/\" -DCONFDIR=\"/usr/local/etc/tuxpaint/\" -DMAGIC_PREFIX=\"/usr/local/lib/tuxpaint/plugins/\" -DNOSOUND     \
          -o tuxpaint obj/tuxpaint.o obj/i18n.o obj/im.o obj/cursor.o obj/pixels.o obj/rgblinear.o obj/playsound.o obj/fonts.o obj/parse.o obj/fill.o obj/progressbar.o obj/dirwalk.o obj/get_fname.o obj/onscreen_keyboard.o obj/gifenc.o obj/sounds.o obj/postscript_print.o \
          -L/usr/local/lib -Wl,-rpath,/usr/local/lib -Wl,--enable-new-dtags -lSDL3  -lSDL3_image -lSDL3_ttf -lz  -lpng16   -L/usr/local/lib -lSDL3_Pango -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lharfbuzz  -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lharfbuzz  -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lharfbuzz -lfontconfig -lfreetype  -lrsvg-2 -lm -lgio-2.0 -lgdk_pixbuf-2.0 -lgobject-2.0 -lglib-2.0 -lcairo  -lpaper -lfribidi  -lxml2  -limagequant -lm
  /usr/bin/ld: obj/tuxpaint.o: in function `blit_brush':
  /home/kendrick/tuxpaint/perepujal-tuxpaint/src/tuxpaint.c:7582:(.text+0x750b): undefined reference to `rotozoomSurface'
  /usr/bin/ld: /home/kendrick/tuxpaint/perepujal-tuxpaint/src/tuxpaint.c:7588:(.text+0x76c4): undefined reference to `rotozoomSurface'
  /usr/bin/ld: obj/tuxpaint.o: in function `update_stamp_xor':
  /home/kendrick/tuxpaint/perepujal-tuxpaint/src/tuxpaint.c:20234:(.text+0xff7f): undefined reference to `rotozoomSurface'
  /usr/bin/ld: obj/tuxpaint.o: in function `stamp_draw':
  /home/kendrick/tuxpaint/perepujal-tuxpaint/src/tuxpaint.c:8219:(.text+0x11ce0): undefined reference to `rotozoomSurface'
  /usr/bin/ld: obj/tuxpaint.o: in function `magic_rotate_scale':
  /home/kendrick/tuxpaint/perepujal-tuxpaint/src/tuxpaint.c:22747:(.text+0x4833): undefined reference to `rotozoomSurface'
  /usr/bin/ld: obj/onscreen_keyboard.o: in function `osk_create':
  /home/kendrick/tuxpaint/perepujal-tuxpaint/src/onscreen_keyboard.c:166:(.text+0x1dfd): undefined reference to `zoomSurface'
  /usr/bin/ld: /home/kendrick/tuxpaint/perepujal-tuxpaint/src/onscreen_keyboard.c:167:(.text+0x1e21): undefined reference to `zoomSurface'
  /usr/bin/ld: /home/kendrick/tuxpaint/perepujal-tuxpaint/src/onscreen_keyboard.c:168:(.text+0x1e47): undefined reference to `zoomSurface'
  /usr/bin/ld: /home/kendrick/tuxpaint/perepujal-tuxpaint/src/onscreen_keyboard.c:169:(.text+0x1e6d): undefined reference to `zoomSurface'
  /usr/bin/ld: /home/kendrick/tuxpaint/perepujal-tuxpaint/src/onscreen_keyboard.c:170:(.text+0x1e96): undefined reference to `zoomSurface'
  /usr/bin/ld: obj/onscreen_keyboard.o:/home/kendrick/tuxpaint/perepujal-tuxpaint/src/onscreen_keyboard.c:171: more undefined references to `zoomSurface' follow
  collect2: error: ld returned 1 exit status
  make: *** [Makefile:1258: tuxpaint] Error 1

However, I see a comment in Makefile that you had trouble with SDL3_gfx pkgconfig.
I just ended up hard-coding it, for now:


  SDL_LIBS+=-lSDL3_gfx

Finally, the Magic tools all want SDL_Mixer too,
so I just dropped "magic-plugins" from Makefile's "all"
target, and it built!

I can launch Tux Paint, and see the splash screen, but
then it seems to freeze.

Okay, it's very late so I need to stop for now.

-bill!

> 
> I'd really like reviews  and tests, below some things that would need help:
> 
> im subsystem:
> I don't know the languages we provide im for, so a test about correctness would be welcome.
> Right Alt do not work in the SDL3 version I have installed, so I've added Left Alt to Thai, even if it was explicitly disabled.
> Oher languages made use of both, left and right alt, now in my box, only left works.
> 
> 
> Fill Lineal doesn't work properly on single click inside small circles, without drag, I am currently investigating this...
> 
> 
> Magic tools:
> there are plenty of magic tools in the magic/src/WIP_SDL3 directory that are waiting to be ported.
> 
> 
> Wew, too long message, thanks for reading, and thaks for any help :)
> Pere
> 
> 
> 
> 
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>