Discussion :

[Jipété]

Yop !

C'est grâce à des personnes comme toi qui teste et qui donne des retours constructifs et pertinents qu'on évolue, c'est très agréable.

Attention ! Je n'ai testé que la démo du GifViewer, je laisse à d'autres le soin de jouer avec GifRes ainsi qu'avec le package, sa procédure d'install et le fonctionnement du composant lorsqu'il est directement posé sur une fiche depuis l'EDI.

Merci pour les dernières modifs, ça permet de remarquer que le panneau de visualisation s'agrandit entre le lancement du prog et le 1^er drag'n'drop :


Du coup, plein de choses bougent vers le bas et ça perturbe la vision de l'ensemble (curieux d'ailleurs que je ne l'aie pas vu auparavant : je viens de vérifier, ce défaut est présent dans la version précédente).

Modifs perso : passage des compos de choix du langage à invisible, de la couleur du panneau à blanc, et la taille de la police est plus grande sous Linux, c'est comme ça.

[BeanzMaster]

Salut,

Yop !

Attention ! Je n'ai testé que la démo du GifViewer, je laisse à d'autres le soin de jouer avec GifRes ainsi qu'avec le package, sa procédure d'install et le fonctionnement du composant lorsqu'il est directement posé sur une fiche depuis l'EDI.

Merci pour les dernières modifs, ça permet de remarquer que le panneau de visualisation s'agrandit entre le lancement du prog et le 1^er drag'n'drop :

Du coup, plein de choses bougent vers le bas et ça perturbe la vision de l'ensemble (curieux d'ailleurs que je ne l'aie pas vu auparavant : je viens de vérifier, ce défaut est présent dans la version précédente).

Modifs perso : passage des compos de choix du langage à invisible, de la couleur du panneau à blanc, et la taille de la police est plus grande sous Linux, c'est comme ça.

Ce comportement n'est pas visible sous Windows et Mac. Le plus drôle c'est que le TGifViewer est posé sur un TPanel avec la propriété Align sur alClient normalement c'est à lui de s'adapter et non l'inverse. J'ai testé en posant le TGifViewer sur la "form" directement même comportement. j'ai testé en commentant le code de Paint et CalculatePreferredSize résultat idem .

[BeanzMaster]

Je viens de faire un test en rajoutant un 2eme TPanel dans le panel "pnlViewer" il semblerai que le problème vienne en fait du TGroupBox des commentaires qui pousse vers le bas. Pourquoi ? aucune idée



Si tu places le TGroupBox dans un panel tu verras que cela viens de lui

[BeanzMaster]

Allez un autre test, et là il semble que ce soit plutôt le TMemo qui provoque ce décalage

[Jipété]

Salut,

me voilà de retour, je vois le bout du tunnel avec la pompe : après avoir changé la pompe entière et le clapet anti-retour, ça serait malheureux ! Reste un souci avec la pompe électrique...

Allez un autre test, et là il semble que ce soit plutôt le TMemo qui provoque ce décalage

J'ai refait ton test et chez moi ça se comporte comme déjà signalé : c'est le pnlView qui s'agrandit, qu'il y ait commentaire ou pas.



Fais attention, les tapis sont traîtres, en ce moment ! Ils te sautent dans les pieds c'est terrible ! Ça doit être la chaleur,

EDIT
Test rapide :
pnlView.Height à 260
ouverture d'une image à 164 de haut (girl.gif)
260 - 164 = 96
96 / 2 = 48
et une copie d'écran montre deux bandes blanches de 49 px de haut.

Il est là le souci (mais je ne sais pas où c'est calculé, et je n'ai pas le temps c't'aprème).

PS : dans le FormCreate,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
  With GifViewer do
  Begin
    Parent := pnlView;
    Align := alClient;
//    Top := 10; // commenté car sert à rien si alClient
//    Left := 10; // commenté car sert à rien si alClient
    Center := True;
