ngetchx() trop lent ??? - Page 1

Pourquoi Kevin méprise-t-il tant cette fonction qui me paraît utile au point de le clamer dans la doc de tigcc en disant que c'est lent ? Pour moi, ce n'est juste qu'une boucle d'attente pour frapper une touche...

ngetchx gere aussi le link, l'apd, etc. Donc ca prend un peu de temps. Mais bof quoi.

mwé enfin il a raison, à partir du moment où elle *attend* une touche, peu importe qu'elle soit lente ou non

euh je suis pas sûr que ça gère l'APD... ?

Hum, si je me souviens bien, la fonction vertel("paus") est un ngetchx()...

Sans le faire exprès je laissais la calto tourner pendant longtemps jusqu'à ce qu'elle s'éteigne, si bien que quand je la rallumais, elle était arrêtée à un vertel("paus") ^^

[cross, je répondais à ./3]
enfin, comme tjs ça dépend de l'application... dans un certain nb de cas, ok, mais si c pour scroller dans une liste avec plein d'éléments par exemple, ça peut être utile que ça rame pas trop ^^

ça dépend ce que t'entends par ramer, mais comme le programme va, a priori, faire une grosse pause (ou bien t'appuies vraiment très vite sur le bouton ^^), le petit lag derrière a de grandes chances de ne même pas se voir

bah, ça dépend des applications... genre un viewer de texte, c même pas la peine d'envisager d'utiliser ngetchx(), à moins de défiler page par page...

bah ça dépend du viewer de texte, regarde une page de man sur pc ça passe très bien, c'est pas forcément à cause de ngetchx() qu'il va y avoir des problèmes (déjà toute la boucle d'affichage sur Ti sera très lente, ça aide pas). déjà, si tu fais un truc qui scrolle ligne par ligne plutot que pixel par pixel, ça devrait passer je pense.

je suis d'accord avec pollux, pour ce genre d'application il vaut mieux eviter ngetchx

Zephyr> ah, ils utilisent ngetchx() sur PC ? (non sérieusement je vois pas le rapport : si tu parles de la latence liée à SSH ou équivalent, ce n'est qu'une latence, mais ça ne diminue pas le nombre de pressions que tu peux faire par seconde, donc c'est pas trop gênant; sur TI, non seulement ça limite le débit, mais en plus comme le buffer clavier n'est que de 1 touche, c'est assez pénible)

pour uview, au début je scrollais ligne par ligne, en passant par OSdequeue() [donc nettement plus rapide que ngetchx()], et même ça c'était un peu trop lent... (depuis j'ai patché la routine du TIOS qui fait du debouncing pour qu'elle fasse pas tout ramer, et ça va mieux)

nan, c'est juste que c'est davantage comparable à ngetchx en tant qu'attente bloquante de touche; à moins d'y aller vraiment comme un barbare on a pas besoin de se ralentir volontairement pour ne pas dépasser le max d'appuis/seconde (enfin je sais pas comment tu lis tes textes après, mais je n'arrive pas à voir le problème de ngetchx pour lire un texte, sauf si tu comptes maintenir la touche enfoncée)

sauf si tu comptes maintenir la touche enfoncée

bien vu

>mais en plus comme le buffer clavier n'est que de 1 touche
Il n'est pas d'une touche, le buffer clavier.

Pollux :
bien vu

Bah heu désolé mais pour lire un texte c'est pas forcément normal comme action hein
Pour sauter rapidement à une autre page ok, mais là ce n'est plus le même problème, c'est simplement parcequ'il manque une fonction "prochaine page" à ton problème ^^

ben je sais pas comment tu te sers d'un viewer de texte, mais essaye de distribuer un firefox dans lequel tu désactiverais toutes les formes de défilement continu (la barre de défilement ou les flèches, et en remappant la molette sur pgup/pgdn), et on en reparle

PpHd>

heu je trouve la comparaison idiote : déjà quand je fais défiler firefox c'est avec la barre sur le coté ou la molette et non pas les flèches, et ensuite quand je lis un *texte* (sans aucune image ni rien, cad ce qui arrive quasiment toujours sous un éditeur de texte et quasiment jamais sur une page web), nan je ne maintiens jamais la touche "bas" enfoncée, c'est impossible de lire comme ça (ou alors tu lis vraiment très vite)

Ben le buffer clavier de la TI permet de sauver plusieurs touches avant d'en perdre.

qu'est-ce que tu racontes p-ê sous pedrom, mais pas sur AMS 2.05 en tout cas :
- tape For i,1,300:EndFor dans l'écran home
- appuie très vite 50 fois sur enter
- constate quand la calc n'est plus BUSY que tu n'as que 2 entrées dans l'écran home : la première pression de touche est attrapée par ngetchx(), démarre le calcul, la suivante remplit le buffer clavier (d'une touche), et toutes les suivantes sont ignorées

Pas fiable ton test. N'oublie pas qu'AMS purge le buffer clavier n'importe quand.

ben je veux bien, mais à ce moment-là la charge de preuve t'incombe, parce que moi j'ai jamais vu ce fameux buffer clavier...

Je confirme que même si théoriquement AMS permet un buffer clavier de n'importe quelle taille, sa taille est de une seule touche par défaut, et il n'est pas redimensionné par AMS (il doit être possible de faire un programme qui change ça par contre).

exactement, cela dit étant donné que l'adresse est hardcodée partout ça risque d'exiger un patch de la ROM si y a d'autres variables du TIOS qui se trouvent juste après kbd_queue (ce qui est très probable...)

l'adresse est hardcodée comment ça ? c'est pas kbd_queue() l'adresse ?

kbd_queue() je crois pas que ça soit un rom_call ou même une fonction en rom, c'est plutôt un hack genre printf (où tigcclib va chercher l'adresse dans le code de sprintf)... en tout cas si tu regardes le code de kbhit() par exemple il fait directement référence à l'adresse de la fifo clavier ^^

ok donc c pas tant un hack que ça, mais l'adresse reste hardcodée...