I am not convinced, the problem is that 80% of my slow down is on the pharo side , the primitive takes 200ms to read the file, 900-1000 ms are taken to convert to Form�� so I dont see how making sprites will help me much. I know you want to blame the hardware , but this is clearly a pharo issue.�� I have already posted the my profiling results.

Since half of form creation is the seconds indicator I can stream it so it loads one png per second which should make the opening of gui much faster. I will find a way , its not a big deal.

This thread was never about a problem I cant solve , but rather a notice that there is a part of pharo that is highly inefficient.

On Mon, Jan 18, 2016 at 12:12 PM Stephan Eggermont <stephan@stack.nl> wrote:
On 18-01-16 10:27, Thierry Goubier wrote:
> Hi Kilon,
>
> Le 17/01/2016 22:25, Dimitris Chloupis a ��crit :
>> Fuel is great indeed and very convenient ,will definetly use this
>> approach if I end up dealing with a lot of PNGs and experience some
>> serious delays, but for now, lazy loading with some forking should be
>> enough to make this instantaneous .�� I prefer to stick with pngs because
>> it easy to update them and version control them via git and github
>
> I think there is a way to cache your pngs, their creation time, and load
> them only once upon installation of your tool, and update them in memory
> only if they have been changed on disk.
>
> I suspect all media heavy software have tactics to work around the same
> performance issues: multi-resource formats (zip or fuel) and the same
> kind of caching (load only once when installing the software).

Yes, and combining multiple resources in one file to increase the
likelihood that they will be on the same track of a disk instead of on
60 different ones. In web software there is the same problem with
multiple images. The browser doesn't give you many threads to download
them in parallel. If you only get two and have to download 60 images
from the other side of the ocean...
https://css-tricks.com/css-sprites/

Stephan