Problème de lenteur avec le composant TImage

Bonjour,

J'utilise depuis au moins 10 ans le composant TImage de Lazarus sur Linux (Ubuntu) ( actuellement sur un portable Acer ) sans problème particulier.

Tout à coup, j'ai souhaité entrer une image (.png) en utilisant la fonction stretch pour formater mon image. Alors, j'ai constaté que ce formatage demandait plus d'une minute, alors qu'auparavant c'était quasi instantané ...

Quelqu'un a-t-il constaté quelque chose de ce genre ? Et que puis-je faire ?

Merci pour toute réponse.


Bon, j'ai redimensionné mon image avant de la charger afin de ne pas trop exiger du composant et j'ai ainsi un temps plus court. Mais, il est vrai que ceci n'était pas indispensable auparavant ...

Citation:

---

Envoyé par pedestre

Tout à coup, j'ai souhaité entrer une image (.png) en utilisant la fonction stretch pour formater mon image. Alors, j'ai constaté que ce formatage demandait plus d'une minute, alors qu'auparavant c'était quasi instantané ...

---

Avec la même image ?

Salut
lorsque tu dis :

Citation:

---

Envoyé par pedestre

Bonjour,

..... en utilisant la fonction stretch pour formater mon image.

---

C'est la propriété "Stretch" du TImage tu veux dire, non ?

Mets-nous ton code, il y a peut-être quelque chose qui t'a échappé

A+

Merci de vos réponses.

BeanzMaster: Oui, c'est la propriété stretch (j'ai utilisé à tort le mot "fonction") de TImage.

Jipété: Oui c'est la même image. Très bizarrement, depuis longtemps la propriété stretch de TImage mettait bien mon image au format voulu et ceci instantanément. Et puis brusquement, j'ai eu ce problème de lenteur sans que j'aie changé quoi que ce soit au fichier de l'image ni au code de mon programme (j'ai seulement réinstallé les dernières versions proposées de fpc et Lazarus en 64 bits sous XUbuntu).

Bon, j'ai résolu le problème en redimensionnant simplement mon image que j'avais laissée dans un format beaucoup trop grand,..

Bonjour,

Citation:

---

Envoyé par pedestre

Et puis brusquement, j'ai eu ce problème de lenteur sans que j'aie changé quoi que ce soit au fichier de l'image ni au code de mon programme (j'ai seulement réinstallé les dernières versions proposées de fpc et Lazarus en 64 bits sous XUbuntu).

---

J'en déduis que tu as quand même recompilé le binaire, alors ?

Et que donc des choses ont changé dans ton dos, entre les différentes versions des sources, ce qui s'est répercuté sur le binaire final qui s'est mis à faire nawak.

Citation:

---

Envoyé par pedestre

Bon, j'ai résolu le problème en redimensionnant simplement mon image que j'avais laissée dans un format beaucoup trop grand...

---

Pour dépanner rapidement ok, mais ce n'est pas la bonne solution, àmha.
Parce qu'in fine tu ne peux plus utiliser la propriété stretch, du coup. :koi:

Bonjour,

Elle est grande comment cette image ?

Les versions 64 bits sont assez gourmandes en espace mémoire (alignement des adresses, ajustement des tailles des objets, la taille des adresses, le code lui-même, etc.). Peut être, ce n'est qu'une hypothèse, n'a t'il plus assez de place alors il permute à outrance entre mémoire et disque (espace de swap). Auquel cas, les performances sont taupes (elles descendent très bas ;)).

Un coup d’œil sur les ressources mémoires consommées pourrait lever/rejeter cette hypothèse.

Bonne chance.

Citation:

---

Envoyé par Guesset

Bonjour,

Elle est grande comment cette image ?

Les versions 64 bits sont assez gourmandes en espace mémoire (alignement des adresses, ajustement des tailles des objets, la taille des adresses, le code lui-même, etc.). Peut être, ce n'est qu'une hypothèse, n'a t'il plus assez de place alors il permute à outrance entre mémoire et disque (espace de swap). Auquel cas, les performances sont taupes (elles descendent très bas ;)).

Un coup d’œil sur les ressources mémoires consommées pourrait lever/rejeter cette hypothèse.

Bonne chance.

---

Que l'on soit en 32 ou 64 bits la taille prise en mémoire par une image reste la même cela ne change pas. Seule obstacle en 32 bit le maximum autorisé pour un bloc mémoire est de 2Go.
Pour ce qui est du swap le TImage/TBitmap ne l'utilise pas. De plus sous linux il y'a quelques spécificité qu'il faut utiliser par rapport à Windows comme le couple Begin/EndUpdate dans certain cas. (vu avec Jipete sur quelques projets)
De toutes les manières le TImage (et le TBitmap en général) est une vraie tortue avec Lazarus.

Bonjour,

C'est vrai que la taille prise par l'image ne varie pratiquement pas (hormis quelques octets d'alignement) mais tout le reste croit (il suffit de faire une compilation 32 bits et 64 bits pour le voir). Si les ressources sont limitées, on passe allègrement en swap (c'est un phénomène d'avalanche, en dessous du seuil c'est OK, juste au dessus c'est KO).

Le swap n'est pas décidé par le composant mais par le système d'exploitation qui juge seul, selon les ressources disponibles et les priorités, du swap éventuel d'une partie de la mémoire sur le disque. Pour les programmes, hormis les délais c'est transparent, ils ne voient pas que la mémoire n'est plus en ram mais sur disque. Il en résulte que la charge globale de la machine influe également sur ce comportement (un navigateur ouvert qui mange beaucoup d'espace est un bon vecteur de swap).

Ce n'est qu'une hypothèse facile à tester. Je propose d'appliquer le rasoir d'Occam : commencer par tester les hypothèses les plus simples.

Salutations