URL: https://linuxfr.org/news/libreoffice-4-4-sous-le-capot Title: LibreOffice 4.4 : sous le capot Authors: woprandi djabal, coid, oinkoink_daotter, Crao, BAud, Xavier Teyssier, HSimpson, Nÿco, Benoît Sibaud, palm123, Jiehong, j, esdeem, ZeroHeure et reynum Date: 2015年01月29日T15:12:18+01:00 License: CC By-SA Tags: bureautique, libreoffice, coulisses, lennart_poettering et openoffice Score: 108 LibreOffice 4.4 a été publié le 29 janvier 2015. Cette nouvelle version est destinée aux utilisateurs expérimentés — les autres, comme les entreprises et les administrations, sont invités à rester sous LibreOffice 4.3.5. ![logo LibreOffice](https://wiki.documentfoundation.org/images/7/77/LibreOffice_external_logo_300px.png) [Michael Meeks](http://en.wikipedia.org/wiki/Michael_Meeks_%28software_developer%29) est un développeur qui travaille sur la suite bureautique LibreOffice pour l’éditeur Collabora. Il vient de publier sur son [blog](https://people.gnome.org/~michael/blog/2015-01-29-under-the-hood-4-4.html) une longue description du travail qui a eu lieu sous le capot lors de ce cycle de développement menant à la version 4.4 de LibreOffice. Cette dépêche est une traduction de son article, initialement publié dans le domaine public ou licence CC0. ---- [Article original](https://people.gnome.org/~michael/blog/2015-01-29-under-the-hood-4-4.html) [Notes de version](https://wiki.documentfoundation.org/ReleaseNotes/4.4/fr) [Dépêche sur la version précédente (4.3)](http://linuxfr.org/news/libreoffice-4-3-est-sorti) [Téléchargement](http://fr.libreoffice.org/) ---- Aujourd’hui, nous [publions](http://blog.documentfoundation.org/2015/01/29/libreoffice-4-4-the-most-beautiful-libreoffice-ever/) LibreOffice 4.4.0, avec plein de nouvelles fonctionnalités pour tous les goûts. Lisez et admirez les [nouveautés apportées aux utilisateurs](https://wiki.documentfoundation.org/ReleaseNotes/4.4/fr). Tout cela est réalisé par beaucoup de programmeurs talentueux. Mais, il y a, comme toujours, nombre de contributeurs dont le travail réside dans les coulisses sur bien des points qui ne sont guère connus. Ce travail est, bien sûr, primordial pour la santé du projet. Il peut être difficile de savoir ce qui ce passe sur plus de 11000 _commits_ faits depuis LibreOffice 4.3. Alors, en voici le détail. Refonte complète de l’interface utilisateur ======================================= La migration des boîtes de dialogue VCL vers Glade est désormais pratiquement terminée (après avoir pensé que nous avions fini, Caolan découvrit beaucoup de fenêtres qui nécessitent la poursuite du travail, mais toutes ont été migrées, à part deux). Il y eut également beaucoup de travail pour les nettoyer et les peaufiner. Un grand merci à _Caolán McNamara (Red Hat)_ pour son incroyable travail et son _leadership_ et à _Adolfo Jayme Barrientos, Palenik Mihály (GSoC 2014), Olivier Hallot (EDX), Szymon Kłos (GSoc 2014), Rachit Gupta (GSoC 2014), Tor Lillqvist (Collabora), Jan Holesovsky (Collabora), Maxim Monastirsky, Efe Gürkan YALAMAN, Yousuf Philips et beaucoup d'autres_. Merci aussi à nos traducteurs qui devraient désormais moins souffrir des modifications intempestives des chaînes de caractères. Je rajoute que [resource-compiler](http://cgit.freedesktop.org/libreoffice/core/tree/rsc/README) a subi un beau régime. ![Graph of progress in UI layout conversion](http://people.gnome.org/~michael/images/2015-01-28-ui-layout.png) Backend initial de rendu OpenGL ================================ Le passage à OpenGL dans VCL pour le rendu est une de ces choses qui devraient, idéalement, se dérouler de manière invisible, mais qui, au final, a un impact important sur le rendu visuel. Tout le travail a été réalisé ici par des ingénieurs _Collabora_, avec un gros ré-usinage et la gestion initiale de OpenGLContext par _Markus Mohrhard_, une grande partie de l'implémentation du rendu avec anti-crénelage par _Louis-Francis Ratté-Boulianne_ et le travail de redimensionnement d'image par _Lubos Lunak_, divers correctifs liés aux fenêtres et du travail de portage de _Jan Holesovsky_ et un peu de _Chris Sherlock_. Pendant ce temps, nous avons aussi implémenté une application VCL, une démonstration à peu près décente et de plus en plus complète pour s’exercer à faire du rendu. Des explications de ce travail avec des images : https://people.gnome.org/~michael/blog/2014-11-10-opengl.html En passant à un modèle de rendu en pur OpenGL, nous pouvons accélérer les opérations qui ont grandement besoin de tirer parti de la puissance et du parallélisme de tous les transistors consacrés à l'APU sur les GPU modernes. Être capable d'interagir beaucoup plus directement avec le matériel graphique sous-jacent nous aide à la fois à rendre nos aperçus d'image en haute qualité et de ne pas sacrifier les performances de défilement et de zoom : on a, à la fois, le beurre et l'argent du beurre. Nous avons également utilisé une partie de cette puissance pour accélérer non seulement notre rendu d'image considérablement, mais aussi pour améliorer sa qualité par rapport à avant... ![Before: image down-scaling](http://people.gnome.org/~michael/images/2015-01-28-chartres.png) ... et maintenant (si votre navigateur redimensionne les images, ça perd tout son sens : remettez le zoom à 1:1 et regardez le haut de la rosace, et d'autres parties en hautes fréquences) : ![After: faster, better, GL image down-scaling](http://people.gnome.org/~michael/images/2015-01-28-chartres-gl.png) Il y a encore du travail pour que OpenGL soit dans un état acceptable, notamment à cause de quelques bugs bizarres du cycle de vie des fenêtres ; il faut paramétrer une variable d'environnement via un `export SAL_FORCEGL=1` pour passer outre la liste noire, mais nous espérons résoudre ceci pendant le cycle de la 4.4.x. Certaines fonctionnalités sont encore en attente et devraient arriver pour la version 4.5. Par exemple un véritable gestionnaire de boucle d'attente par _Jennifer Liebel_ et _Tobias Madl_ ainsi qu'un travail en cours sur le canvas OpenGL (_Michael Jaumann_) et sur les transitions OpenGL (_Stefan Weiberg_). Ces travaux sont encadrés par _Thorsten Behrens (SUSE)_. Visualisateur Mobile / LibreOfficeKit ============================== Le récemment annoncé [Android Viewer (Beta)](http://people.gnome.org/~michael/blog/2015-01-21-android-viewer.html) inclut un certain nombre d'éléments invisibles, en particulier l'amélioration de LibreOfficeKit : une façon simple de réutiliser les bienfaits du rendu et du format de fichier de LibreOffice, conçus par _Andrzej Hunt et Kohei Yoshida (Collabora)_ pour créer le rendu par tuiles pour Impress et Calc au moins en version bêta (NdT: le rendu par tuiles consiste à segmenter l’affichage plutôt que de tout faire d’un coup). Vous pouvez en lire plus à propos du [travail](http://vmiklos.hu/blog/tiled-editing-part-1.html) débuté sur le mode édition pour TDF. LibreOfficeKit est également devenu plus puissant dans l'extraction des méta-données des documents de la base, toujours plus vaste, de formats de fichier que LibreOffice gère, ce qui est important pour l’indexation des données non structurées. Améliorations du build / de la plateforme ======================================= Compilations sous Windows 30% plus rapides ------------------------- Avec le nouveau système de compilation terminé, nous avons examiné son principal problème : le temps de compilation plutôt élevé sous Windows. [Un examen et quelques _benchmarks_](http://lists.freedesktop.org/archives/libreoffice/2014-June/061727.html) ont révélé que l'usage de Cygwin était la cause principale de lenteur et _Michael Stahl (Red Hat)_ a fait en sorte de pouvoir construire LibO 4.4 avec une version native Win32 de GNU make, réduisant le temps total de compilation de près d'un tiers par rapport à un Cygwin de base et accélérant encore plus les re-compilations incrémentales. Port vers Win64 -------------------- Une autre amélioration majeure vient de _David Ostrovsky (CIB)_, qui a réalisé un travail important pour terminer le portage Win64. Nous espérons une disponibilité pour la version 4.5 et cela devrait aider significativement, notamment, les utilisateurs Java et ceux ayant de très grosses feuilles de calcul. Jetez un œil à la [page wiki Windows 64 bits](https://wiki.documentfoundation.org/Development/msvc-x86_64) pour plus de détails. Merci également à _Mark Williams_ pour les travaux délicats de correction sur UNO et à _Tor Lillqvist (Collabora)_ qui a posé les fondations de ce travail. Travail autour de la qualité du code ================= Il y a eu beaucoup de travail sur la qualité, l'amélioration de la maintenabilité et la propreté du code. Merci aux quelques 59 _commits_ de corrections d'erreurs `cppcheck` de _Thomas Arnhold, Julien Nabet et Simon Dannner_, parmi les _commits_ quotidiens pour compiler sans aucun avertissement `-Werror -Wall -Wextra` sur beaucoup de plateformes avec des remerciements à _Tor Lillqvist (Collabora), Caolán McNamara (Red Hat) et Thomas Arnhold_. Impressionnant Coverity ---------------- Nous avons parcouru l’énorme quantité de données analysée avec le "Coverity Scan". En particulier, _Caolán McNamara (Red Hat)_ a réalisé un superbe boulot. Son [blog](http://caolanm.blogspot.co.uk/2014/11/libreoffice-coverity-defect-density-000.html) à ce sujet est, comme à l’accoutumée, modeste. Nous avons désormais une densité de défauts qui approche 0, bien que Coverity introduise de nouvelles vérifications et que le nouveau code commité fasse varier ce chiffre. Nous sommes actuellement à 0,02 c'est à dire, 2 avertissements de vérification statique pour 100 000 lignes. C'est extrêmement bien comparé à la moyenne des projets open source qui se situe à environ 65. Les commits mentionnant Coverity sont au nombre de 1530 depuis LibreOffice 4.3 avec dans le top 3 des contributeurs après Caolán (1378 commits) : _Norbert Thiebaud, David Tardon (Red Hat), Miklos Vajna (Collabora)_. Augmentation de l'utilisation d'« asserts » ------------------------- Dans la version 3.5, nous sommes passés d'un système maison de macros à des appels normaux d'« assert » pour assainir les vérifications d'invariants. Leur nombre augmente au fur et à mesure : ![Graph of number of run-time assertions](http://people.gnome.org/~michael/images/2015-01-28-asserts.png) Tests de l'import et maintenant de l'export ----------------------------- Les tests de crash d'importation / exportation de _Markus Mohrhard (Collabora)_ ont été élargis pour couvrir plus de 76 000 documents problématiques contre 55 000 à la dernière version, avec désormais une sélection d'images irrégulières *(?)* aussi incluse. Une autre grande victoire était la mise à disposition par TDF (merci à nos [donateurs](https://donate.libreoffice.org/)) d'une nouvelle machine 64 cœurs pour exécuter le chargement/l'enregistrement/la validation des tests ci-dessus. Ceci, combiné avec quelques retouches et un meilleur parallélisme des scripts Python qui dirige cela, a accéléré l’exécution de tests, réduisant le temps de cinq jours à moins de un, permettant une détection rapide de nouvelles régressions de façon beaucoup plus précise. Nous avons également été en mesure de lancer [AddressSanitizer](https://code.google.com/p/address-sanitizer/) sur une série de documents, ce qui a conduit à plusieurs corrections, merci à _Caolán McNamara (Red Hat)_ pour l'excellent travail effectué. Greffons / outils d'analyse pour Clang ------------------------ Nous avons continué à compléter notre collection de greffons Clang : un rapide "git grep" sur _Registration_ dans le dossier "compilerplugins" montre que nous sommes passés de 27 à 38 greffons dans les six derniers mois. Ceux-ci vérifient de tout un tas de façons pleins de trucs piégeux dans notre code dans lesquels les gens peuvent tomber. Certains de ces greffons sont utilisés manuellement, mais beaucoup sont lancés automatiquement sur le _Tinderbox_ et par certains utilisateurs pour trouver les erreurs rapidement. Merci à : _Stephan Bergmann (Red Hat) et Noel Grandin (Peralex)_ pour le dur travail fourni sur ces outils d'analyse. Les greffons font plein de choses, par exemple, _Bjoern Michaelsen (Canonical)_ en a [écrit](https://skyfromme.wordpress.com/2014/12/02/to-win-in-toulouse/) un qui détecte les imbrications profondes de clauses conditionnelles comme [ces](https://gerrit.libreoffice.org/gitweb?p=core.git;a=blob;f=sw/source/core/doc/DocumentContentOperationsManager.cxx;h=6955cde6edd79a530513ac8e7db2a203265405dc#l3205) [monstres](https://gerrit.libreoffice.org/gitweb?p=core.git;a=blob;f=sw/source/core/txtnode/thints.cxx;h=5ec497a734d78dae96c7e456ccad252f7f3bca62#l3411). Ils sont difficiles à lire et une plaie à débugguer. Certains des pires cas dans sw/ (NdT: Writer) ont été réécrits et le greffon peut facilement être utilisé ailleurs dans les sources. Tests unitaires --------------- Nous construisons et exécutons aussi plus de tests unitaires pour éviter les régressions lorsque nous changeons le code. Une recherche `grep` sur les macros TEST et ASSERT montre que le nombre de tests continue d'augmenter. ![Graph of number of unit tests and assertions](http://people.gnome.org/~michael/images/2015-01-28-unit-tests.png) L'idéal est d'ajouter un test unitaire à chaque bug corrigé pour l'empêcher de revenir à jamais. Avec environ 1000 commits pour plus de 70 auteurs sur les tests unitaires dans la 4.4, il est difficile de lister toutes les personnes impliquées dans ce travail, mes excuses pour cela. Voici une liste triée des auteurs de plus de dix commits dans les répertoires `qa/` : _Miklos Vajna (Collabora), Caolán McNamara (Red Hat), Kohei Yoshida (Collabora), Michael Stahl (Red Hat), Stephan Bergmann (Red Hat), Zolnai Tamás (Collabora), David Tardon (Red Hat), Noel Grandin (Peralex), Matúš Kukan (Collabora), Luboš Luňák (Collabora), Markus Mohrhard (Collabora), Tor Lillqvist (Collabora), Thomas Arnhold, Andrzej Hunt (Collabora), Eike Rathke (Red Hat), Jan Holesovsky (Collabora)_. Assurance Qualité / Bugzilla ------------- Sur les six derniers mois, l'équipe QA _[NDR : pour "quality assurance", assurance qualité]_ a grandi en taille et en efficacité. Réalisant un travail fantastique pour réduire le nombre de bugs non triés de mille (ce que nous pensions déjà bien) vers à peine plus de trois cents. Le tri de certains de ces bugs étant particulièrement difficiles car assez techniques ou très difficiles à reproduire, c'est un excellent travail. C'est assez difficile d'extraire la liste de ceux qui confirment les bogues, mais la liste des héros se chevauche avec la liste non-développeurs/top clôtureurs donnée ci-dessous. L'une des métriques que nous regardons dans l'appel ESC est l'appartenance au top dix dans la [liste récapitulative hebdomadaire freedesktop](https://bugs.documentfoundation.org/page.cgi?id=weekly-bug-summary.html). Voici une liste des personnes qui sont apparues plus de cinq fois dans cette liste de ceux qui ont clôturé le plus de bogues (dans l'ordre de fréquence de d'apparence) : _Caolán McNamara (Red Hat), Adolfo Jayme, tommy27, Julien Nabet, Jean-Baptiste Faure, Jay Philips, Urmas, Maxim Monastirsky, Beluga, raal, Michael Stahl (Red Hat), Joel Madero, ign_christian, Cor Nouws, V Stuart Foote, Eike Rathke (Red Hat), Robinson Tryon (TDF), Miklos Vajna (Collabora), Matthew Francis, foss, Sophie (TDF), Samuel Mehrbrodt, Markus Mohrhard (Collabora)_. Et merci à _tous les autres d'avoir aidé à fermer autant de bogues pour cette version_. _Bjoern Michaelsen (Canonical)_ a également écrit une [« Assurance Qualité du nouvel an »](https://skyfromme.wordpress.com/2015/01/05/auld-lang-syne/) qui vaut le coup d’être lue. Un autre succès qui devrait nous aider à rendre notre bugzilla plus convivial et mieux structuré est la migration de l'infrastructure FreeDesktop vers TDF, en remerciant FreeDesktop pour avoir pris en charge notre gros bugzilla pendant toutes ces années. Le travail a été récemment terminé, donc désormais les bugs sont à déposer à [http://bugs.documentfoundation.org/](http://bugs.documentfoundation.org). Merci à _Robinson 'colonelqubit' Tryon (TDF), Tollef Fog Heen et notre équipe d'administrateurs système pour ce travail_. Même si cela est peut-être évident, Robinson travaille pour TDF (financé par nos [généreux donateurs](https://donate.libreoffice.org/fr/)) à mi-temps pour aider à améliorer la situation côté QA. Nettoyage de code ============ Le code sale doit être nettoyé - donc nous avons beaucoup nettoyé. Nettoyage des commentaires en allemand ---------------------------- Nous avons continué a progresser, mais malheureusement peu, dans la traduction des commentaires allemands persistant dans le code en bon anglais technique précis. C'est un bon moyen de s'investir dans le développement de LibreOffice. Mille mercis à : _Philipp Weissenbacher, Christian M. Heller, Jennifer Liebel (Munich), Chris Sherlock (Collabora), Michael Jaumann (Munich), Luc Castermans, Jeroen Nijhof, Florian Reisinger et de nombreux autres avec un seul changement à leur actif_. De plus, la diminution des faux positifs signalés par bin/find-german-comments suggère qu'il ne reste que dix modules de premier niveau contenant de l'allemand, parmi eux, neuf méritant des efforts de traduction : i18npool, include, reportdesign, sc, scaddins, sfx2, stoc, svx, sw. ![Graph of remaining lines of German comment to translate](http://people.gnome.org/~michael/images/2015-01-28-german-comments.png) Une des contributions particulièrement encourageante à notre [effort](https://gerrit.libreoffice.org/gitweb?p=core.git;a=commitdiff;h=1958ca235be05912497747b9916f22258f5716d4) de traduction des commentaires allemand a été celle de _Lennart Poettering_ qui semble avoir [quelque chose de drôle](https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/VUzeRLf5g5m) en préparation. Mise à jour vers (un peu de) sous-ensemble de C++11 -------------------------------- Avec le temps, C++ s'améliore, et avec la mise à jour de Visual Studio, nous avons pu passer à un sous ensemble de C++11 (celui offert par VS2012) en tant que base. Nous avons aussi retiré plusieurs contournements (empêchant des optimisations) de bug présents sur des vieilles versions de GCC (qui de toute façon ne prennent pas en charge C++11), et donc GCC et MSVC peuvent tous les deux désormais compiler l'ensemble de LO avec toutes les optimisations. Merci à _Stephan Bergmann (Red Hat)_ pour la recherche et la gestion de ce travail. Nettoyage du tokenizer OOXML ---------------------------- Ce nettoyage s'appuie sur le travail de _Miklos Vajna (Collabora)_ dans la dernière version. Un gros morceau de notre tokenizer OOXML était du code généré, ce qui est raisonnable, mais il a été généré en utilisant XSLT (qui a tendance à être en-dessous de cobol). Les 4200 lignes de XLST ont été réécrites en 1300 lignes de Python - pour produire le même résultat avec une forte augmentation de la hackabilité. Puis certaines optimisations ont été réalisées par _Jan Holesovsky (Collabora pour CloudOn)_, pour réduire des parties inefficaces de la sortie générée par writerfilter DSO, faisant ainsi 2,2Mo d'économie sur 8Mo (dépouillé). C'est génial de voir ce genre de nettoyage de code, la taille du code et du binaire se réduisant en même temps. Vous pouvez en lire plus à ce sujet sur le [blog de Miklos](http://vmiklos.hu/blog/ooxmltok.html). std:: containers ---------------- Un ensemble systématique d'améliorations à notre utilisation des conteneurs `std::` est en cours dans le code. Des choses comme éviter l'héritage de `std::vector`, changer `std::deque` en `std::vector` et commencer à utiliser les nouvelles constructions C++ pour l'itération comme `for (auto& it : aTheContainer) { ... }`. Il y a beaucoup de gens à féliciter ici, merci à _Stephan Bergmann (Red Hat), Takeshi Abe, Tor Lillqvist (Collabora), Caolan McNamara (Red Hat), Michaël Lefèvre, et bien d'autres_. Amélioration des performances ======================== Les performances font partie de ces éléments assez difficiles à voir, néanmoins on les ressent viscéralement de cette manière : « pourquoi est-ce que je dois encore attendre ? ». Il y a un nombre encourageant d’améliorations de performances faites par différentes personnes dans LibreOffice 4.4 qui valent la peine d'être notées. Performance de l'auto-correction ----------------------- Pour des raisons qui me dépassent, certaines personnes aiment avoir d'[énormes](https://bugs.documentfoundation.org/show_bug.cgi?id=79761) listes d'auto-correction. Elles sont stockées au format XML zippé. _Daniel Sikeler (Munich)_ a amélioré de façon sympathique le chargement de celles-ci. Il a découvert en particulier que nous réanalysions notre `BlockList.xml` un grand nombre de fois, et résoudre ce bug a fait une grosse différence. Si on combine cela avec le passage à `FastParser` qui a été threadé et amélioré, on gagne encore plus. La liste d'auto-correction est chargée après la première touche appuyée, donc descendre de 4,3 secondes à 1,5 secondes (pour des listes énormes de correction) est une belle victoire. Gestion des images ---------------- Tout en profilant la sauvegarde de différents types de fichiers, il a été découvert que nous échangeons fréquemment (i.e. rechargeons et re-décompressons) les images. Cela prend bien évidemment beaucoup de temps CPU, en particulier puisqu'ensuite on continue tout de suite à préserver les données (originales) dans le fichier. Dans certains cas cela prenait une grosse portion du temps de sauvegarde pour des présentations ayant beaucoup d'images. Merci à _Tamaz Zolnai (Collabora)_ pour le nettoyage et la résolution de ce problème, et ainsi que la chasse à ces soucis récurrents de perte d'image. Fast Serializer --------------- En règle générale, toute classe nommée « Fast » dans le code hérité d'OpenOffice est atrocement mal nommée. Un grand merci à _Matus Kukan (Collabora)_ pour avoir résolu cela. Nous avons découvert que 25% du temps d'enregistrement d'un fichier XLSX composé de grandes feuilles était consommé dans le « FastSerializer », qui, à notre grande stupeur, lance 9.900.000 appels système, chacun écrivant à chaque fois de minuscules fragments d'un attribut XML. Il sépare par exemple les écritures pour les ouvertures des balises, les noms d'éléments, les noms d'attributs, les espaces de noms, etc. Matus a réduit cela à 76.000 appels pour produire le même résultat, soit une baisse de 99%. Abstraction faite de la surcharge d'appels systèmes, nous avons réduit le nombre de cycles CPU cachegrind pour « SaveXML » de plus de douze milliards à moins de trois milliards pour un cas simple. Empaquetage de libjpeg-turbo -------------------- On sait depuis plusieurs années que JPEG-turbo fournit des [performances](http://www.libjpeg-turbo.org/About/Performance) de décompression supérieures - « In the most general terms, libjpeg-turbo is 2.1 - 5.3x as fast as libjpeg v6b and 2.0 - 5.8x as fast as libjpeg v8d ». Naturellement les éditeurs Linux utilisent la ligpjpeg packagée dans leur système, mais quand on distribue pour Windows... Nous fournissons maintenant une accélération x2 sous la forme de libjpeg-turbo. Merci à _Matúš Kukan (Collabora) avec quelques nettoyages de Stephan Bergmann (Red Hat)_. Des volontaires pour intégrer proprement jpeg-turbo sur Mac seraient fortement appréciés. Performance du publipostage ---------------------- Le publipostage fonctionne en construisant un énorme document contenant le résultat de tous les courriers à imprimer / fusionner vers un ficher unique. La pertinence est très discutable, mais merci cependant à _Lubos Lunak & Miklos Vajna (tous deux Collabora pour Munich)_ qui ont fait un effort significatif pour accélérer substantiellement les fusions de gros documents, selon les cas de plusieurs ordres de grandeur. Malheureusement OpenOffice.org avait subi une grosse régression à ce propos dans la version 3.3, et ceci est globalement corrigé. On passe de plusieurs heures à quelques minutes pour 2000 enregistrements. Performance de Calc ================== Il y a eu un certain nombre de gains de performance sympathiques dans cette version de LibreOffice, qui, une fois cumulés ont un effet assez bénéfique. Améliorations des dépendances de plages (Range dependency re-work) ------------------------ Pour les précédentes versions de LibreOffice _Kohei Yoshida (Collabora)_ a passé beaucoup de temps à unifier l'exécution de formules similaires dans FormulaGroups - qui s'étendent tout le long d'une colonne - puisque c'est un cas courant des grands ensembles de données. Cela a permis une réduction importante de l'utilisation mémoire et beaucoup de partage de données. Cependant, la gestion de dépendance était découplée de cette opération et était encore effectuée cellule par cellule. C'est particulièrement coûteux si vous envisagez une référence de plage qui est commune à tout le groupe de formules : cela aboutit à beaucoup de travail pour pas grand chose, essentiellement pour notifier tout le groupe de formules. Calc 4.4 ajoute un type de _Listener_ qui est adapté pour ces groupes de formules - pouvant potentiellement transformer des dizaines de milliers d'entrées de structure de données complexes en une seule entrée. Cela permet d'économiser des gros bouts de mémoire et beaucoup de temps CPU sur les parcours des listes, il permet aussi d'économiser énormément de temps lors de la diffusion des changements. Il y a encore beaucoup de travail à réaliser pour développer toutes les possibilités de ce changement et, idéalement à l'avenir, nous devrions utiliser la même approche pour les références de cellule. Merci aussi à _Eike Rathke (Red Hat) et Markus Mohrhard (Collabora)_ pour certains correctifs associés. Détection du type d'écriture d'une cellule ------------------------- Pour plusieurs raisons, la détection du type d'écriture d'une cellule est une opération coûteuse; est-ce un texte asiatique, un texte simple ou complexe (qui a un effet sur la police, sa taille et différentes métriques). _Kohei Yoshida (Collabora)_ a trouvé que lors de différentes opérations courantes (ex: copier/coller de gros blocs de données) cette détection était répétée inutilement. De même, pour des types de donnée simple avec formatage standard (ex: de grands blocs de nombres à virgules), il était possible de simplifier significativement la détection du type d'écriture. Différer la régénération des diagrammes --------------------------- Un autre domaine qui cause (encore) quelques douleurs est qu'à chaque fois qu'une plage de données dont dépend un diagramme change, le diagramme entier est généré à nouveau. Cela implique de détruire de nombreuses formes graphiques et de les recréer, ce qui dans le cas d'un texte coûte particulièrement cher. _Kohei Yoshida (Collabora)_ a implémenté une belle optimisation pour différer ce travail jusqu'à ce que le diagramme soit visible. Cela devrait avoir un effet agréable sur le temps d'édition d'un grand ensemble de données converti en diagrammes dans beaucoup d'autres feuilles comme sur l'exploitation de macros dans beaucoup de diagrammes. S’impliquer ================ J’espère que vous comprendrez que de plus en plus de développeurs arrivent et se sentent comme chez eux parmi nous. Nous travaillons ensemble pour réaliser des travaux importants à la fois sous le capot et sur la carrosserie. Si vous voulez vous impliquer, il y a plein de gens compétents à rencontrer et avec qui œuvrer. Comme vous pouvez le constater, les indépendants ont un impact significatif sur la diversité de LibreOffice (la légende de couleurs se lit de gauche à droite, de haut en bas, ce qui représente les couleurs de haut en bas dans le graphique. [NdT: les indépendants, c’est le gros morceau orange au milieu.]) ![Graph showing individual code committers per month](http://people.gnome.org/~michael/images/2015-01-28-committers.png) Et en ce qui concerne la diversité des correctifs, nous adorons voir le volume des contributions apportées par les indépendants, même si clairement ce volume et les équilibres changent selon les saisons, les cycles de publication, le temps libre / de travail des volontaires. ![Graph of number of commits per month by affiliation](http://people.gnome.org/~michael/images/2015-01-28-commits.png) Naturellement, nous maintenons une liste de petites ou minuscules tâches sur notre [page Easy Hacks](https://wiki.documentfoundation.org/Development/Easy_Hacks) dont vous pouvez vous emparer pour vous impliquer dans ce projet, avec des instructions simples d’installation ou de compilation. Il est extrêmement facile de compiler LibreOffice. Chaque « Easy Hack » indique où aller dans le code et représente une tâche simple à résoudre dans un cadre bien restreint. De plus, certaines de ces tâches sont des fonctionnalités vraiment utiles ou des améliorations de performance. S’il vous plaît, envisagez de vous impliquer sur quelque chose. Autre chose qui aide vraiment : lancer les préversions et rapporter les bogues. Il suffit de télécharger et d’en installer une et vous êtes prêt pour contribuer avec l’équipe de développement. Conclusion ========== LibreOffice 4.4 est la prochaine d’une série de versions qui vont améliorer progressivement non seulement les fonctionnalités, mais aussi les fondations de la suite bureautique libre. Ce n’est bien sûr pas encore parfait, c’est juste la première d'une longue série de versions 4.4.x mensuelles, qui apporteront chacune leur lot de correctifs et d’améliorations qualitatives dans les mois à venir, tandis que nous commençons à travailler sur LibreOffice 4.5. J’espère que LibreOffice 4.4.0 vous plaira. Merci de m’avoir lu, et merci de soutenir LibreOffice. N’oubliez pas de consulter la page des nouveautés visibles. Les [données brutes](http://people.gnome.org/~michael/data/2015-01-28-4.4-data.ods) de la plupart des graphiques ci‐dessus sont disponibles.

AltStyle によって変換されたページ (->オリジナル) /