Re: [Tuxpaint-devel] Problem regaurding tux paint.

[Bill K. <nb...@so...>]

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!