[1.8.2 Linux/Windows] Bugs de l'OpenPictureDialog EDIT : ou plutôt de l'unité Graphics

Citation:

---

Envoyé par jurassic pork

Par contre il semble toujours y avoir une fuite mémoire (beaucoup moins importante qu'avant) :
Pour la constater, charger le gif 38732719.gif (de plus de 2Mo) plusieurs fois de suite --> A chaque chargement, je me prends 3Mo de mémoire en plus sous windows 10).

---

Oui et non : comme il est rare, dans la vraie vie, de charger le même fichier plusieurs fois de suite, j'ai commencé par charger le 38blabla puis un autre fichier et j'ai recommencé cette séquence de deux, auquel cas la mémoire se libère.
Par contre, oui, charger plusieurs fois le même diminue la mémoire dispo.

Bonsoir

Citation:

---

Envoyé par jurassic pork

hello,
j'ai pris ta dernière version et fait les modifications qui sont indiquées dans le message qui suivait :
Cela semble en effet beaucoup mieux fonctionner : plus de plantage, l'image qui est bien remise à zéro avant le chargement d'un nouveau gif :applo:

Par contre il semble toujours y avoir une fuite mémoire (beaucoup moins importante qu'avant) :
Pour la constater, charger le gif 38732719.gif (de plus de 2Mo) plusieurs fois de suite --> A chaque chargement, je me prends 3Mo de mémoire en plus sous windows 10).

Ami calmant, J.P (sans T)

---

Salut

Merci de ton retour.
J'ai testé en regardant avec le gestionnaire de taches de windows la consommation mémoire reste constante chez moi, je ne me prend pas 3Mo à chaque rechargement :weird:
Dans tous les cas lazarus ne me renvois plus de fuite mémoire chez moi en cochant l'option "Utiliser l'unité Heaptrc".

Pièce jointe 390168

Mis à part cette différence sur la pile. de 192 octets. Je sais que le système en utilise 160 (chiffre vu avec un projet vide) il resterait donc 32 octets. Je me demande de ou cela pourrais provenir ? un idée ?

Citation:

---

Envoyé par Jipété

Bonsoir,

j'ai mis en place la nouvelle version et l'ai testée sous XP / Laz 1.8.2. Rien de particulier à dire.

Mais à l'usage, avec la balle rouge du wiki c'est très bizarre : l'examen des images une par une montre des déformations résumées dans le .gif ci-dessous (nota : j'ai allongé le Delay afin de bien voir les différentes images, qui ont été générées par copie d'écran depuis le fichier d'origine en mode image par image, et remarquez aussi le changement de teinte de l'ombre de la balle) :

déformations non visibles quand on examine en mode "animation" le fichier d'origine où la balle est bien ronde.

Quelqu'un pour expliquer ce mystère ?

---

Bien vue :lun: Les images sont déformées car elle sont mise à l'échelle par rapport au dimensions globale du GIF lors de l'affichage. Normalement les images brutes extraites de la balle sont plus petites.
Dans Function TGIFViewer.DestRect : TRect;au début il faut mettre

Code:

---

1 2 3

PicWidth := FCurrentView.Width; PicHeight := FCurrentView.Height;

---

au lieu de

Code:

---

1 2 3

PicWidth := FGIFWidth; PicHeight := FGIFHeight;

---

Du coup je crois que j'ai trouvé d'ou vient cette petite fuite de mémoire mentionner plus haut.

Dans Function TGIFViewer.RenderFrame(Index : Integer) : TBitmap;il faut mettre

Code:

---

1 2 3 4 5 6

dmKeep: begin FVirtualView.PutImage(Src,0,0, Src.Width, Src.Height,pLeft,pTop,dmAlphaCheck); if Assigned(FRestoreBitmap) then FreeAndNil(FRestoreBitmap); FRestoreBitmap := FVirtualView.Clone; End;

---

Le truc c'est que je ne libère pas FRestoreBitmap et que celui-ci n'est pas initialisé dans le Constructor Create. Mais il reste toujours 192 octets non libéré dans la pile :aie:

15 minutes plus tard..... j'ai trouvé EUREKA !!!! :yaisse3::lahola:

Bon alors dans TColorRGBA32List et TGIFImageList

il faut rajouter dans la partie l'interface

Code:

---

1 2 3 4 5 6 7

TColorRGBA32List = Class(TObjectList) //Class(TBZStringList) Private Protected Function GetColorItem(index: Integer): TColorRGBA32Item; Procedure SetColorItem(index: Integer; val: TColorRGBA32Item); Public procedure Clear; override;

---

Code:

---

1 2 3 4 5 6 7

TGIFImageList = class(TObjectList) private protected function GetItems(Index: integer): TGIFImageListItem; procedure SetItems(Index: integer; AGifImage: TGIFImageListItem); public procedure Clear; override;

---

et dans l'implementation

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

procedure TColorRGBA32List.Clear; Var anItem: TColorRGBA32Item; i : Integer; Begin inherited Clear; If Count > 0 then begin For i := 0 to Count -1 do begin AnItem:= Colors[i]; if anItem<>nil then anItem.Free; End; End; End;

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

procedure TGIFImageList.Clear; Var anItem: TGIFImageListItem; i : Integer; Begin inherited Clear; If Count > 0 then begin For i := 0 to Count -1 do begin AnItem:= Items[i]; if anItem<>nil then anItem.Free; End; End; End;