//    AutoSize := true; // commenté --> pas vu de diff. Sert à quoi, ce truc ?

/EDIT

Tu remarqueras que sur cette animation (générée avec commentaire, si tu veux la tester) la taille de la fiche est un poil plus haute et il y a un bouton "test" qui est apparu : je voulais voir comment réagissait ton TFastBitmap avec un .bmp mal formé, et la conclusion que j'en tire est la suivante : à gauche avec un TBitmap, à droite avec ton TFastbimap (qui "rend" comme un TLazInftImage), en bas au milieu le viewer de Linux.


J'avais déjà travaillé avec ce fichier qui vient du forum Delphi, où je m'étais arraché les cheveux.

La grande question est : est-ce que je continue à polluer ce post avec ce sujet qui dérive, ou est-ce que j'en ouvre un autre, qui pourrait s'appeler "Comment travailler avec un bmp mal formé, si on ne le sait pas" -- car là, je m'en doute puisque je peux le comparer avec le rendu Linux, mais IRL ?

[BeanzMaster]

Salut

Salut,

me voilà de retour, je vois le bout du tunnel avec la pompe : après avoir changé la pompe entière et le clapet anti-retour, ça serait malheureux ! Reste un souci avec la pompe électrique...

J'ai refait ton test et chez moi ça se comporte comme déjà signalé : c'est le pnlView qui s'agrandit, qu'il y ait commentaire ou pas.

Il est là le souci (mais je ne sais pas où c'est calculé, et je n'ai pas le temps c't'aprème).

J'ai trouvé le problème si tu commentes dans FormDropFiles les lignes des Labels :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
Procedure TMainForm.FormDropFiles(Sender: TObject; Const FileNames: Array Of String);
var
   ImageFileName : String;
   i: integer;
Begin
    Try
      GIFLoaded := False;
      Screen.Cursor := crHourGlass;
      ImageFileName := '';
      ImageFileName := FileNames[0];
      GifViewer.LoadFromFile(ImageFileName);
      //lblFileName.Caption := MiniMizeName(ImageFileName, lblFileName.Canvas ,lblFileName.ClientWidth);
      //lblVersion.Caption := GifViewer.Version;
      //lblFrameCount.Caption := IntToStr(GifViewer.FrameCount);
      pnlAnimationPlayer.Enabled := (GifViewer.FrameCount>1);
      pnlSelectFrame.Enabled := (GifViewer.FrameCount>1);
      edtViewFrameIndex.MaxValue := GifViewer.FrameCount-1;
      //edtViewFrameIndex.Value := 0;
      //lblCurrentFrame.Caption := '1';
      //lblTotalFrame.Caption := IntToStr(GifViewer.FrameCount);
      GIFLoaded := True;
      mmoComments.Lines.Clear;
      for i:=0 to GifViewer.FrameCount-1 do
      begin
        mmoComments.Lines.AddStrings(GifViewer.RawFrames[i].Comment);
      End;
    Finally
      Screen.Cursor := crDefault;
    End;
end

;

Ce comportement disparait. Pour l'éviter il faut agrandir les TPanel (1,2,3,4,5,6,7) en hauteur de quelques pixels pour que ce truc vaudou disparaisse

EDIT : Petite rectification le panel4 avait sa propriété autosize à True, ce qui provoquai ce comportement (sources mise à jour)

Tu remarqueras que sur cette animation (générée avec commentaire, si tu veux la tester) la taille de la fiche est un poil plus haute et il y a un bouton "test" qui est apparu : je voulais voir comment réagissait ton TFastBitmap avec un .bmp mal formé, et la conclusion que j'en tire est la suivante : à gauche avec un TBitmap, à droite avec ton TFastbimap (qui "rend" comme un TLazInftImage), en bas au milieu le viewer de Linux.

J'avais déjà travaillé avec ce fichier qui vient du forum Delphi, où je m'étais arraché les cheveux.

La grande question est : est-ce que je continue à polluer ce post avec ce sujet qui dérive, ou est-ce que j'en ouvre un autre, qui pourrait s'appeler "Comment travailler avec un bmp mal formé, si on ne le sait pas" -- car là, je m'en doute puisque je peux le comparer avec le rendu Linux, mais IRL ?

Ouvres un autre topics pour les bmp.
Je ne sais pas comment tu charges les BMP, mais il faut que tu fasses attention à l'ordre des composantes de couleur. Dans les fichiers BMP les couleurs sont codée au format BGR TFastBitmap sous linux est au format RGBA. Il faut donc inverser le Rouge et Bleu (procedure SwapRB) ou le faire dans ta procédure de chargement. Note le bmp que tu nous montre "FondRVB.Bmp" n'est pas mal formé c'est Lazarus qui le lit mal. Et comme je te l'ai dis jette un oeil dans BZImageFileBMP.pas que je t'ai passé. Je l'ai justement blindé de commentaires parce que j'en ai ch.... Tu y trouveras plein d'informations qui t'aideront, j'en suis sure avec ce format qui semble pourtant facile à prendre en charge. Il reste encore quelques erreurs notamment avec la compression RLE dans certain cas ou je ne gère pas les erreurs d'encodage correctement et quelques couleurs que je n'ai pas inversé (surtout les bmp os22x 8bits)

Si tu veux des BMP bizarres et hors normes à tester : https://github.com/jdelauney/BMP-ImageTestSuite

A+

[Jipété]

J'ai trouvé le problème si tu commentes dans FormDropFiles les lignes des Labels :

Ce comportement disparait. Pour l'éviter il faut agrandir les TPanel (1,2,3,4,5,6,7) en hauteur de quelques pixels pour que ce truc vaudou disparaisse

EDIT : Petite rectification le panel4 avait sa propriété autosize à True, ce qui provoquai ce comportement (sources mise à jour)

Bonsoir,

j'ai lu (sans mettre en œuvre) tes histoires avec les labels, j'ai trouvé ça tellement loufoque et barjot que j'ai regardé d'un peu plus près le comportement de cette ihm perturbée -- et perturbante !
Et j'ai bossé une grosse heure sur ce qui suit sans avoir vu/lu la soluce du panel4 que je viens de mettre en application après tout ce qui suit :

Sur l'image ci-dessous on voit l'ihm en mode construction à gauche et l'exécution après chargement de la girl, j'ai fait afficher la hauteur du pnlView que j'avais défini à 260.


Conclusion, puisqu'il est alClient : ce qui est dessous (en alBottom) descend, et ça concerne le gbxComments.
Pourquoi descend-il ? Mystère... Bug ? Why not.
En attendant, j'ai changé le ParentFont de False à True partout où c'était nécessaire (les labels lblxxxxxx entre autres, mais peut-être d'autres compos, à vérifier), et j'ai passé la police de la fiche à Liberation Sans, n'ayant pas Verdana sous Linux.

Enfin, j'ai passé l'alignement de pnlView de alClient à alTop, et gbxComments de alBottom à alClient : ça a apporté du mieux.
Je pense qu'il faudrait mettre les 3 objets du bas dans 1 panel container, auquel cas on aurait :
panel1 alTop en haut
pnlview alClient au milieu
pnlcontainer alTop en bas contenant gbxComments alTop, panel4 alClient et panel2 alBottom.

Mais la manip du panel4 a été très efficace, bien vu !
+++
Autre chose : dans uGifViewer Function TGIFViewer.DestRect: TRect; j'ai trouvé des choses qui m'ont interpellé :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
  If FCenter Then
  Begin
    If FBorderShow Then
    Begin
//      Result.Left   := n + ((ClientWidth-(n*2)) Div 2) - (PicWidth Div 2);
//      Result.Top    := n + ((ClientHeight-(n*2)) Div 2) - (PicHeight Div 2);
      Result.Left   := n + ((ClientWidth -(n*2))  - PicWidth)  div 2; // il faudrait peut-être inclure "n +" dans la parenthèse, je te laisse voir
      Result.Top    := n + ((ClientHeight-(n*2))  - PicHeight) div 2; // idem
    end
    else
    begin
//      Result.Left   := (ClientWidth Div 2) - (PicWidth Div 2);
//      Result.Top    := (ClientHeight Div 2) - (PicHeight Div 2);
      Result.Left   := ((ClientWidth  - PicWidth)  Div 2);
      Result.Top    := ((ClientHeight - PicHeight) Div 2); 
    end;

Pourquoi ? Parce qu'imaginons 5 et 7 : 5 div 2 ça fait 2 et 7 div 2 ça fait 3 et 2 + 3 = 5 alors que (5 + 7) div 2 ça fait 6. Tu vois le truc ?

C'est tout pour le moment.
La suite à demain,

[BeanzMaster]

Salut

En attendant, j'ai changé le ParentFont de False à True partout où c'était nécessaire (les labels lblxxxxxx entre autres, mais peut-être d'autres compos, à vérifier), et j'ai passé la police de la fiche à Liberation Sans, n'ayant pas Verdana sous Linux.

Ben alors ça je m'y attendais pas j'étais persuadé que Verdana était disponible sous tous les OS. Arial je peux comprendre, mais là que tu ne dispose pas de Verdana sur ton Linux me laisse sans voix. Donc une question, qu'elle police est présente sur les trois systèmes que sont Linux, Windows et mac OS par défaut ? Car c'est génant du coup pour faire de la "cross-compilation" et obtenir une IHM identique sur les trois.

Autre chose : dans uGifViewer Function TGIFViewer.DestRect: TRect; j'ai trouvé des choses qui m'ont interpellé :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
  If FCenter Then
  Begin
    If FBorderShow Then
    Begin
//      Result.Left   := n + ((ClientWidth-(n*2)) Div 2) - (PicWidth Div 2);
//      Result.Top    := n + ((ClientHeight-(n*2)) Div 2) - (PicHeight Div 2);
      Result.Left   := n + ((ClientWidth -(n*2))  - PicWidth)  div 2; // il faudrait peut-être inclure "n +" dans la parenthèse, je te laisse voir
      Result.Top    := n + ((ClientHeight-(n*2))  - PicHeight) div 2; // idem
    end
    else
    begin
//      Result.Left   := (ClientWidth Div 2) - (PicWidth Div 2);
//      Result.Top    := (ClientHeight Div 2) - (PicHeight Div 2);
      Result.Left   := ((ClientWidth  - PicWidth)  Div 2);
      Result.Top    := ((ClientHeight - PicHeight) Div 2); 
    end;

Pourquoi ? Parce qu'imaginons 5 et 7 : 5 div 2 ça fait 2 et 7 div 2 ça fait 3 et 2 + 3 = 5 alors que (5 + 7) div 2 ça fait 6. Tu vois le truc ?

C'est tout pour le moment.
La suite à demain,

Effectivement ce sont des optimisations que je n'ai pas faites. Pour ce qui est du "n+" non il faut le laisser à l'extérieur de la parenthèse car il correspond à la largeur de la bordure. Si non le gif serait affiché par dessus.
Pour allez encore un peu plus loin dans l'optimisation on peux faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
If FBorderShow Then
    Begin
      Result.Left   := n + ((ClientWidth -(n+n))  - PicWidth)  shr 1;
      Result.Top    := n + ((ClientHeight-(n+n))  - PicHeight) shr 1;
    end
    else
    begin
      Result.Left   := ((ClientWidth  - PicWidth) shr 1);
      Result.Top    := ((ClientHeight - PicHeight) shr 1);
    end;

On pourrait même rajouter un variable et calculer qu'une seule fois "n+n" mais bon c'est insignifiant une opération en plus ici.

Merci

[inforock]

Bonsoir,

j'ai passé la police de la fiche à Liberation Sans, n'ayant pas Verdana sous Linux.

C'est quelle version de Linux ? Je suis sur Ubuntu 16.04 LTS et j'ai la police Verdana que je retrouve et peux utiliser dans Lazarus.

Cela signifierait donc que suivant les distributions de Linux, il n'y a pas les mêmes polices installées par défaut (je n'ai pas rajouté de polices par rapport à celles installées avec le système) ?

J'en profite pour dire que je suis avec attention tous les échanges qui sont passionnants et supers intéressants. Merci.

Cdt

Laurent

[BeanzMaster]

Bonsoir Laurent

Bonsoir,
Cela signifierait donc que suivant les distributions de Linux, il n'y a pas les mêmes polices installées par défaut (je n'ai pas rajouté de polices par rapport à celles installées avec le système) ?

