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

[Shin-ichi T. <dol...@wm...>]

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...>