[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