Oui en effet, j'ai fait quelques recherches, je suis tombé sur ce site qui date de 2009 quand même et celui-ci. Linux est le parent pauvre pour les polices. Néanmoins d'après ce que j'ai pu remarqué avec les distributions actuelles, elle contiennent presque toutes Verdana à contrario Arial est de plus en plus délaissée. C'est quand même dommage de ne pas avoir de polices communes par défaut. J'image un écrivain se servant de OpenOffice ou autre et qui jongle entre plusieurs systèmes. Cela peux devenir contraignant, à moins de s'assurer et le cas échéant d'installer soit même les polices.

Pour la réalisation d'applications (non consoles) devant tourner sous plusieurs OS, il va falloir ruser et ou pré-installer les polices adéquates.

J'en profite pour dire que je suis avec attention tous les échanges qui sont passionnants et supers intéressants. Merci.

Cdt

Laurent

Content que tu trouves nos discussions intéressante N'hésites pas à toi aussi participer, questions suggestions ou autres, même si cela te parait bête. Ces colonnes sont ouvert à tous et tout le monde est le bienvenue

A+

[Jipété]

Bonsoir,

D'abord une grande et bonne nouvelle : la pompe a repris du service !

Ensuite, pour répondre à la question de Laurent,

C'est quelle version de Linux ? Je suis sur Ubuntu 16.04 LTS et j'ai la police Verdana que je retrouve et peux utiliser dans Lazarus.

je suis sous un vieux Debian 7 et Lxde, et LO m'a installé tout une tripotée de polices dont la famille Libération.
Et comme j'ai il y a qq mois bossé avec une copine sur un livre qu'elle avait en chantier sous Windows, ne voulant pas d'embrouilles de compatibilité, j'ai installé dans mon Linux les fichiers Arial.ttf, je vous laisse juger du résultat, ici en taille 18 (pour moi c'est quasiment similaire, quasiment car remarquez la taille du blanc entre le "i" et le "g" ou le "t", il n'est pas identique mais au final les mots semblent avoir la même longueur) :


Enfin, concernant les optimisations, souviens-toi, Jérome, que "le mieux est l'ennemi du bien" :

Pour allez encore un peu plus loin dans l'optimisation on peux faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
If FBorderShow Then
    Begin
      Result.Left   := n + ((ClientWidth -(n+n))  - PicWidth)  shr 1;
      Result.Top    := n + ((ClientHeight-(n+n))  - PicHeight) shr 1;
    end
    else
    begin
      Result.Left   := ((ClientWidth  - PicWidth) shr 1);
      Result.Top    := ((ClientHeight - PicHeight) shr 1);
    end;

ce que tu proposes, ce n'est pas de l'optimisation, c'est de l'offuscation : il n'y a rien de moins mnémotechnique que ces shl / shr, qui m'obligent à réfléchir et à compter sur mes doigts alors qu'un simple div x est instantanément compris.
Et si l'on considère que le compilateur va probablement générer le même code machine (à vérifier, mais je ne sais pas comment), je dirais que c'est plus une embrouille qu'autre chose, àmha.

D'ailleurs, j'avais trouvé il y a quelques semaines, dans le projet espagnol une ligne de code vers la ligne 1015 commentée utilisant un [EDIT] shl 1 shr 1 [/EDIT] et juste dessous et active la même ligne avec un div 2 bien plus lisible, y a pas photo !

[BeanzMaster]

Salut

Bonsoir,

D'abord une grande et bonne nouvelle : la pompe a repris du service !

C'est ton gazon et tes plantes qui doivent être content ! à moins que tu parlais de pompe à bière !!! je sais plus.....

Enfin, concernant les optimisations, souviens-toi, Jérome, que "le mieux est l'ennemi du bien" :

C'est vrai mais.....

ce que tu proposes, ce n'est pas de l'optimisation, c'est de l'offuscation : il n'y a rien de moins mnémotechnique que ces shl / shr, qui m'obligent à réfléchir et à compter sur mes doigts alors qu'un simple div x est instantanément compris.
Et si l'on considère que le compilateur va probablement générer le même code machine (à vérifier, mais je ne sais pas comment), je dirais que c'est plus une embrouille qu'autre chose, àmha.

Pour le CPU SHR et DIV sont 2 instructions différentes. "SHR 1" est beaucoup plus rapide que "DIV 2" le temps de latence est beaucoup plus élévé pour "DIV" (http://www.agner.org/optimize/instruction_tables.pdf et pour plus d'informations sur les CPUs la bible Intel : https://software.intel.com/en-us/articles/intel-sdm)
Le compilateur ne va pas faire la conversion automatiquement car c'est une instruction du microprocesseur DIV 2 ne sera probablement pas changer en SHR 1 lors de la compilation.

Ensuite ce qu'il faut retenir avec SHR/SHL, c'est qu'ils fonctionnent par puissance de deux. SHR divise et SHL multiplie Exemple : SHR 1 = DIV 2, SHR 2 = DIV 4, SHR 3 = DIV 8, SHR 4 = DIV 16, SHR 5 = DIV 32, SHR 6 = DIV 64, SHR 7 = DIV 128, SHR 8 = 256 ect....

Par exemple pour rester dans le graphisme si je prend le bout de code ci-dessous qui fait la moyenne de 4 pixels (un petit effet d'"antialisaing" vite fait) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
  DstColor.Red := (AColor0.Red + AColor2.Red + AColor.Red + AColor1.Red) Shr 2;
 DstColor.Green := (AColor0.Green + AColor2.Green + AColor.Green + AColor1.Green) Shr 2;
 DstColor.Blue := (AColor0.Blue + AColor2.Blue + AColor.Blue + AColor1.Blue) Shr 2;

Si tu doit répéter ce code sur une image (donc pour chaque pixel) ou pire dans une animation et appliquer ce filtre avant d'afficher ton image. Si tu utilise "DIV 4" à la place de "SHR 2" tu va vite sentir la différence et voire les performance dégringolées. Cette optimisation n'est pas du tout anodine et peut vraiment faire de grosses différences avec certain algorithme et suivant la taille des images à traiter.

EDIT : c'est valable également pour le "n+n" au lieu de "n*2". L'addition est traité beaucoup plus rapidement que la multiplication par le cpu.

Par contre je suis d'accord ça oblige à réfléchir un peu plus. Faut juste penser en puissance de deux, ce qui n'est pas très compliquer au final (enfin, pour moi).
L'ajout d'un commentaire est surement de bon aloi pour la compréhension.

D'ailleurs, j'avais trouvé il y a quelques semaines, soit dans le projet espagnol soit dans le compo TGifAnim une ligne de code commentée utilisant un shl 1 et juste dessous et active la même ligne avec un div 2 bien plus lisible, y a pas photo !

Là c'est lui qui c'est pris les pied dans le tapis SHL multiplie, il ne divise pas

[Jipété]

C'est ton gazon et tes plantes qui doivent être content ! à moins que tu parlais de pompe à bière !!! je sais plus.....

Vi, c'est les plantes qui sont contentes (et je ne bois jamais de bière)

Pour le CPU SHR et DIV sont 2 instructions différentes. "SHR 1" est beaucoup plus rapide que "DIV 2" le temps de latence est beaucoup plus élévé pour "DIV" (http://www.agner.org/optimize/instruction_tables.pdf et pour plus d'informations sur les CPUs la bible Intel : https://software.intel.com/en-us/articles/intel-sdm)

Et tu as lu tout ça ?
Les 352 pages du 1^er lien ? Fouhh, quel courage.
(et les commentaires du lien Intel m'ont bien fait rire : on peut être un bon fabricant de µproc mais un très mauvais communicant -- surtout quand on voit toutes ces petites photos de gens très heureux de leur vie, communication institutionnelle banalisée et horripilante, à force : on voit les mêmes partout).

Le compilateur ne va pas faire la conversion automatiquement car c'est une instruction du microprocesseur ; DIV 2 ne sera probablement pas changé en SHR 1 lors de la compilation.

Alors, à quoi servent toutes ces options d'optimisations sur la page Projet / Options du projet / Options du compilateur / Compilation et édition de liens ?

Ensuite ce qu'il faut retenir avec SHR/SHL, c'est qu'ils fonctionnent par puissance de deux. SHR divise et SHL multiplie Exemple : SHR 1 = DIV 2, SHR 2 = DIV 4, SHR 3 = DIV 8, SHR 4 = DIV 16, SHR 5 = DIV 32, SHR 6 = DIV 64, SHR 7 = DIV 128, SHR 8 = DIV 256, etc.

Ce qui fait que si on doit diviser par 3 on est marron,

Là c'est lui qui c'est pris les pied dans le tapis SHL multiplie, il ne divise pas

Non c'est moi : écrit hier soir de tête et sans aller voir le code d'origine, et comme ce n'est pas facilement mémorisable pour moi, bin... paf !
J'ai corrigé le post concerné.

Merci pour toutes ces précisions, je vais me faire un pense-bête,

[BeanzMaster]

Vi, c'est les plantes qui sont contentes (et je ne bois jamais de bière)


Et tu as lu tout ça ?
Les 352 pages du 1^er lien ? Fouhh, quel courage.
(et les commentaires du lien Intel m'ont bien fait rire : on peut être un bon fabricant de µproc mais un très mauvais communicant -- surtout quand on voit toutes ces petites photos de gens très heureux de leur vie, communication institutionnelle banalisée et horripilante, à force : on voit les mêmes partout).

Presque tout lu, quand j'ai bossé sur ma bibliothèques sur les vecteurs optimisée avec les instructions SIMD SSE/AVX

Alors, à quoi servent toutes ces options d'optimisations sur la page Projet / Options du projet / Options du compilateur / Compilation et édition de liens ?

Les optimisations se concentrent principalement sur les boucles et la vectorisation du code en générant des instructions SIMD principalement. De plus si tu travail avec des réel (Single/Double) les instructions SHR/SHL ne peuvent pas être employés. Ce sont également des mots clefs comme les opérateurs logiques AND, NOT, OR, XOR. Ils sont traduit en langage machine tel quel.

Ce qui fait que si on doit diviser par 3 on est marron,

Et oui SHR/SHL ne peuvent pas être employé partout.

[BeanzMaster]

Bonjour à tous, je vous notifie que les sources de TGifViewer ont été mises à jour.

Des modifications mineurs qui concernaient des fuites de mémoire ont été corrigées.

Vous pouvez télécharger ce composant dans la section de téléchargement de Lazarus
ou sur Github

TGifViewer est également installable directement depuis Online Package Manager (Gestionnaire de paquets en ligne) de Lazarus



N'hésitez pas à évaluer ce composant sur github et dans OPM

Merci d'avance

Cordialement

Jérôme