Une bibliothèque graphique puissante et pourtant simple d'utilisation - Page 9

J'ai pas l'impression que c'est ce qu'il voulait dire.

Voici comment je fais. Pour l'expliquer, rien ne vaut une mise en situation :
- l'utilisateur appelle la fonction pour afficher le buffer de travail
- la fonction regarde si depuis l'appel précédent, il s'est bien écoulé 2 __switch_cnt
- oui ? on échange les pointeurs !
- non ? on n'échange pas


C'est tout con ! j'ai pas encore essayé mais y'a pas de raison que ça déconne

Thibaut a écrit :
TiMad : J'y suis pour rien si tu es trop bête pour trouver une solution à ce ralentissement dû à la synchro. Allez je suis gentil je vais t'aider, petit Il faut penser le problème autrement : plutôt que se dire "merde la synchro oblige à attendre l'affichage de 2 plans avant d'échanger les pointeurs", il faut se dire "merde la synchro oblige à compter l'affichage de 2 plans avant d'échanger les pointeurs".

Là où il faut attendre la synchro sur HW1, c'est après l'échange des pointeurs, pas avant!

Thibaut a écrit :
J'ai pas l'impression que c'est ce qu'il voulait dire.

Voici comment je fais. Pour l'expliquer, rien ne vaut une mise en situation :
- l'utilisateur appelle la fonction pour afficher le buffer de travail
- la fonction regarde si depuis l'appel précédent, il s'est bien écoulé 2 __switch_cnt
- oui ? on échange les pointeurs !
- non ? on n'échange pas


C'est tout con ! j'ai pas encore essayé mais y'a pas de raison que ça déconne

Et c'est faux. Il faut attendre la synchro après l'échange de pointeurs et avant d'appeler une quelconque routine d'affichage sur les nouveaux plans!

En admetant qu'il faille attendre 2 switchs...
Sur Ti:

D R (12:28) Kevin Kofler: OSC2/2^11

Où OSC2 vaut:
HW1: ~680 kHz - ~770 kHz
HW2: ??? - (~520 kHz (= 2^19 Hz !)) - ???

Source: J89hw.txt