---

Le pire c'est qu'à la base j'avais ces 2 procedures le seul truc c'est que j'avais mis inherited Clear; à la fin au lieu du début et cela générait une exception. Alors j'avais tout effacé

Voila maintenant

Pièce jointe 390171

Plus de fuites !!!

Je vais continuer à rajouté 2 3 trucs indispensables car je sens que tu va les demander Jipete :ptdr:

Bon aller c'est la bonne, je vais me coucher

Bonne nuit

hello,
en faisant les modifications que tu indiques dans le message précédent, j'avais toujours ma fuite mémoire :( :
Pièce jointe 390186

Par contre si au lieu de mettre la ligne if Assigned(FRestoreBitmap) then FreeAndNil(FRestoreBitmap) dans dmkeep de la fonction TGIFViewer.RenderFrame je la mets au début de la fonction comme ceci :

Code:

---

1 2 3 4 5 6 7 8 9 10

Function TGIFViewer.RenderFrame(Index : Integer) : TBitmap;var Src : TFastBitmap; pTop, pLeft : Integer; Begin Src := FGIFLoader.Frames.Items[Index].Bitmap; pLeft := FGIFLoader.Frames.Items[Index].Left; pTop := FGIFLoader.Frames.Items[Index].Top; if Assigned(FRestoreBitmap) then FreeAndNil(FRestoreBitmap); if Index = 0 then begin

---

je n'ai plus de fuite mémoire :D :
Pièce jointe 390188

Il serait peut-être bien aussi qu'une fois que tu en auras fini avec ton code, tu remettes ton projet en pièce jointe avec un numéro de version (pour le suivi) ;) .

Ami calmant, J.P (sans T)

Yop !

Citation:

---

Envoyé par BeanzMaster

Bien vu :lun: Les images sont déformées car elles sont mises à l'échelle par rapport aux dimensions globales du GIF lors de l'affichage. Normalement les images brutes extraites de la balle sont plus petites.
Dans Function TGIFViewer.DestRect : TRect;au début il faut mettre

Code:

---

1 2 3

PicWidth := FCurrentView.Width; PicHeight := FCurrentView.Height;

---

au lieu de

Code:

---

1 2 3

PicWidth := FGIFWidth; PicHeight := FGIFHeight;

---

---

OK, mais cette modif génère ce genre d'images, sous Linux ! Parce que sous XP c'est parfait... Problème de transparence ?
Pièce jointe 390232
Pièce jointe 390235
Pièce jointe 390236

Je comprends mieux pourquoi les gars de FreePascal ont lâché l'affaire :
Pièce jointe 390256

Un dernier mot, tiens, à propos de cette image, où l'on voit que sous XP trois points de suspension sont apparus alors qu'ils ne sont pas nécessaires. Alors j'ai fait des tests en mettant le fichier dans P:\ puis P:\Programmation et enfin P:\Programmation\GIF et là, il semblerait qu'il y ait un souci de décodage de chemin :
Pièce jointe 390248


Pour la fuite mémoire, je vous laisse en discuter.

Salut

Citation:

---

Envoyé par jurassic pork

hello,
en faisant les modifications que tu indiques dans le message précédent, j'avais toujours ma fuite mémoire :( :

Par contre si au lieu de mettre la ligne if Assigned(FRestoreBitmap) then FreeAndNil(FRestoreBitmap) dans dmkeep de la fonction TGIFViewer.RenderFrame je la mets au début de la fonction comme ceci :

Il serait peut-être bien aussi qu'une fois que tu en auras fini avec ton code, tu remettes ton projet en pièce jointe avec un numéro de version (pour le suivi) ;) .

Ami calmant, J.P (sans T)

---

Arf, effectivement, j'avais deja fait quelques petits changements, on ne pouvais pas être synchro, je n'y ai plus pensé ce matin. :oops:

J'ai rajouté une numero de version à l'archive qui correspond à celle dans les commentaires de l'unité uGifViewer : version 0.3

Citation:

---

Envoyé par Jipété

Yop !
OK, mais cette modif génère ce genre d'images, sous Linux ! Parce que sous XP c'est parfait... Problème de transparence ?

---

J'ai testé sous Linux, et j'ai pu constaté le même truc. J'ai modifié le code. Ca devrait être bon maintenant

Citation:

---

Envoyé par Jipété

Un dernier mot, tiens, à propos de cette image, où l'on voit que sous XP trois points de suspension sont apparus alors qu'ils ne sont pas nécessaires. Alors j'ai fait des tests en mettant le fichier dans P:\ puis P:\Programmation et enfin P:\Programmation\GIF et là, il semblerait qu'il y ait un souci de décodage de chemin :

---

Je regarderais ce soir.

En attendant allez hop une petite 3eme version de test

Nouveautés :

• Affichage avec ou sans transparence propriété TGIFViewer.Transparent
• L'image affichée est accessible depuis la propriété TGIFViewer.CurrenView
• Possibilité de chargé un GIF depuis une resource (non testé)

Pièce jointe 390490

A+

hello,
:applo: bravo pour la version 0.3 tout semble fonctionner !
En ce qui concerne l'affichage du chemin du fichier c'est la fonction EllipsisPath qui semble avoir quelques problèmes. Tu peux la remplacer par la fonction MinimizeName de l'unité FileCtrl comme ceci par exemple :

Code:

---

1 2 3

// uses FileCtrl // ... lblFileName.Caption := MinimizeName(ImageFileName,lblFileName.Canvas,lblFileName.ClientWidth);

---

Ami calmant, J.P (sans T)

Bonjour,

Mes retours sous Linux :

Citation:

---

Envoyé par jurassic pork

Code:

---

1 2 3

uses FileCtrl //!\ // ... lblFileName.Caption := MinimizeName(ImageFileName,lblFileName.Canvas,lblFileName.ClientWidth);

---

---

Testé et validé, :plusser:

Gros problèmes de transparence avec pen-anime (à noter le tout petit zigouigoui blanc en haut à gauche) :
Pièce jointe 390608

et SmallFullColour (Transparent décoché c'est pire) :
Pièce jointe 390612

un point de détail avec la balleWiki, qui rejoint ce que je disais hier à propos de Canvas.Rectangle : selon que je coche Transparent ou pas, je n'ai pas ou j'ai une bordure à droite et une autre en bas (ai changé la couleur de transparence pour bien la mettre en évidence) :
Pièce jointe 390615

Ergonomie :
- cocher/décocher Transparent arrête l'animation si elle est en cours, dommage.
- quand on clique sur "Start" pour lancer une animation, on regarde ensuite l'animation et il est dommage de la lâcher pour chercher le bouton "Pause" en cas de besoin : il serait mieux que "Start" devienne "Pause", àmha, comme ça on pourrait lancer/pauser l'anim sans la quitter des yeux.
- quand on est en pause, c'est dommage d'être obligé de passer par "Stop" pour parcourir les images brutes (et la case à cocher ne sert à rien : à partir du moment où le spin est activé par "Stop", on l'utilise ou pas, ça devrait suffire). En résumé pour ce point-là, plus qu'à combiner l'indicateur "Images" tout en bas avec l'indicateur du Spin et ça fera un truc tout-en-un qui pourrait être cool.


Pendant que j'y suis, pbs de fichiers :
fc3e2b992c559055267e26dc23e484c0 devrait être dans les bad : "membership" affiché, boutons grisés.

9f8f60... je le renomme 9f8f_malfini car en effet au lieu de se terminer par ";" il se termine par "!", mais je le garde, ça peut être utile pour tester la fonction d'ouverture.

fc3e2b... est dans les good, il passe dans les bad car :
- il ne s'ouvre pas (boutons grisés) ;
- il a exactement la même taille que 9f8f_malfini et les première et dernière pages dans l'éditeur hexa sont identiques, sauf qu'il est bien fini.

Les deux dernières lignes des fichiers 9f8f_malfini en haut, et fc3e2b en bas :
Pièce jointe 390618

Bonjour,

Citation:

---

Envoyé par Jipété

Bonjour,

Mes retours sous Linux :


Testé et validé, :plusser:

Gros problèmes de transparence avec pen-anime (à noter le tout petit zigouigoui blanc en haut à gauche) :
Pièce jointe 390608

et SmallFullColour (Transparent décoché c'est pire) :
Pièce jointe 390612

---

Merci, c'est bon j'ai corrigé le problème

Citation:

---

Envoyé par Jipété

un point de détail avec la balleWiki, qui rejoint ce que je disais hier à propos de Canvas.Rectangle : selon que je coche Transparent ou pas, je n'ai pas ou j'ai une bordure à droite et une autre en bas (ai changé la couleur de transparence pour bien la mettre en évidence) :

---

Rien à voir avec Canvas.Rectangle. Les bordures noire que tu vois lorsque tu affiches sans la prise en charge de la transparence sont normales. La couleur noire est la couleur transparente dans ce gif. Testes avec le singe.

Citation:

---

Envoyé par Jipété

Ergonomie :
- cocher/décocher Transparent arrête l'animation si elle est en cours, dommage.

---

C'est tout simplement impossible par la nature de la structure de l'animation d'un GIF qui peut-être différent de l'un à l'autre. Certain (la majorité des GIFs sont par défaut transparent). Le calcul final d'une image de l'animation peux dépendre de la précédente et du mode défini pour chaque image. De plus ici les images pour l'animation sont pré-calculées. Sinon cela reviendrai à afficher directement les images brutes sans transparence (prend la girl par exemple avec un fond noire , cela serai les images que tu visualiserais dans ce cas). D'ou le besoin d'arrêter l'animation et de recharger le fichier. Notes que pour un affichage de la transparence correcte avec les TBitmap on doit passe par l'utilisation des masques. Cela serait surement possible de faire ce que tu demandes mais alourdirai énormément le code et cela n'as pas vraiment d'intérêt à mon sens.

EDIT : Cela serai possible, mais il faudrait faire comme dans mon projet ne pas passer par la LCL et les TBitmap pour l'affichage et utiliser directement les API du système.

Citation:

---

Envoyé par Jipété

- quand on clique sur "Start" pour lancer une animation, on regarde ensuite l'animation et il est dommage de la lâcher pour chercher le bouton "Pause" en cas de besoin : il serait mieux que "Start" devienne "Pause", àmha, comme ça on pourrait lancer/pauser l'anim sans la quitter des yeux.

- quand on est en pause, c'est dommage d'être obligé de passer par "Stop" pour parcourir les images brutes (et la case à cocher ne sert à rien : à partir du moment où le spin est activé par "Stop", on l'utilise ou pas, ça devrait suffire). En résumé pour ce point-là, plus qu'à combiner l'indicateur "Images" tout en bas avec l'indicateur du Spin et ça fera un truc tout-en-un qui pourrait être cool.

---

Oui combiner l'indicateur j'y avais penser. Par contre dire que la case à cocher ne sert à rien, pas du tout justement lorsqu'elle est cochée tu visualises les images brutes du gif, sinon ce sont les images pré-calculées de l'animation. Ce n'est pas la même chose.

Après rien ne t'empêches de faire des modifs comme bon te semble. C'est juste un programme de démonstration de l'utilisation du composant.

Citation:

---

Envoyé par Jipété

Pendant que j'y suis, pbs de fichiers :
fc3e2b992c559055267e26dc23e484c0 devrait être dans les bad : "membership" affiché, boutons grisés.

9f8f60... je le renomme 9f8f_malfini car en effet au lieu de se terminer par ";" il se termine par "!", mais je le garde, ça peut être utile pour tester la fonction d'ouverture.

fc3e2b... est dans les good, il passe dans les bad car :
- il ne s'ouvre pas (boutons grisés) ;
- il a exactement la même taille que 9f8f_malfini et les première et dernière pages dans l'éditeur hexa sont identiques, sauf qu'il est bien fini.

Les deux dernières lignes des fichiers 9f8f_malfini en haut, et fc3e2b en bas :

---

Pour ça je te l'avais dis dans les BAD se sont les fichiers pour lesquels aucune erreurs est levée par le composants lui même pour permettre le chargement sans embêter l'utilisateur avec ces petits défauts. On pourrais aisément rajouter ces erreurs. Et effectivement il serait peut-être préférable de mettre tous les fichiers mal encodés dans ce dossier, cela éviterai la confusion.


Je posterai une mise à jour d'ici ce week-end

Merci des retours :ccool:
A+

@BeanzMaster

Bravo. Testé avec succès sous Windows. :ccool:

Citation:

---

Envoyé par jurassic pork

En ce qui concerne l'affichage du chemin du fichier c'est la fonction EllipsisPath qui semble avoir quelques problèmes. Tu peux la remplacer par la fonction MinimizeName de l'unité FileCtrl comme ceci par exemple :

Code:

---

1 2 3

// uses FileCtrl // ... lblFileName.Caption := MinimizeName(ImageFileName,lblFileName.Canvas,lblFileName.ClientWidth);

---

---

Tiens, je ne connaissais pas cette fonction. Ça mériterait une entrée dans la FAQ.

Citation:

---

Envoyé par BeanzMaster

Merci, c'est bon j'ai corrigé le problème

---

Ah !
Comment ?
Tu as inclus un nouveau fichier dans la vieille archive 0.3 d'hier ?
Ou tu as modifié 2-3 lignes par ci par là mais il faut qu'on devine ? :ptdr:
Ou tu as simplement zappé cette information pour cause de surmenage ? :mouarf:

Citation:

---

Envoyé par BeanzMaster

Rien à voir avec Canvas.Rectangle. Les bordures noires que tu vois lorsque tu affiches sans la prise en charge de la transparence sont normales. La couleur noire est la couleur transparente dans ce gif. Testes avec le singe.

---

J'ai testé sous Linux only avec le singe et tout ce que j'ai vu c'est des images de largeurs différentes si je décoche "Transparent".
Mais on s'est peut-être pas compris, ou je me suis mal exprimé.
Je viens de vérifier : concernant la ballewiki rouge, la demi-bordure (en bas et à droite) apparaît en mode "Animation" et "Transparent" décoché. En mode image par image, "Transparent" coché ou pas n'a aucune incidence sur le fait que la demi-bordure n'apparaît pas.
J'ai utilisé l'espagnol pour extraire et enregistrer les 8 frames :
Pièce jointe 390908
La 1^re est sélectionnée, elle fait 50x50, toutes les autres ont des tailles chelou (35x33, 34x38, 29x44, etc.) et on notera deux images avec une traînée rouge sur le côté droit.
Mais comment vois-tu que la transparence est noire pour ce fichier ?

Si je demande à Gimp de m'afficher le singe et la balle rouge (zoomée à 400%) on voit bien la transparence avec le singe : on voit les boules des trois images.
Pièce jointe 390911

Mais on ne voit rien de tel concernant la balle rouge.
Au passage, ce qui est intéressant avec cet outil, c'est dans la bande en bas les mots "replace" et "combine" qui doivent être la "Method" d'affichage Gif.

Et tout ça me fait penser qu'il faudrait un indicateur signalant si l'auteur de l'image l'a prévue transparente ou pas. Car tant qu'on a les mains dans le cambouis, je pense qu'il est bon de pouvoir cocher-décocher, mais cette possibilité devrait être désactivée dans la version finale, tout comme le mode image par image, tu vois ce que je veux dire ?

Citation:

---

Envoyé par BeanzMaster

Après rien ne t'empêche de faire des modifs comme bon te semble. C'est juste un programme de démonstration de l'utilisation du composant.

---

Je sais bien, mais là j'ai légèrement dévié vers l'étude de la transparence via Canvas.BrushCopy (comme on a pu le lire tout récemment), et c'est loin d'être fini. C'est dommage car le case of Method s'appuie là-dessus; aussi bien pour l'espagnol que pour TGifAnim.

(d'un autre côté, quand on regarde les 2 fichiers conseillés par J.P extraits de la jvcl, on sort d'abord sa boîte d'aspirine et puis on part en courant en laissant tout tomber, :mrgreen:)

Salut

Citation:

---

Envoyé par Jipété

Ah !
Comment ?
Tu as inclus un nouveau fichier dans la vieille archive 0.3 d'hier ?

---

Non

Citation:

---

Envoyé par Jipété

Ou tu as modifié 2-3 lignes par ci par là mais il faut qu'on devine ? :ptdr:
Ou tu as simplement zappé cette information pour cause de surmenage ? :mouarf:

---

Oui juste 2,3 ligne et oui je devais repartir bosser

Citation:

---

Envoyé par Jipété

J'ai testé sous Linux only avec le singe et tout ce que j'ai vu c'est des images de largeurs différentes si je décoche "Transparent".
...
Je viens de vérifier : concernant la ballewiki rouge, la demi-bordure (en bas et à droite) apparaît en mode "Animation" et "Transparent" décoché. En mode image par image, "Transparent" coché ou pas n'a aucune incidence sur le fait que la demi-bordure n'apparaît pas.
J'ai utilisé l'espagnol pour extraire et enregistrer les 8 frames :
La 1^re est sélectionnée, elle fait 50x50, toutes les autres ont des tailles chelou (35x33, 34x38, 29x44, etc.) et on notera deux images avec une traînée rouge sur le côté droit.

---

Ca c'est normal. Les images de l'animation peuvent être de taille différentes. Et ensuite est sont positionnées au bon endroit grace aux infos extraites de "l'Imgae Descriptor" (Left/Top)

Citation:

---

Envoyé par Jipété

Mais on s'est peut-être pas compris, ou je me suis mal exprimé.

Mais comment vois-tu que la transparence est noire pour ce fichier ?
Si je demande à Gimp de m'afficher le singe et la balle rouge (zoomée à 400%) on voit bien la transparence avec le singe : on voit les boules des trois images.

---

Non j'ai bien compris, en fait c'est moi qui me suis fourvoyé. les bandes noires en dernière ligne et dernière colonne sont une erreur d'affichage (que j'ai corrigé en passant ). Je n'avais plus de temps hier pour poster une réponse. Je me suis rendu compte et confirmer ce bug avec un autre gif qui n'est pas dans la TestSuite.

Citation:

---

Envoyé par Jipété

Mais on ne voit rien de tel concernant la balle rouge.
Au passage, ce qui est intéressant avec cet outil, c'est dans la bande en bas les mots "replace" et "combine" qui doivent être la "Method" d'affichage Gif.

---

Tu peux voir le rendu dans TGIFViewer.RenderFrame avec les methodes : dmNone, dmKeep, dmErase, dmRestore

Citation:

---

Envoyé par Jipété

Et tout ça me fait penser qu'il faudrait un indicateur signalant si l'auteur de l'image l'a prévue transparente ou pas. Car tant qu'on a les mains dans le cambouis, je pense qu'il est bon de pouvoir cocher-décocher, mais cette possibilité devrait être désactivée dans la version finale, tout comme le mode image par image, tu vois ce que je veux dire ?

---

Ok je vais rajouté une propriété GIFIsTransparent dans TGIFViewer. Pour le mode Image par image les bitmaps, je vais rajouter 2 fonctions (ou modifier celle présentent) pour qu'elles n'affichent pas les bitmap, juste pour pouvoir extraire les TBItmaps
Pour l'instant dans la démo je vais laisser. A la limite je pourrais refaire un petit visualiseur plus orienter "Outil de tous les jour"

Citation:

---

Envoyé par Jipété

Je sais bien, mais là j'ai légèrement dévié vers l'étude de la transparence via Canvas.BrushCopy (comme on a pu le lire tout récemment), et c'est loin d'être fini. C'est dommage car le case of Method s'appuie là-dessus; aussi bien pour l'espagnol que pour TGifAnim.

(d'un autre côté, quand on regarde les 2 fichiers conseillés par J.P extraits de la jvcl, on sort d'abord sa boîte d'aspirine et puis on part en courant en laissant tout tomber, :mrgreen:)

---

Petite question comment s'affiche le singe avec ces 2 trucs ? La transparence est elle prise en charge correctement ?

Concernant la Jvlc j'ai jeté un oeil et je pense qu'il y a les mêmes défauts que les 2 autres la moitié des image de la TestSuite ne seront pas chargées correctement à mon avis

Pour la mise à jour je vais essayé de faire ça dans la journée

Bonjour

Citation:

---

Envoyé par Roland Chastain

@BeanzMaster

Bravo. Testé avec succès sous Windows. :ccool:



Tiens, je ne connaissais pas cette fonction. Ça mériterait une entrée dans la FAQ.

---

Merci Roland 8-)
Idem JP, je ne connaissais pas cette fonction :plusser:

Citation:

---

Envoyé par BeanzMaster

Petite question comment s'affiche le singe avec ces 2 trucs ? La transparence est elle prise en charge correctement ?

---

Parfaitement bien : transparent coché --> juste le singe et ses baballes, transparent décoché --> fond fuchsia rajouté.
Sous Linux c'est impec.

Citation:

---

Envoyé par BeanzMaster

Pour la mise à jour je vais essayé de faire ça dans la journée

---

Prends ton temps, prends ton temps, 8-)

Bonjour,

le compo TGifAnim n'est pas fini, à un endroit : la manière de rendre les bitmaps, :aie:

Je rappelle d'abord les spécifications, trouvées dans la doc officielle (le gras c'est moi) :

Citation:

---

Disposal Method - Indicates the way in which the graphic is to be treated after being displayed.
Values :
0 - No disposal specified. The decoder is not required to take any action.
1 - Do not dispose. The graphic is to be left in place.
2 - Restore to background color. The area used by the graphic must be restored to the background color.
3 - Restore to previous. The decoder is required to restore the area overwritten by the graphic with what was there prior to rendering the graphic.
4-7 - To be defined.

---

avec la recommandation qui va avec :

Citation:

---

Disposal Method - The mode Restore To Previous is intended to be used in small sections of the graphic; the use of this mode imposes severe demands on the decoder to store the section of the graphic that needs to be saved. For this reason, this mode should be used sparingly (avec parcimonie).
This mode is not intended to save an entire graphic or large areas of a graphic; when this is the case, the encoder should make every attempt to make the sections of the graphic to be restored be separate graphics in the data stream.
In the case where a decoder is not capable of saving an area of a graphic marked as Restore To Previous, it is recommended that a decoder restore to the background color.

---

J'aime bien la dernière phrase, lire juste après.

Et maintenant, la manière dont le compo gère cette affaire :

Code:

---

1 2 3 4 5 6 7

case Method of //0 : Not specified... //1 : No change Background 2: BufferImg.Canvas.FillRect( Rect(PosX, PosY, Bitmap.Width + PosX, Bitmap.Height + PosY)); 3: BufferImg.Canvas.FillRect(Rect(0, 0, Width, Height)); end;

---

BufferImg c'est un tampon de travail, tout le monde l'avait compris.

Grâce à la dernière phrase précédente que j'aime bien, on peut même simplifier ainsi (je n'ai pas noté de différences de rendu à ce jour) :

Code:

---

1 2 3 4 5 6

case Method of //0 : Not specified... //1 : No change Background 2,3 : BufferImg.Canvas.FillRect( Rect(PosX, PosY, Bitmap.Width + PosX, Bitmap.Height + PosY)); end;

---

Ma demande d'aide est très simple : étant entendu que les images en mode 1 sont mal rendues, que mettre dans le point 1 du case Method of s'appuyant sur les specs (que je rappelle : Do not dispose. The graphic is to be left in place.) pour avoir un rendu correct ?
J'ai tenté ça, mais c'est toujours aussi moche (pb de transparence) :

Code:

---

1: if FCurrentImage > 0 then BufferImg.Canvas.Draw(0, 0, GifBitmaps.Items[FCurrentImage-1].Bitmap);

---

Du coup, je suis un peu sec, là...

Le code complet (ou presque : on s'en fiche un peu du mode "Design", et j'ai aussi enlevé la ligne concernant le délai, allons à l'essentiel) dans procedure TGifAnim.Paint; :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

if (FCurrentImage < GifBitmaps.Count) then with GifBitmaps.Items[FCurrentImage] do begin BufferImg.Canvas.Brush.Color := self.Color; if FCurrentImage = 0 then // 1re image BufferImg.Canvas.FillRect(Rect(0, 0, Width, Height)); BufferImg.Canvas.Draw(PosX, PosY, Bitmap); // le bmp de l'image en cours CurrentView.Assign(BufferImg); // affichage case Method of //0 : Not specified... //1 : No change Background 2,3: BufferImg.Canvas.FillRect( // area used by graphic must be restored to background color. Rect(PosX, PosY, Bitmap.Width + PosX, Bitmap.Height + PosY)); end; end; Canvas.Draw(0, 0, CurrentView);

---

Un dernier mot, concernant la 1^re image. J'ai testé ça, just curious :

Code:

---

1 2 3

if FCurrentImage = 0 then //pour tester BufferImg.Canvas.FillRect(Rect(0, 0, Width, Height)); BufferImg.Canvas.Draw(0, 0, Bitmap); // pas vu de différence

---

Mon souci de compréhension de cette histoire, c'est que par exemple TAnimatedGif.pas utilise ça :

Code:

---

1 2	type TDisposeMode = (dmNone, dmKeep, dmErase, dmRestore);

---

mais une recherche de dmKeep dans le fichier ne renvoie rien (à part cette ligne) alors que dmErase remonte plein de choses et que les fichiers qui posent problème avec TGifAnim sont corrects avec TAnimatedGif...
:koi:
Bon, j'arrête de vous saouler, merci d'avance pour les retours,

Citation:

---

Envoyé par Jipété

Bonjour,
Mon souci de compréhension de cette histoire, c'est que par exemple TAnimatedGif.pas utilise ça :

Code:

---

1 2	type TDisposeMode = (dmNone, dmKeep, dmErase, dmRestore);

---

mais une recherche de dmKeep dans le fichier ne renvoie rien (à part cette ligne) alors que dmErase remonte plein de choses et que les fichiers qui posent problème avec TGifAnim sont corrects avec TAnimatedGif...
:koi:

---

Celui-ci, sont les bons

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71

Procedure TGIFViewer.RenderFrame(Index: Integer); Var Src: TFastBitmap; pTop, pLeft: Integer; iDrawMode: TFastBitmapDrawMode; TmpBmp : Graphics.TBitmap; Begin Src := FGIFLoader.Frames.Items[Index].Bitmap; pLeft := FGIFLoader.Frames.Items[Index].Left; pTop := FGIFLoader.Frames.Items[Index].Top;   FRenderCache.AddNewCache; FRenderCache.Items[Index].Delay := FGIFLoader.Frames[Index].Delay;   If Index = 0 Then Begin If (FTransparent) Then Begin FVirtualView.Clear(clrTransparent); iDrawMode := dmAlphaCheck; End Else Begin FVirtualView.Clear(FGIFLoader.BackgroundColor); iDrawMode := dmSet; End; FVirtualView.PutImage(Src, 0, 0, Src.Width, Src.Height, pLeft, pTop, dmSet); FRestoreBitmap := FVirtualView.Clone; End Else Begin   With FGIFLoader.Frames.Items[Index] Do Begin Case DrawMode Of dmNone: Begin FVirtualView.PutImage(Src, 0, 0, Src.Width, Src.Height, pLeft, pTop, iDrawMode); End; dmKeep: Begin FVirtualView.PutImage(Src, 0, 0, Src.Width, Src.Height, pLeft, pTop, iDrawMode); If Assigned(FRestoreBitmap) Then FreeAndNil(FRestoreBitmap); FRestoreBitmap := FVirtualView.Clone; End; dmErase: Begin If (FGIFLoader.Frames.Items[Index].IsTransparent And FTransparent) Then FVirtualView.Clear(clrTransparent) Else FVirtualView.Clear(FGIFLoader.BackgroundColor); FVirtualView.PutImage(Src, 0, 0, Src.Width, Src.Height, pLeft, pTop, iDrawMode); End; dmRestore: Begin FVirtualView.PutImage(FRestoreBitmap, 0, 0, FRestoreBitmap.Width, FRestoreBitmap.Height, 0, 0, dmSet); FVirtualView.PutImage(Src, 0, 0, Src.Width, Src.Height, pLeft, pTop, iDrawMode); End; Else FVirtualView.PutImage(Src, 0, 0, Src.Width, Src.Height, pLeft, pTop, dmSet); End; End; End; // Note : Sous MacOS on ne peux pas assigner FRenderCache.Items[Index].Bitmap directement avec // FVirtualView.GetBitmap; On est obligé de créer le bitmap de destination et utiliser Assign. // Dans le cas contraire seulment la première image sera affichée. TmpBmp := Graphics.TBitmap.Create; TmpBmp := FVirtualView.GetBitmap; FRenderCache.Items[Index].Bitmap.Assign(TmpBmp); FreeAndNil(TmpBmp); If FGIFLoader.FFrames[Index].Delay <> 0 Then FAnimateTimer.Interval := FGIFLoader.FFrames[Index].Delay * FAnimateSpeed; End;

---

Citation:

---

Disposal Method - Indicates the way in which the graphic is to be treated after being displayed. --------> Après que la 1ere image est été affichée
Values :
0 - No disposal specified. The decoder is not required to take any action. -------------------> dmNone L'image est affichée tel quelle
1 - Do not dispose. The graphic is to be left in place. -------------------> dmKeep L' image doit être affichée tel quelle et sauvegardée pour une utilisation du mode dmRestore plus tard
2 - Restore to background color. The area used by the graphic must be restored to the background color. -------------------> dmErase Le fond doit être effacée avant d'afficher l'image
3 - Restore to previous. The decoder is required to restore the area overwritten by the graphic with what -------------------> dmRestore Le fond précédemment sauvegarder par dmKeep doit être utilisé (comme fond) avant de traiter l'image
was there prior to rendering the graphic.
4-7 - To be defined.

---

J'espère que cela t'aidera. Arrêtes de te prendre la tête utilises mon composant :mouarf:

EDIT : Je viens de penser à un truc il est a noter que l'image 0 peut prendre comme valeur seulement dmNone, dmKeep et dmErase. Et que dans mon code

Code:

---

1 2 3 4 5 6

dmErase: Begin If (FGIFLoader.Frames.Items[Index].IsTransparent And FTransparent) Then FVirtualView.Clear(clrTransparent) Else FVirtualView.Clear(FGIFLoader.BackgroundColor); FVirtualView.PutImage(Src, 0, 0, Src.Width, Src.Height, pLeft, pTop, iDrawMode);

---

iDrawMode peut-être égal à dmAlphaCheck

du coup au début de ma procedure mon test :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

If (FTransparent) Then Begin FVirtualView.Clear(clrTransparent); iDrawMode := dmAlphaCheck; End Else Begin FVirtualView.Clear(FGIFLoader.BackgroundColor); iDrawMode := dmSet; End;

---

est erroné il devrait être If (FGIFLoader.Frames.Items[0].IsTransparent) then et ensuite seulement je devrais peut-être faire If (FTransparent) Then faut que je teste, mais je ne suis jamais tombé sur ce genre de gif. Je vais regardé si je peux faire une petite anim avec gimp

Citation:

---

Envoyé par BeanzMaster

Citation:

---

0 - No disposal specified. The decoder is not required to take any action. -------------------> dmNone L'image est affichée telle quelle
1 - Do not dispose. The graphic is to be left in place. -------------------> dmKeep L' image doit être affichée telle quelle et sauvegardée pour une utilisation du mode dmRestore plus tard
2 - Restore to background color. The area used by the graphic must be restored to the background color. -------------------> dmErase Le fond doit être effacé avant d'afficher l'image
3 - Restore to previous. The decoder is required to restore the area overwritten by the graphic with what was there prior to rendering the graphic.-------------------> dmRestore Le fond précédemment sauvegardé par dmKeep doit être utilisé (comme fond) avant de traiter l'image

---

---

Où as-tu trouvé ces explications ?

Par exemple, dans le cas 0, une fois l'image affichée il n'y aurait rien à faire, et c'est comme ça avec TGifAnim et dans TAnimatedgif.pas.
Tu dis "L'image est affichée telle quelle" et moi je précise "avant d'entrer dans le case" et l'option dit bien qu'il n'y a rien à faire ensuite.
Alors pourquoi y mets-tu du code, toi ?

Citation:

---

Envoyé par BeanzMaster

J'espère que cela t'aidera.

---

Va me falloir un peu de temps.

Citation:

---

Envoyé par BeanzMaster

Arrête de te prendre la tête, utilise mon composant :mouarf:

---

C'est prévu, mais j'aimerais bien amener l'espagnol et TGifAnim au bout, il ne doit pas manquer grand chose, et ça me permet (d'essayer) de bien comprendre la mécanique interne.

Citation:

---

Envoyé par Jipété

Où as-tu trouvé ces explications ?

---

En faisiant des recherches complémentaires sur le format GIF. J'ai regardé dans les code de firefox et gimp notemment

Citation:

---

Envoyé par Jipété

Par exemple, dans le cas 0, une fois l'image affichée il n'y aurait rien à faire, et c'est comme ça avec TGifAnim et dans TAnimatedgif.pas.
Tu dis "L'image est affichée telle quelle" et moi je précise "avant d'entrer dans le case" et l'option dit bien qu'il n'y a rien à faire ensuite.
Alors pourquoi y mets-tu du code, toi ?

---

Regardes bien dans la procedure de TGifAnim. Que fait-il juste avant le case ?

Code:

---

1 2 3

BufferImg.Canvas.Draw(PosX, PosY, Bitmap); CurrentView.Assign(BufferImg);

---

Par défaut il prend en charge le mode 0 et 1.
La façon de faire ici est bonne seulement si le gif est correctement encodé. Il travaille pour les mode 2 et 3 avec l'image n-1.

Prenons le mode 2 ou il efface l'image qu'il a précédemment copié avec les lignes de code ci-dessus. Pour ma part je n'ai pas trouvé cela logique de travailler avec 1 temps d'avance.
les données dans le gif ont un ordre précis. (oui je sais ce qui la doc, par rapport à ça)
Pour TGifAnim la première image de l'animation n'est pas l'image 0 mais la couleur de fond si elle est définie (Une palette de couleur global existe) sinon c'est la couleur choisi par l'utilisateur et de là commence le travail avec ces "DisposalMode"

Voici ce qu'on trouve en commentaire dans TGifImage pour Delphi

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61

{ Disposal mode algorithm:   Step 1: Copy destination to backup buffer   Always executed before first frame and only once.   Done in constructor. Step 2: Clear previous frame (implementation is same as step 6)   Done implicitly by implementation.   Only done explicitly on first frame if goClearOnLoop option is set. Step 3: Copy backup buffer to frame buffer Step 4: Draw frame Step 5: Copy buffer to destination Step 6: Clear frame from backup buffer +------------+------------------+---------------------+------------------------+ |New \ Old | dmNone | dmBackground | dmPrevious | +------------+------------------+---------------------+------------------------+ |dmNone | | | | | |4. Paint on backup|4. Paint on backup |4. Paint on backup | | |5. Restore |5. Restore |5. Restore | +------------+------------------+---------------------+------------------------+ |dmBackground| | | | | |4. Paint on backup|4. Paint on backup |4. Paint on backup | | |5. Restore |5. Restore |5. Restore | | |6. Clear backup |6. Clear backup |6. Clear backup | +------------+------------------+---------------------+------------------------+ |dmPrevious | | | | | | |3. Copy backup to buf|3. Copy backup to buf | | |4. Paint on dest |4. Paint on buf |4. Paint on buf | | | |5. Copy buf to dest |5. Copy buf to dest | +------------+------------------+---------------------+------------------------+ } case (Disposal) of dmNone, dmNoDisposal: begin DrawDestination := BackupBuffer.Canvas; DrawRect := BackupBuffer.Canvas.ClipRect; DoStep5 := True; end; dmBackground: begin DrawDestination := BackupBuffer.Canvas; DrawRect := BackupBuffer.Canvas.ClipRect; DoStep5 := True; DoStep6 := True; end; dmPrevious: case (OldDisposal) of dmNone, dmNoDisposal: begin DrawDestination := FCanvas; DrawRect := FRect; end; dmBackground, dmPrevious: begin DrawDestination := FrameBuffer.Canvas; DrawRect := FrameBuffer.Canvas.ClipRect; DoStep3 := True; DoStep5 := True; end; end; end;

---

J'ai été beaucoup plus directe dans mon implémentation et cela marche tout aussi bien.

Citation:

---

Envoyé par Jipété

C'est prévu, mais j'aimerais bien amener l'espagnol et TGifAnim au bout, il ne doit pas manquer grand chose, et ça me permet (d'essayer) de bien comprendre la mécanique interne.

---

C'est une bonne chose et effectivement il ne manque pas grand chose.