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

[sai k. <sai...@gm...>]

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
>