Metafor

ULiege - Aerospace & Mechanical Engineering

User Tools

Site Tools


commit:futur:robo

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
commit:futur:robo [2017/04/05 18:36] – [Nettoyage macOS] bomancommit:futur:robo [2019/07/10 14:43] (current) boman
Line 1: Line 1:
 ====== Commit ====== ====== Commit ======
  
-===== Nettoyage VTK =====+===== VizWin/BWin Linux =====
  
-Suite à la migration VTK6, mon Metafor démarrait en plus de 6 secondes sur ma machine Ubuntu. Après une petite analyseje me suis rendu compte que toutes les libs VTK de ma machine étaient chargées en mémoire suite à une opération de link un peu brutale (je linkais avec toutes les libs, c'est-à-dire ''VTK_LIBRARIES''). Comme les libs VTK d'Ubuntu sont très complètes (toutes les options sont activées), je me retrouvais ainsi avec plus de 300 libs ''.so'' à charger au démarrage, dont certaines utilisent MPI ou d'autres libs annexes un peu lourdes..+Lorsqu'on utilise Metafor sous Linuxon se rend compte que le développement a été effectué sous Windows. Les widgets de 'BWin', par exemple, ont été dimensionnés (en dursuivant la largeur de la police de caractère de WindowsOn se retrouve alors avec des widgets "trop étroits" sous Ubuntu qui utilise une police plus large.
  
-J'ai donc pris le temps de nettoyer tout ça et de sélectionner une à une les libs VTK qu'on utilise réellement dans MetaforLe but est de linker Metafor qu'avec ce qui est réellement nécessaire.+{{:commit:2019:bwin_avant2.png?300|avant}} {{:commit:2019:bwin_apres.png?300|après}}
  
-Un seul petit problème rencontré (qui m'a pris une journée complète pour le résoudre): VTK6.2 d'Ubuntu ne charge pas correctement toutes les libs nécesaires à l'utilisation de ''vtkXYPlotActor'' et, si on ne linke pas explicitement avec ''vtkRenderingFreeType*'', on se retrouve avec une version de Metafor utilisable mais dont les fenêtres de courbes sont gelées. Est ce un bug VTK6.2 ou un bug Ubuntu, je n'en sais rien. La seule version de comparaison que j'ai est celle sous Windows linkée avec VTK7.1 et le bug n'est pas (plus?) présent.+J'ai donc passé sur tous les widgets pour effacer toutes ces tailles fixées "en dur".
  
-===== Nettoyage CMake 3.x =====+Un autre problème sous Ubuntu est l'ouverture des fenêtres 'VizWin'. Elles s'ouvrent par moment avec une taille ridicule qui correspond à la taille de la fenêtre VizWin dans le QtDesigner. Normalement VizWin doit s'afficher et se redimensionner soit à la taille par défaut, soit à la taille qui a été sauvegardée précédemment. Cette opération de redimensionnement se passe mal sur le bureau Gnome et je suspecte une interaction non voulue entre cette opération de redimensionnement et les effets de bureau de Gnome où les fenêtres n'apparaissent pas d'un seul coup. Un autre facteur qui ne vient pas aider est le fait que, dans Metafor, l'interface graphique est dans un thread séparé, piloté par le thread python via des requêtes inter-threads dont je ne connais pas les détails techniques.
  
-J'en ai profité pour gérer correctement les warnings liés aux nouvelles ''POLICY'' des CMakes récentsEn effetlorsque CMake change de comportement au cours des versions, les développeurs définissent une nouvelle ''POLICY'' qui, par défaut n'est pas définie (et produit un warning pour avertir les développeurs). Chaque policy peut valoir ''OLD'' (la valeur par défaut - mais qui traduit le "vieux" comportement qui sera supprimé plus tard) et ''NEW'' (le nouveau comportement qui nécessite peut-être une phase de debug des ''CMakeLists.txt''. J'ai donc vaillamment activé toutes les nouvelles ''POLICY'' à ''NEW'' et... pas de fumée... ça a l'air de marcher.+J'ai essayé de jouer sur plusieurs plans pour obtenir un bon redimensionnementAu finalça marche beaucoup mieux qu'avant mais ça ne marche pas toujours. J'ai donc simplement augmenté la taille de VizWin dans le QtDesigner pour que, quand ça foire, la fenêtre ne soit pas minuscule.
  
-Autre nettoyage: CMake gère maintenant de manière beaucoup plus transparente les opérations liées à ''moc'' (génération du code source supplémentaire des classes dérivées de Qt pour gérer le système de signaux/slots, pour ceux qui connaissent). J'étais passé à la nouvelle manière de traiter les mocs lors de la migration Qt5 mais cela générait des tas de warnings parce que je n'avais pas complètement supprimé l'ancienne manière de faire (il fallait supprimer tous les ''#include "machin.moc"'' qui sont maintenant vides. +===== ProjectionSelector =====
-Ce problème est maintenant corrigé.+
  
-===== Nettoyage images PNG =====+Les cas tests de redressage pour Minitubes nécessitent l'utilisation de l'ancien projection selector codé par Ludo sur base du travail de Denis Graillet. En effet, le nouvel algorithme de Gaëtan provoque des mauvaises projections qui ne sont clairement pas normales à la surface. Le problème avec l'ancien algorithme, c'est qu'il affiche, dans certains cas pathologiques, des infos pour dire qu'il ne s'en sort plus dans le choix des projections multiples et qu'il choisit alors la première. Ces infos sont tellement courantes dans les tests de redressage (2 tubes maillés qui sont en contact l'un dans l'autre), que le fichier de sortie devient énorme. 
  
-Le nouveau Qt est linké avec la toute nouvelle libpng qui détecte et signale des erreurs dans les profils de couleur sRGB de certaines images PNG. On voit ces nouveaux warnings au runtime dans la console. J'ai donc passé tous les PNG du repository à travers [[https://psydk.org/pngoptimizer?lang=fr|PngOptimizer]]. Ça a supprimé tous les warnings et, accessoirement, ça a réduit la taille de quelques uns de ces fichiers.+J'ai donc simplement supprimé l'affichage de ces warnings (ils sont connus et ne servent que si quelqu'un voulait débuguer le truc) 
  
  
-===== Nettoyage macOS ===== +===== Tabs/Espaces =====
- +
-J'ai continué la compilation [[wp>macOS]] (il parait qu'on ne dit plus "OSX", ni "Mac OS" mais "macOS") sur le mac du service nommé ''spirou''. J'arrive maintenant à tout compiler (j'ai ajouté parasolid, MUMPS, oo_nda) et ça tourne plutôt bien (les perfs sont assez bonnes, voire très bonnes). Pour fêter ça, j'ai défini un ''CMake/macos.cmake'' (config de compilation complète) et ''CMake/macos-student.cmake'' (config de compilation sans oo_nda, ni parasolid). +
-J'ai supprimé ''CMake/OSX-student.cmake'' qui n'est plus utile. +
- +
-Il me reste à compiler les modules python auxiliaires (PyQt, numpy) et tester vtk sous python. +
- +
-Pour la batterie, il faudra voir comment gérer les baconneries nécessaires au bon déroulement de celle-ci; samcef n'étant pas disponible sous Mac. +
- +
-Autre amélioration de la version Mac de Metafor: l'aspect de la fenêtre graphique principale de Metafor était très moche sur Mac dû à un mauvais choix de police de caractères. J'avais eu le même problème sous Ubuntu où j'avais dû trouver une police pas trop laide qui existait et sous Windows et sous Linux. Ce problème a été résolu de manière élégante dans Qt 5.2: c'est la police "monospace" du système qui est choisie (et qui dépend donc de votre "thème" de bureau). J'utilise cette nouvelle fonctionnalité et j'ai donc changé la manière dont les polices de type "monospace" sont choisies. Le rendu est maintenant "parfait" sur toutes les plateformes (quand on utilise Qt 5.2).  +
- +
- --- //[[r.boman@ulg.ac.be|boman]] 2017/04/04 16:35//+
  
 +J'ai supprimé les tabs qui avaient été ajoutés lors de commits précédents (principalement par Gaëtan).
  
 + --- //[[r.boman@ulg.ac.be|boman]] 2019/07/10 14:27// 
  
commit/futur/robo.1491410207.txt.gz · Last modified: 2017/04/05 18:36 by boman

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki