IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Lazarus Pascal Discussion :

Migration 32 --> 64 bits, toujours la misère [Lazarus]


Sujet :

Lazarus Pascal

  1. #1
    Expert éminent sénior
    Avatar de Jipété
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    10 700
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Juillet 2006
    Messages : 10 700
    Points : 15 043
    Points
    15 043
    Par défaut Migration 32 --> 64 bits, toujours la misère
    Bonjour,

    toujours dans la misère de la migration 32 --> 64 bits Laz 1.4.0 --> 2.0.12 FPC 2.6.2 --> 3.2.0, voilà ce que j'ai vécu ce matin tôt.

    J'ouvre un ancien projet, F9 c'est joli tout plein pour jouer avec les couleurs, bref, ça fait des années que je développe des trucs comme ça :
    Nom : f9_dans_32bits.png
Affichages : 230
Taille : 35,3 Ko

    Ce matin je passe tous les fichiers de code du projet dans la nouvelle machine, F9 et patatras :
    Nom : f9_après_copie_fics.png
Affichages : 223
Taille : 33,1 Ko

    Et je ne parle pas du RadioBox dont la Caption est barrée, on en ai déjà causé, va falloir que je déclare un bug (je ne sais pas comment, si qqun a une idée, merci).

    Il m'aura fallu un temps dément pour trouver la solution, toute simple pourtant : dans un module complémentaire où j'ai plein de routines en rapport avec le traitement des couleurs, j'étais comme ça, en 32 bits :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    interface
    uses
      LCLIntf, LCLType, // pour DrawMultiGradient
      Math,
    //  Dialogs, // showmessage
    //  ExtCtrls, // TImage
      Classes, SysUtils, Graphics;
    alors qu'il fallait être comme ça, dans la nouvelle 64 bits :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    interface
    uses
      Math,
    //  Dialogs, // showmessage
    //  ExtCtrls, // TImage
      Classes, SysUtils, Graphics,
      LCLIntf, LCLType; // pour DrawMultiGradient
    pour que tout aille bien.

    Notez-vous-le dans un coin…
    Il a à vivre sa vie comme ça et il est mûr sur ce mur se creusant la tête : peutêtre qu'il peut être sûr, etc.
    Oui, je milite pour l'orthographe et le respect du trait d'union à l'impératif.
    Après avoir posté, relisez-vous ! Et en cas d'erreur ou d'oubli, il existe un bouton « Modifier », à utiliser sans modération
    On a des lois pour protéger les remboursements aux faiseurs d’argent. On n’en a pas pour empêcher un être humain de mourir de misère.
    Mes 2 cts,
    --
    jp

  2. #2
    Expert éminent sénior
    Avatar de Jipété
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    10 700
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Juillet 2006
    Messages : 10 700
    Points : 15 043
    Points
    15 043
    Par défaut
    Bonjour,

    Citation Envoyé par Jipété Voir le message
    Et je ne parle pas du RadioBox dont la Caption est barrée, on en ai déjà causé, va falloir que je déclare un bug (je ne sais pas comment, si qqun a une idée, merci).
    Ce n'est pas un bug FP/Laz, j'en ai parlé ce matin dans le fil qui va bien, c'est un pb Linux (vraiment lassant).

    Citation Envoyé par Jipété Voir le message
    Il m'aura fallu un temps dément pour trouver la solution, toute simple pourtant : dans un module complémentaire où j'ai plein de routines en rapport avec le traitement des couleurs, j'étais comme ça, en 32 bits :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    interface
    uses
      LCLIntf, LCLType, // pour DrawMultiGradient
      Math,
    //  Dialogs, // showmessage
    //  ExtCtrls, // TImage
      Classes, SysUtils, Graphics;
    alors qu'il fallait être comme ça, dans la nouvelle 64 bits :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    interface
    uses
      Math,
    //  Dialogs, // showmessage
    //  ExtCtrls, // TImage
      Classes, SysUtils, Graphics,
      LCLIntf, LCLType; // pour DrawMultiGradient
    pour que tout aille bien.

    Notez-vous-le dans un coin…
    J'ai enlevé le car dans le même projet je fais dessiner un cercle chromatique complet (du rouge au rouge en faisant tout le tour, rouge orange jaune vert cyan bleu mauve violet, et de l'extérieur noir vers l'intérieur blanc en passant par couleur au milieu) plus l'affichage dans des panneaux des valeurs rgb et hsl décodées au passage de la souris sur le cercle.
    J'ai beaucoup souffert en son temps, mais depuis des années c'est tout bon en 32 bits.

    Je ne change rien (à part cette histoire d'emplacement de LCLType et LCLIntf dans les uses décrite ci-dessus) et ça se vautre lamentablement en 64 bits, ça en devient à pleurer à hurler à tout casser à se recycler vendeur de frites, franchement y en a marre !
    Je n'ai pas changé une virgule, rien, et les conversions rgb vers hsl foirent. Pourquoi ? Je travaille avec des byte (pour R, G et B) et des double (pour H, S et L), ça peut jouer différemment en 64 versus 32 ?
    J'ai regardé le début de graphics, de LCLType et de LCLIntf sans rien trouver.
    Je suis au désespoir, c'est totalement déprimant…

    Nom : boule_chroma.png
Affichages : 177
Taille : 80,4 Ko
    Sur cette magnifique image (un peu réduite) on voit le pointeur (mon curseur en forme de croix de viseur n'a pas été attrapé par l'outil de capture Linux, désolé) et dans les patches en haut à droite les valeurs rgb de la couleur survolée et de la couleur inversée (dans le sens où je me contente de transformer rgb en hsl puis de transformer les trois valeurs obtenues en suivant la règle if valeur < 0,5 then valeur := valeur + 0,5 else valeur := valeur - 0,5; (les valeurs varient de 0 à 1) et retransformation de ces valeurs vers rgb) et quand je fais la même chose en 64 bits il y a du flicker dans les panneaux et surtout, les valeurs opposées ne bougent pas.
    Et je rappelle que c'est strictement le même code !
    Alors comment dépanner/débogueur un code qui fonctionne bien, sauf qu'il fonctionne mal ?

    Merci pour les pistes,
    Il a à vivre sa vie comme ça et il est mûr sur ce mur se creusant la tête : peutêtre qu'il peut être sûr, etc.
    Oui, je milite pour l'orthographe et le respect du trait d'union à l'impératif.
    Après avoir posté, relisez-vous ! Et en cas d'erreur ou d'oubli, il existe un bouton « Modifier », à utiliser sans modération
    On a des lois pour protéger les remboursements aux faiseurs d’argent. On n’en a pas pour empêcher un être humain de mourir de misère.
    Mes 2 cts,
    --
    jp

  3. #3
    Expert confirmé
    Avatar de BeanzMaster
    Homme Profil pro
    Amateur Passionné
    Inscrit en
    Septembre 2015
    Messages
    1 899
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Amateur Passionné
    Secteur : Tourisme - Loisirs

    Informations forums :
    Inscription : Septembre 2015
    Messages : 1 899
    Points : 4 346
    Points
    4 346
    Billets dans le blog
    2
    Par défaut
    Salut JP, ton probleme viens surement de l'utilisation du type double, qui est different en 32bits et 64bits à la place remplace par des Single pour voir. Regardes egalement dans tes options de compilation si il n'y a pas un truc qui traine et qui pourrait engranger cette erreur


    A+ Jérôme
    • "L'Homme devrait mettre autant d'ardeur à simplifier sa vie qu'il met à la compliquer" - Henri Bergson
    • "Bien des livres auraient été plus clairs s'ils n'avaient pas voulu être si clairs" - Emmanuel Kant
    • "La simplicité est la sophistication suprême" - Léonard De Vinci
    • "Ce qui est facile à comprendre ou à faire pour toi, ne l'est pas forcément pour l'autre." - Mon pèrei

    Mes projets sur Github - Blog - Site DVP

  4. #4
    Expert éminent sénior
    Avatar de Jipété
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    10 700
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Juillet 2006
    Messages : 10 700
    Points : 15 043
    Points
    15 043
    Par défaut
    , Jérôme,
    Citation Envoyé par BeanzMaster Voir le message
    Salut JP, ton probleme vient surement de l'utilisation du type double, qui est différent en 32bits et 64bits à la place remplace par des Single pour voir.
    différent en 32bits et 64bits : comment tu sais ça, toi ? Où se trouvent les infos ? Parce que figure-toi que j'y ai bien pensé aussi, je me suis paluché l'aide en ligne (donc à jour j'ose espérer), que j'ai comparée avec mes vieilles notes 32 bits et je ne vois aucune différence entre les deux…

    Ceci étant dit, pour essayer d'avancer, j'ai créé un prog ultra simple qui reproduit à peu près ce que j'ai montré sur l'image et là, toujours en ne changeant strictement rien d'une archi à l'autre, ça fonctionne sur les deux.
    Je serais donc tenté de dire que ce n'est pas ça le problème et c'est pour ça que je m'arrache les cheveux car je ne vois pas où ça peut coincer ni quoi est concerné.

    J'en suis réduit à repartir du gros programme, le dupliquer et enlever le max de choses jusqu'à ce que le 'blème disparaisse. À suivre…

    Citation Envoyé par BeanzMaster Voir le message
    regarde également dans tes options de compilation si il n'y a pas un truc qui traîne et qui pourrait engranger cette erreur
    Rien trouvé, et si c'est pointu, je risque de ne pas savoir le trouver -- d'un autre côté, si c'est pointu, je ne l'aurais jamais mis en place, alors tout va bien de ce côté-là.

    Bon, j'y retourne une poignée d'heures et après c'est week-end, je ne pourrai rien faire.
    Il a à vivre sa vie comme ça et il est mûr sur ce mur se creusant la tête : peutêtre qu'il peut être sûr, etc.
    Oui, je milite pour l'orthographe et le respect du trait d'union à l'impératif.
    Après avoir posté, relisez-vous ! Et en cas d'erreur ou d'oubli, il existe un bouton « Modifier », à utiliser sans modération
    On a des lois pour protéger les remboursements aux faiseurs d’argent. On n’en a pas pour empêcher un être humain de mourir de misère.
    Mes 2 cts,
    --
    jp

  5. #5
    Expert éminent sénior
    Avatar de Jipété
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    10 700
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Juillet 2006
    Messages : 10 700
    Points : 15 043
    Points
    15 043
    Par défaut
    J'ai trouvé où et quoi coinçait, et ça restera un mystère insondable, pour moi : dans une unité complémentaire à mon projet, il y a plein de fonctions et procédures et plein de mes programmes y font référence, comme tout le monde je suppose, et là-dedans j'ai plein de choses trifouillant les pixels, les couleurs, etc.
    Et ça fait un paquet d'années que c'est stable et efficace.

    Il m'est arrivé parfois d'englober des petits bouts de proc's pour en faire une plus grande, genre
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    procedure ijpColorToHSL(const aColor: TColor; out H,S,L: double); inline;
    var // graphutil, c'est là que j'ai trouvé ColorToHLS (notez l'inversion L <> S), voir dessous 
      R,G,B: Byte;
    begin
      R :=  aColor and $FF;
      G := (aColor shr  8) and $FF;
      B := (aColor shr 16) and $FF;
      ijpRGBtoHSL(R,G,B, H,S,L); // vient de easyrgb.com, attend des bytes et va en sortir des doubles
    end;
    inversion S <> L car si graphutil travaille avec des bytes en sortie, comme je m'appuie beaucoup sur des codes trouvés sur easyrgb.com qui travaillent en double, ben j'ai fait mes propres procs, préfixées donc par ijp, avec i comme "inline" (qui ne fonctionne pas toujours, avec des messages pas clairs), et "jp" comme ma pomme , et l'inversion S <> L pour être sûr de ne pas m'emmêler les pinceaux

    En gros, je reprends le principe de graphutil :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    procedure ColorToHLS(const AColor: TColor; out H, L, S: Byte);
    var
      R, G, B: Byte;
      RGB: TColorRef;
    begin
      RGB := ColorToRGB(AColor);
      ExtractRGB(RGB, R,G,B); // cette proc extrait les composantes R, G et B d'un TColor
      RGBtoHLS(R,G,B, H,L,S); // et celle-la nous donne les valeurs HLS en bytes
    end;
    Tout ça n'est que du Meccano avec des lignes de code au lieu de plaques de ferraille, mais dans l'idée c'est la même chose.

    Et je ne vois absolument pas pourquoi le fait d'avoir empaqueté des petites procs dans une grosse fait que si ça continue à fonctionner dans la machine 32 bits, ça foire lamentablement dans la 64, m'obligeant à éclater la big proc en ses petits composants pour que ça daigne tomber en marche.
    Il a à vivre sa vie comme ça et il est mûr sur ce mur se creusant la tête : peutêtre qu'il peut être sûr, etc.
    Oui, je milite pour l'orthographe et le respect du trait d'union à l'impératif.
    Après avoir posté, relisez-vous ! Et en cas d'erreur ou d'oubli, il existe un bouton « Modifier », à utiliser sans modération
    On a des lois pour protéger les remboursements aux faiseurs d’argent. On n’en a pas pour empêcher un être humain de mourir de misère.
    Mes 2 cts,
    --
    jp

  6. #6
    Expert confirmé
    Avatar de anapurna
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Mai 2002
    Messages
    3 410
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Arts - Culture

    Informations forums :
    Inscription : Mai 2002
    Messages : 3 410
    Points : 5 801
    Points
    5 801
    Par défaut
    Salut

    C'est le problème de typage : avant un entier était sur 32 bits, maintenant sur 64.

    Pour éviter les problèmes de type j'ai tendance à créer les miens ; de cette manière, je les fais évoluer pour rester compatible dans le temps.
    Les exemples les plus criants étant les integer et les string.

    PS : Certaines données sont des valeurs système et dépendent donc de l'OS.
    Voici un lien super intéressant Ici.
    Nous souhaitons la vérité et nous trouvons qu'incertitude. [...]
    Nous sommes incapables de ne pas souhaiter la vérité et le bonheur, et sommes incapables ni de certitude ni de bonheur.
    Blaise Pascal
    PS : n'oubliez pas le tag

  7. #7
    Expert confirmé
    Avatar de BeanzMaster
    Homme Profil pro
    Amateur Passionné
    Inscrit en
    Septembre 2015
    Messages
    1 899
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Amateur Passionné
    Secteur : Tourisme - Loisirs

    Informations forums :
    Inscription : Septembre 2015
    Messages : 1 899
    Points : 4 346
    Points
    4 346
    Billets dans le blog
    2
    Par défaut
    Salut
    Citation Envoyé par Jipété Voir le message
    , Jérôme,

    différent en 32bits et 64bits : comment tu sais ça, toi ? Où se trouvent les infos ? Parce que figure-toi que j'y ai bien pensé aussi, je me suis paluché l'aide en ligne (donc à jour j'ose espérer), que j'ai comparée avec mes vieilles notes 32 bits et je ne vois aucune différence entre les deux…
    Oups, non c'est moi j'ai confondu avec le type Extend

    Citation Envoyé par anapurna Voir le message
    Salut

    C'est le problème de typage : avant un entier était sur 32 bits, maintenant sur 64.
    Je n'ai jamais eu ce probleme avec des entier

    https://www.freepascal.org/docs-html/ref/refsu4.html
    https://wiki.freepascal.org/Data_type
    https://wiki.freepascal.org/Variables_and_Data_Types


    L'ordre des classes dans le uses est important, comme tu l'a deja signalé. Et notamment pour LCLIntf, LCLType. Mais ce n'est pas nouveau ça. Donc attention aussi avec tes unités perso

    JP, un truc qui m'ai déja arrivé. Lorsque je lance le prog avec F9 j'ai du des fois supprimé les fichiers de sortie créés de la précédente compilation.
    Autre truc que j'ai eu lorsque je manipulait suivant le prog en le lançant depuis Lazarus celui-ci ne fonctionnait pas. La cause c'était le debugger DBG. Je faisait juste un construire et lançais le prog en dehors de Lazarus et la ca fonctionnait.

    Pour les options de compilation force le mode asm en Intel, par précaution et attention à l'options d'optimisation ne le force pas au maximum. Ensuite assure toi bien que tes progs sont en mode ObjFPC. J'ai eu des soucis en mode Delphi sous Linux.

    Si tu as encore un soucis dans le genre. Ca serait bien de nous faire un zip avec tout le code.
    A mon avis il ne doit pas y avoir grand chose à modifier pour rendre compatible tes progs à la fois en 32bit et en 64bit
    • "L'Homme devrait mettre autant d'ardeur à simplifier sa vie qu'il met à la compliquer" - Henri Bergson
    • "Bien des livres auraient été plus clairs s'ils n'avaient pas voulu être si clairs" - Emmanuel Kant
    • "La simplicité est la sophistication suprême" - Léonard De Vinci
    • "Ce qui est facile à comprendre ou à faire pour toi, ne l'est pas forcément pour l'autre." - Mon pèrei

    Mes projets sur Github - Blog - Site DVP

  8. #8
    Expert éminent sénior
    Avatar de Jipété
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    10 700
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Juillet 2006
    Messages : 10 700
    Points : 15 043
    Points
    15 043
    Par défaut
    Bonjour,

    et merci à vous pour vos retours et les liens.

    Citation Envoyé par anapurna Voir le message
    C'est le problème de typage : avant un entier était sur 32 bits, maintenant sur 64.
    Typique à Delphi, non ?


    @Jérôme :
    ce lien est le plus intéressant des trois, àmha : https://www.freepascal.org/docs-html/ref/refsu4.html
    et on y trouve
    Remark In newer Delphi versions, the longint type is platform and CPU dependent. This is not so in FPC, where longint is 32-bit on all platforms.
    Tout est dit et ça ne m'explique pas comment la pagaille a pu se produire chez moi.

    Comment j'ai fait : dans la nouvelle machine j'ai reproduit l'arborescence des dossiers contenant les .pas communs à plusieurs programmes, puis j'ai transféré certains dossiers (j'y vais petit à petit, avec cette migration : entre le passage de 32 à 64 bits, d'un proc Intel à un AMD, la disparition dans l'OS de sysVinit au profit de [cette cochonnerie de] systemd et autres bricoles, ça va bientôt faire 14 mois que la machine neuve n'est toujours pas en prod…)
    Et donc un gros dossier dont le binaire fonctionne très bien en 32 bits s'est mis à dérailler sur certains points, ceux liés aux conversions RGB --> HSL et/ou (me souviens plus très bien) HSL --> RGB, ce qui m'a psychologiquement complètement déstabilisé.
    Et en même temps que je vous raconte je réalise que je n'ai toujours pas compris qu'est-ce qui se passe au juste.
    Parce que d'autres programmes ont pu être migrés sans soucis.

    Citation Envoyé par BeanzMaster Voir le message
    Pour les options de compilation force le mode asm en Intel, par précaution et attention à l'option d'optimisation ne le force pas au maximum.
    Je ne sais pas où se cache cette option du mode asm en Intel (ou alors c'est dans Options / Options du compilateur / Analyse / Style d'assembleur ? Dans ce genre de choses je laisse "par défaut" parce que comm' d'hab' l'aide est lamentable :
    Citation Envoyé par aide minable de Lazarus 1.4
    Assembler style
    Sets the value of -R<x> option:
    -Rdefault: use default assembler
    -Ratt: use AT&T style assembler
    -Rintel: use Intel style assembler
    Nom : assembleur_style.png
Affichages : 135
Taille : 4,3 Ko
    (Si l'aide se résume à nous redire ce que nous montrent déjà les textes du radiogroup, ce n'est franchement pas la peine), et pour les options d'optimisation je n'ai jamais dépassé le niveau 2 et en français on perd un niveau : en haut l'aide qu'on trouve sur le web en cliquant sur le bouton "Aide" situé en bas à gauche de la page qui nous affiche ce qu'il y a en bas de l'image…
    Nom : optimisations.png
Affichages : 142
Taille : 15,4 Ko

    Citation Envoyé par BeanzMaster Voir le message
    Ensuite assure-toi bien que tes progs sont en mode ObjFPC. J'ai eu des soucis en mode Delphi sous Linux.
    Étant entendu que c'est parfois la misère de passer en ObjFPC, quand il faut modifier des trucs et des machins pas toujours intuitifs, pb rencontré quand on récupère un prog écrit pour Delphi au départ.

    Citation Envoyé par BeanzMaster Voir le message
    Si tu as encore un souci dans le genre, ça serait bien de nous faire un zip avec tout le code.
    C'est ce que j'avais commencé à préparer, et c'est là que je me suis rendu compte de la blagounette qui a fait disparaître le problème avec le projet minimaliste prévu pour le zip.
    Va falloir que je remette le fourbi sur l'établi, j'ai pas complètement fini les coups de lime mais là c'est week-end, donc rdv lundi !
    Il a à vivre sa vie comme ça et il est mûr sur ce mur se creusant la tête : peutêtre qu'il peut être sûr, etc.
    Oui, je milite pour l'orthographe et le respect du trait d'union à l'impératif.
    Après avoir posté, relisez-vous ! Et en cas d'erreur ou d'oubli, il existe un bouton « Modifier », à utiliser sans modération
    On a des lois pour protéger les remboursements aux faiseurs d’argent. On n’en a pas pour empêcher un être humain de mourir de misère.
    Mes 2 cts,
    --
    jp

  9. #9
    Expert éminent sénior
    Avatar de Jipété
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    10 700
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Juillet 2006
    Messages : 10 700
    Points : 15 043
    Points
    15 043
    Par défaut
    Bonjour à tous,

    Citation Envoyé par Jipété Voir le message
    Va falloir que je remette le fourbi sur l'établi, j'ai pas complètement fini les coups de lime mais là c'est week-end, donc rdv lundi !
    et donc je fais le point :
    en 32 bits, cette suite d'appels fonctionne très bien et est très fluide ("opp" pour couleur opposée) :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    begin
      CurColor := img.Canvas.Pixels[X,Y];
      ijpColorToHSL(CurColor, hopp,sopp,lopp);
      // suite du code pour l'inversion des valeurs h s l
    avec
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    procedure ijpColorToHSL(const aColor: TColor; out H,Sh,L: double); inline;
    var
      R,G,B: Byte;
    begin
      R :=  aColor and $FF;
      G := (aColor shr  8) and $FF;
      B := (aColor shr 16) and $FF;
      ijpRGBtoHSL(R,G,B, H,Sh,L); // proc compliquée venant de chez easyRGB.com
    end;
    En 64 bits la suite d'appels précédente cafouille (erreurs de couleurs, cahots au déplacement de la souris, etc.) et il me faut faire ainsi :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    begin
      CurColor := img.Canvas.Pixels[X,Y];
      RedGreenBlue(CurColor, rcur,gcur,bcur); // ajout pour 64 bits
      ijpRGBToHSL(rcur,gcur,bcur, hopp,sopp,lopp);  // OK
      //ijpColorToHSL(CurColor, hopp,sopp,lopp);  // KC !
    Le gag c'est qu'ici RedGreenBlue vient de graphics.pp et contient simplement
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    procedure RedGreenBlue(rgb: TColorRef; out Red, Green, Blue: Byte);
    begin
      Red   :=  rgb and $000000ff;
      Green := (rgb shr  8) and $000000ff;
      Blue  := (rgb shr 16) and $000000ff;
    end;
    (c'est la même chose qu'on trouve dans graphutil.pp :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    procedure ExtractRGB(RGB: TColorRef; var R, G, B: Byte); inline;
    begin
      R :=  RGB and $FF;
      G := (RGB shr  8) and $FF;
      B := (RGB shr 16) and $FF;
    end;
    ), ce qui correspond aux premières lignes de ma ijpColorToHSL.

    Donc en gros je suis obligé de dépaqueter pour 64 bits ce que j'avais pu empaqueter pour 32 bits.


    Note : on trouve ça dans graphutil.pp, pas utilisable directement car sort sur des byte au lieu de double :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    procedure ColorToHLS(const AColor: TColor; out H, L, S: Byte);
    var
      R, G, B: Byte;
      RGB: TColorRef;
    begin
      RGB := ColorToRGB(AColor);
      ExtractRGB(RGB, R, G, B);
      RGBtoHLS(R, G, B, H, L, S);
    end;
    mais c'est de ça dont je me suis inspiré.

    Pourquoi ça cafouille en 64 bits alors que les uses sont identiques restera un mystère total à dépatouiller pour les générations futures,
    Il a à vivre sa vie comme ça et il est mûr sur ce mur se creusant la tête : peutêtre qu'il peut être sûr, etc.
    Oui, je milite pour l'orthographe et le respect du trait d'union à l'impératif.
    Après avoir posté, relisez-vous ! Et en cas d'erreur ou d'oubli, il existe un bouton « Modifier », à utiliser sans modération
    On a des lois pour protéger les remboursements aux faiseurs d’argent. On n’en a pas pour empêcher un être humain de mourir de misère.
    Mes 2 cts,
    --
    jp

  10. #10
    Expert confirmé
    Avatar de BeanzMaster
    Homme Profil pro
    Amateur Passionné
    Inscrit en
    Septembre 2015
    Messages
    1 899
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Amateur Passionné
    Secteur : Tourisme - Loisirs

    Informations forums :
    Inscription : Septembre 2015
    Messages : 1 899
    Points : 4 346
    Points
    4 346
    Billets dans le blog
    2
    Par défaut
    Salut la difference c'est le TColor dans graphUtil, c'est TColorRef. Les fonctions de easyRGB.com proviennent de Delphi (et il y a longtemp) .
    L'ordre des composant n'est pas la même.
    Avant FPC 3.2.0 sous Linux le TColor sous linux l'ordre des couleurs etaient RGBA et BGRA sous Windows. Maintenant que l'on soit sous Linux ou Windows TColor est au format BGR

    Since FPC 3.2.0, Free Pascal defines TColor and TColorRec as well as the 140 standard Color names in the Delphi compatible System.UItypes unit, to allow non visual code to use the same type as visual code. Lazarus hasn't caught on yet, because the current Lazarus versions still support 3.0.x.

    In the LCL TColor is the standard color type. It is compatible with Delphi's TColor. TColor can represent either an RGB (3x8bit) value, or a system color like clDefault. The LCL can also work with the fpImage system which uses the TFPColor type (which is RGBA (4x16bit), not RGB (3x8bit) like TColor).
    https://wiki.freepascal.org/Colors

    dans FPC, TColor est en 24bits. Et par exemple clRed = TColor($0000FF). C'est pour cela que

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
      R :=  aColor and $FF;  //= $FF0000 au lieu de $0000FF
      G := (aColor shr  8) and $FF;
      B := (aColor shr 16) and $FF;
    ne peut pas fonctionner correctement tes bitMasks ne sont pas correcte

    TColorRef lui de type cardinal (32 bits) et donc au format ABGR

    J'avoue quand même que sur ce point la doc n'est pas très explicite.

    Depuis ta version 1.4 il est certain que certaine chose comme ici la gestion des couleurs du TColor a changé.

    A+
    • "L'Homme devrait mettre autant d'ardeur à simplifier sa vie qu'il met à la compliquer" - Henri Bergson
    • "Bien des livres auraient été plus clairs s'ils n'avaient pas voulu être si clairs" - Emmanuel Kant
    • "La simplicité est la sophistication suprême" - Léonard De Vinci
    • "Ce qui est facile à comprendre ou à faire pour toi, ne l'est pas forcément pour l'autre." - Mon pèrei

    Mes projets sur Github - Blog - Site DVP

  11. #11
    Expert éminent sénior
    Avatar de Jipété
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    10 700
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Juillet 2006
    Messages : 10 700
    Points : 15 043
    Points
    15 043
    Par défaut
    Bonjour Jérôme,

    et merci pour ces précisions qui me (nous !) seront d'une valeur inestimable :
    (légèrement édité pour plus de clarté)
    Citation Envoyé par BeanzMaster Voir le message
    L'ordre des composant n'est pas la même.
    Avant FPC 3.2.0 pour le TColor l'ordre des couleurs était RGB(A) sous Linux et BGR(A) sous Windows. Maintenant que l'on soit sous Linux ou Windows TColor est au format BGR
    Mais il y a un truc bizarre dans la traduc' : j'ai suivi ton lien, et on y trouve
    Citation Envoyé par english
    Overview

    Since FPC 3.2.0, Free Pascal defines TColor and TColorRec as well as the 140 standard Color names in the Delphi compatible System.UItypes unit, to allow non visual code to use the same type as visual code. Lazarus hasn't caught on yet, because the current Lazarus versions still support 3.0.x.

    In the LCL TColor is the standard color type. It is compatible with Delphi's TColor. TColor can represent either an RGB (3x8bit) value, or a system color like clDefault. The LCL can also work with the fpImage system which uses the TFPColor type (which is RGBA (4x16bit), not RGB (3x8bit) like TColor).
    Citation Envoyé par français
    Vue d'ensemble

    Dans la LCL, TColor est le type couleur standard. Il est compatible avec le TColor de Delphi. TColor peut représenter soit une valeur RGB (3x8bits), soit une couleur système comme crDefault. La LCL peut aussi travailler avec le système fpImage qui emploie le type TFPColor qui est du RGBA (4x16bits), et non du RGB (3x8bits comme TColor).
    Donc la traduc' française fait sauter le 1er § où l'on trouve notamment la phrase :
    Lazarus hasn't caught on yet, because the current Lazarus versions still support 3.0.x
    et une traduc' ggl donne
    Lazarus n'a pas encore compris, car les versions actuelles de Lazarus prennent toujours en charge 3.0.x
    On n'est pas sorti de l'auberge, àmha !

    Bonne journée,
    Il a à vivre sa vie comme ça et il est mûr sur ce mur se creusant la tête : peutêtre qu'il peut être sûr, etc.
    Oui, je milite pour l'orthographe et le respect du trait d'union à l'impératif.
    Après avoir posté, relisez-vous ! Et en cas d'erreur ou d'oubli, il existe un bouton « Modifier », à utiliser sans modération
    On a des lois pour protéger les remboursements aux faiseurs d’argent. On n’en a pas pour empêcher un être humain de mourir de misère.
    Mes 2 cts,
    --
    jp

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Migration d'une DLL Delphi 32 bits vers 64 bits
    Par pwaesely dans le forum Langage
    Réponses: 1
    Dernier message: 20/03/2009, 13h50
  2. Réponses: 2
    Dernier message: 18/04/2008, 16h26
  3. migration java 32 bits vers 64 bits
    Par patrox333 dans le forum Langage
    Réponses: 2
    Dernier message: 26/03/2008, 22h01
  4. Migration base 8.1.6 32 bit to 8.1.7.4 64 bit
    Par debutant_oracle dans le forum Installation
    Réponses: 5
    Dernier message: 28/05/2007, 16h57
  5. Migration 64 bits et strtok
    Par fffonck dans le forum C
    Réponses: 7
    Dernier message: 07/09/2006, 19h32

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo