Questions concernant les attributs

[loic]

Bonjour,

D'après ce que j'ai pu voir dans le code, les attributs des objets graphiques sont codées sur 32 bits.

Première question: Les 16 derniers bits sont dévolues à coder la couleur.

j'ai essayé de voir un peu comment retrouver ensuite cette couleur mais je n'y arrive pas.
De ce que j'ai compris:
** Entre 0 et 255: Couleurs de la palette graphique.
0 -> Noir
1 -> vert
etc
7 -> blanc
Comment retrouver le code rgb à partir du numéro?

** entre 256 et 381: couleur de l'arc en ciel
C'est la fonction arc_en_ciel(intk, int r, int g, int b) qui sert à la retranscription rgb dans ce cas

** un dernier truc que je n'ai surement pas compris: pourquoi utiliser 16 bits si on ne dépasse pas l'entier 381? (2^9=512...)

Deuxième question:

Code : Tout sélectionner

segment(point(1+i),point(2+3*i),affichage=line_width_8+cap_round_line)

Quand je teste avec Qtgiac, le gen rendu ne contient pas les paramètres de style... ça vient de moi?

Merci d'avance des réponses

Loïc

[parisse]

alors, pour la 1ere question, la couleur est codee sur 16 bits, mais FLTK ne reconnait que 8 bits dans sa palette predefinies, j'utilise donc 8 bits pour cette palette et on a ajoute une centaine de couleurs de l'arc en ciel en definissant nous-meme des couleurs (la fonction arc_en_ciel permet de connaitre les composantes r,g,b de ces couleurs). Les autres codes couleurs ne marchent pas en 2d car non predefinies (par contre elles le sont en mode 3-d). Tout ca n'est pas tres coherent, ce serait peut-etre l'occasion de remettre a plat, des suggestions?
Pour la 2eme question, le probleme vient sans doute de affichage qui n'est reconnu qu'en localisation francaise, essayez avec display.

[loic]

Effectivement, c'était display qu'il fallait utiliser.

Sinon, pour un système plus cohérent en 2D, la première idée qui me vient serait de décomposer en 4x4 bits (r,g,b,alpha)
Ca ferait un codage en multiple de 16 pour les 4 composantes ce qui me parait largement suffiant d'un point de vue de la précision.

Qu'en pensez-vous?

[parisse]

Bonne idée, reste la compatibilité avec les couleurs actuelles (FLTK<256 et arc en ciel), on pourrait peut-être coder le canal alpha sur 3 bits lorsque la couleur est <512. On mettrait donc alpha pour les bits 15-12 (bit15=0 cas particulier) et rgb pour les autres.

[loic]

Je dois vous avouer que j'ai bien avancé dans la version Qt pour le support de la géométrie 2D (pas encore tout commité, cela commence vraiment à ressembler à qq chose, je vous tiendrai au courant)

J'avais codé la couleur sur les 16 bits selon mon modèle rompant ainsi la compatibilité avec XCAS.

Ne serait-il pas possible dans XCAS de proposer en plus la possibilité de spécifier une couleur avec (r,g,b) ou (r,g,b,a). Par exemple:

Code : Tout sélectionner

A:=point(1+i,display=(245,156,24,120)+point_losange)

Ensuite, pour coder la couleur, on récupère juste le quotient de 245, 156, 24 et 120 par 16 que l'on stocke dans l'ordre sur les bits 1 à 16

Est-ce une mauvaise idée?

PS: sinon, je n'ai toujours pas compris comment retranscrire en rgb les couleurs de 1 à 256 dans XCAS. Une petite idée?

[parisse]

Bon, ce n'est peut-etre pas grave si la compatibilite est rompue, du moment qu'on a au moins les noms de couleur qui marchent (et ca on peut le changer dans giac), je demanderai a Renee. Pour les couleurs de 8 a 255 de FLTK, je n'ai aucune idee de comment c'est code...

[loic]

ça serait cool en effet que je sache comment fonctionne cette transcription ....

Autre petite question:

Lorsqu'on trace une courbe ou un polygone (ouvert ou non), les points rconcernés sont stockés dans un GROUP_VECT.
Malheureusement, à la réinterprétation du gen, il n'est plus possible de distinguer une courbe (d'ailleurs éventuellement tracée avec un petit nstep) d'une figure géométrique style polygone.

Serait-il possible de créer un nouveau sous type de vecteur afin que l'on puisse dissocier les deux?

J'avais éventuellemnt eu l'idée de tester si le premier point et le dernier du vecteur correspondent mais cela ne me parait pas très fiable...

[parisse]

il y a quand meme une difference, une courbe est normalement dans un symbolic de sommet at_curve.

[loic]

oups, j'avais pas bien étudié le problème en effet. Merci de cette remarque!

Concernant le placement des légendes: petite incompréhension encore

Dans dispatch.h:

Code : Tout sélectionner

 _QUADRANT1 = 0,
 _QUADRANT2 = 1 << 28,
 _QUADRANT3 = 1 << 29,
 _QUADRANT4 = 805306368,

j'ai essayé successivement point(1+i, display=quadrant1) puis quadrant2 , quadrant3 et quadrant4.

Dans le INT qui contient les styles, voici ce que giac me sort:

quadrant1: 2^29
quadrant2: 2^28+2^29
quadrant3: 2^30
quadrant4: 2^28+2^30
Il me semblait que le quadrant était codé sur les bits 29 et 30 de l'entier donc là, je comprends plus la logique...

[loic]

Concernant la transcirption des couleurs entre 0 et 255, je l'ai trouvé ds le source de fltk.
Donc, une chose de moins à retrouver.

Modèle potentiel:

Les 12 bits de poids faibles représente r,g,b (4 pour chaque)
Il reste 4 bits de poids forts:
** Les 3 dernières de ce paquet représente la transparence (les valeurs seront donc espacées tous les 32)
** pour le bit de poids fort:
- s'il vaut 0, on est en codage rgb
- s'il vaut 1: on est en codage type fltk et seules les 9 bits sur 16 de poids faibles sont considérés.

Votre avis?

[parisse]

Pourquoi ne pas mettre plutot le bit de poids fort a 0 pour codage fltk et 1 pour codage rgb? ca serait plus compatible.
Pour les attributs des points, il y a un probleme parce que j'ai change le quadrant par defaut. Essayez avec des droites plutot.

[loic]

oui, bien sûr, c'est plus logique comme cela avec le bit de poids fort à 1 pour le rgb.

Pour les attributs des points, il y a un probleme parce que j'ai change le quadrant par defaut.

Vous pouvez m'en dire plus?


Est-ce que la librairie qtgiac dont je dispose est la dernière en date ou y a-t-il eu des évolutions depuis?

[parisse]

je n'ai pas mis a jour les sources de giac dans qtgiac, elle est donc un peu a la traine sur la version 0.9.7, je compte la mettre a jour prochainement.
C'est pour ca qu'il vaut mieux faire les tests sur les attributs avec les droite en attendant...

[loic]

Ok, merci en tout cas pour la mise à jour.

Si ça vous intéresse, j'ai déjà intégré les fichiers de qtgiac à mon dépôt Git sur tuxfamily donc, je peux vous rajouter au projet et vous pourrez travailler firectement avec Git, cela pourrait être plus simple, non?

[parisse]

ben ce qu'il faudrait faire a mon avis, c'est avoir un repertoire central pour le source de giac qui puisse mettre a jour automatiquement tous les autres projets, xcas, qtgiac, androcas, qcas, ...
Il faut donc qu'on reflechisse a une architecture commune a tous ces projets (et je pense que ce serait bien vu ici que ca soit heberge par mon labo, il faut que je demande a notre sysadmin s'il peut mettre en place ca, et qu'on voit si on utilise git ou svn, perso je n'ai jamais utilise git, seulement svn).