donc sur HW2:
ton swapbuffering fait du 260 Hz.
=> XCpyGPlanToLcd fait du 350 Hz (a confirmer car j'avais pas beaucoup de pile..)

Sur HW1:
ton swapbuffering fait du 725/2=362 Hz.
=> XCpyGPlanToLcd fait du 367 Hz (a confirmer car j'avais pas beaucoup de pile..)

ceci etant dit, tu as raison, puisque sur TI, on bosse en basse frequence.. donc ta methode est plus rapide (si j'ai bien compris ...)

TiMad a écrit :
donc sur HW2:
ton swapbuffering fait du 260 Hz. => XCpyGPlanToLcd fait du 350 Hz (a confirmer car j'avais pas beaucoup de pile..)

On peut supprimer l'attente des 2 switches sur HW2.

Sur HW1:
ton swapbuffering fait du 725/2=362 Hz. => XCpyGPlanToLcd fait du 367 Hz (a confirmer car j'avais pas beaucoup de pile..)

On n'est pas à 5 Hz près.

C'est pour ca que j'ai conclu que le SwapBuffering et plus rapide ...

Comment on supprime les 2 switch sur HW2
Si on les supprime ca clignotte?

TiMad a écrit :
Comment on supprime les 2 switch sur HW2

if (!_GrayIsRealHW2()) GrayWaitNSwitches(2);

Si on les supprime ca clignotte?

Ben non. Ça ne clignotait que sur HW1 quand l'attente de la synchro n'était pas là du tout!

Sur ma HW2 ca cligotait... c'est du a mon patch alors

Bizarre. Le test GraphX ne clignotait pas du tout sur HW2, que sur HW1...
Mais peut-être que lui, il attendait la synchro avant l'échange de pointeurs, alors que toi, tu ne l'attendais pas du tout...

Non !

Pour la synchro, je ne comprend pas du tout mais alors pas du tout !!! pourquoi ne faut-il pas commencer à dessiner dans le buffer qui servait avant à l'affichage tant que 2 switchs ne sont pas passés, si on a changé les pointeurs et que la routine des grays utilse ces nouveaux pointeurs, pourquoi ne peut-on plus faire ce qu'on veut dans les anciens plans ???

Thibaut a écrit :
Non !

Pour la synchro, je ne comprend pas du tout mais alors pas du tout !!! pourquoi ne faut-il pas commencer à dessiner dans le buffer qui servait avant à l'affichage tant que 2 switchs ne sont pas passés, si on a changé les pointeurs et que la routine des grays utilse ces nouveaux pointeurs, pourquoi ne peut-on plus faire ce qu'on veut dans les anciens plans ???

Parce que sur HW1, l'échange des pointeurs n'est effectif qu'après le prochain changement de plan, donc après 1 ou 2 switches selon la phase en laquelle tu te trouves (1 switch si c'est un changement L->D ou D->L, 2 switches si le premier switch est un changement D->D).

Mais t'es obligé d'attendre une synchro.. sinon etant donné que ma boucle d'affichage a un FPS superieur a ticks... c'est obligé que ca clignotte

J'ai peut-être trouvé un moyen de se passer de la synchro, faut que je teste

Non reviens sur ma position.
La methode XCpyGPlanToLCD, est la plus rapide, car elle est la plus rapide sur HW1.
Or les jeux sont synchronysés sur un int (5) et que par conséquent, la vitesse limitante est la vitesse des HW1.
=> Meme si le SwapBuffering est plus rapide sur HW2, ca sert à rien!

Nan nan avec GraphX l'affichage sera instantané, il n'y a plus la moindre attente due à la synchro

J'ai trouvé un moyen (complexe) de se passer de la synchro, enfin on s'en passe sans s'en passer c'est compliqué come je l'ai dit, j'espère arriver à coder ça ! si j'y parvient, la fonction GX_DisplayWorkBuffer rendra la main au programme appelant immédiatement sans attendre quoi que ce soit

Chaqun sa methode, de toute maniere c'est pas ce qu'il y a de capital dans une lib...
Genlib utilise cette methode, et pourtant quand j'ai fait un bench de scroll diff, elle est plus lente .

Elle fonctionne avec un "swap buffering" même sur HW1 ?

Oui. (cf SwapBuffer() de gen)

>Timad: Un programme Genlib calcule les deplacements/plein de choses pendant ce temps au lieu de compter fleurette.

ouai... elle doit s'ammuser à effacer le 'GPlan' inactif ou un truc comme ca...
Mais bon elle a pas le temps de faire grand chose..

thibaut, tu vas mettre ta fonction d'attente dans une int? si elle est assez frequente, ca ne pause pas de pb, elle gere ca automatiquement a ce moment la, et toi tu ne perds pas de temps a attendre la synchro?! Je suis a coté de la plaque?

GX_DisplayWorkBuffer changera juste dans l'int l'adresse du plan a afficher?

Le probleme c'est la synchro sur HW1 ca clignote ce qui implique qu'il faut attendre 2 / 2 switch.

Donc cela fait une difference de vitesse entre HW1 et HW2. De plus si tu essaies de calculer des tas de truc comme le dit pphd, il faut savoir que le nombre de switch est variable, il faut donc gérer 2 cas. Cela ne permet pas d'optimiser comme il le faudrait par exemple la routine de clear_buffer, ou alors par une perte de memoire non negligeable...

freka & TiMad : mais non c'est pas ça ! j'ai bien précisé que c'était compliqué ! ce que dit freka est simple Je le répète, c'est pas du tout ça, c'est plus complexe, et ça permet de n'avoir AUCUNE attente de quoi que ce soit.

Au hasard, tu modifies le count je sais plus quoi pour l'obligé à rentrer dans la bonne phase des grays....

Pas du tout. En plus ça nécessiterait une attente aussi.
C'est beaucoup plus subtile que ça


hé hé

"Parce que sur HW1, l'échange des pointeurs n'est effectif qu'après le prochain changement de plan, donc après 1 ou 2 switches selon la phase en laquelle tu te trouves (1 switch si c'est un changement L->D ou D->L, 2 switches si le premier switch est un changement D->D).
"

Je dirais:
il faut faire forcé le changement de plan...

Mais bon faudai que je regarde les sources...

Désolé, forcer le changement de plans c'est dégueulasse et en plus ça altérerait les gris : chaque plan doit apparaître un temps bien précis chaque seconde pour qu'il y ait 4 NDG sans scintillement. En forçant le swap des 2 plans, ça scintillerait énormément ! réfléchit...


Et puis merde j'arrête pas de répéter que ce n'est pas ça et... Môssieur Sabatier persite

Sacré TiMAd !

C'est quoi alors?
Parce que ça a de bonnes chances d'être faux.