[Pdmtl] encore la valise
Mathieu Bouchard
matju at artengine.ca
Fri Jan 29 11:20:45 EST 2010
On Fri, 29 Jan 2010, Jérôme Abel wrote:
> Pour l'instant, il y en aurait 4 :
> - les sliders
> - les arrays
> - les canvas => pas testé, je viens d'y penser.
> - GEM => pas testé.
aussi PDP et GridFlow.
Pour GridFlow, c'est facile, tu prends une liste de 16 entiers et tu fais
|
| [loadbang]
| |
| [#for 0 128 1]
| |
[#outer <]
|
[# * (255 255 255)]
|
[#out window]
et ça te donne une image de 16 rangées de 128 colonnes.
cela dit, GridFlow est beaucoup plus stable maintenant qu'avant mai 2008
(0.9.2).
> Résultats de ces tests : - A partir de 4 ou 5 visualisations actives
> dans les 2 tests, rien ne va plus !! Sans compter que l'on aimerait bien
> un affichage plus grand ! - Le CPU interne dans Pd n'est pas utile ici,
> chez moi il n'indique aucune saturation de performances, alors que
> l'affichage est complètement saccadé.
Mais que dit la commande "top" ?
Dans Pd, il y a deux processus différents qui prennent du CPU : le client
et le serveur. Celui mesuré par [cputime] est le serveur. Le client
s'occupe d'affichage à l'utilisateur. C'est une bonne chose quand on a
deux CPU, parce qu'alors, le client et le serveur peuvent rouler sur des
CPU différents.
La partie client de Pd a la mauvaise habitude de trop redessiner de choses
pour rien et de prendre trop de temps pour le faire.
> Si ce n'est pas possible : - se mettre à développer un objet en C ou C++
> avec Flext ? Est-ce que ça changerait ça changerait quelque chose ?
Cette classe d'objet afficherait comment ? Le problème est dans la manière
d'afficher. Le canevas de Tk est notoirement lent.
_ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
More information about the Pdmtl
mailing list