C'est exactement le même principe mais fait à un niveau d'abstraction différent. Au lieu des boundings box c'est des éléments du dom.
Cela n'a pas la meme fonction et n'a pas non plus les memes impacts. Tout d'abord, l'objectif d'une telle optimisation base sur le n-buffering est de sauver de la bande passante. Compare au double DOM qui lui tente de sauver des performances lors de la traverse de la barriere JS/DOM (qui est necessaire, car les appels au DOM stop les optimisations de type JIT). Il n'y a pas d'amelioration de bande passante memoire ni de reduction de ce qui va etre rendu a l'ecran. Cela evite juste de faire des appels qui n'auraient du rien coute, mais qui coute dans le monde web. C'est aussi pour ca que l'implementation dans les navigateurs web d'un double DOM n'aurait pas d'impact sur les performances des applications JS.
De plus, les boundings box, c'est des objets tres sympa, ca tiens sur 4 entiers et un booleen. Tu peux les utiliser directement dans le GPU. Et enfin, tu n'as pas besoin de les reallouer entre deux frames, car elles sont tres facilement reutilisable. Tu peux optimiser ta structure memoire pour qu'elle soit bien lineaire et que les cache memoire apprecie. Pour plus de lecture: https://raphlinus.github.io/rust/graphics/gpu/2022/02/24/piet-gpu-clipping.html .
Enfin tu pourras en conclure que un navigateur web, meme si il fait du rendu d'un truc qui utilise react, aura toujours a gagner a implementer des optimisations de type n-bufferring. Et le double DOM serait probablement moins utile si il etait possible de faire des appels DOM directement depuis le code JIT au lieu de repasser en mode interprete.
car cela implique de creer/detruire pas mal d'objet.
Non justement. C'est le boulot de React de ne pas le faire.
React evite de construire des objets DOM, pas des objets JavaScript. Ceux-ci existent et consomme des ressources. Ils peuvent etre recycle sous certaine condition probablement, mais globalement, ca va passer par des cycles de GC.
Le double buffering, c'est juste sur le contenu du buffer graphique. C'est principalement utilise pour eviter les problemes de synchronisation avec l'ecran. L'idee, c'est que tu peux travailler dans un buffer pendant que le deuxieme buffer est pousse a l'ecran.
Theoriquement on devrait pouvoir se passer completement de ce buffer supplementaire qui impact la latence pour afficher ce qui ce doit au plus pres du moment ou le contenu va arriver a l'ecran. Tu as toujours au moins une latence de 16ms a 60Hz, mais ca peut varier car il n'y a pas de synchronisation explicite dans la chaine de rendu et du cout les applications travaillent souvent avec en fait 3 buffers. Pour une petite introduction sur le sujet: https://github.com/ishitatsuyuki/LatencyFleX . Aucun toolkit a ma connaissance n'en est la pour l'instant.
Maintenant, pour Wayland et dans certain cas sous X11, tu peux te retrouver a travailler dans le buffer que tu avais presente a l'ecran il y a 2 frames. Du coup, tu peux, si tu as une idee des changements qui ont eu lieu, faire un delta et uniquement toucher les morceaux du buffer qui ont change. Pour faire ce delta, tu ne travaille pas au niveau des pixels, cela serait trop couteux, mais au niveau des boundings box des primitives graphiques qui composent la scene que tu dois rendre. En regardant quel bounding box a visiblement change depuis les 2 ou 3 dernieres frame, tu peux construire un "masque" des zones a redessiner. Mais cela s'applique uniquement a Linux, les autres ecosystemes n'ont pas cette fonctionnalite et ne permettent pas de connaitre l'age d'un buffer. Du cout, peu de toolkit graphique implemente cette optimisation. Cela n'est peut etre plus vrai avec Vulkan, mais je n'en suis pas certain.
Techniquement, tous ces toolkits sont en go. Ca veut dire que tu as un GC et si tu remplace le contenu d'un conteneur par un autre arbre de widget, celui-ci fera exactement la meme chose qu'en react. Maintenant, je ne pense pas que ce soit un bon pattern pour l'usage de ces API, car cela implique de creer/detruire pas mal d'objet.
Meme avec un systeme optimise, cela a un cout qui impact les performances. Dans ton exemple, c'est probablement negliegable voir meme pas mesurable. Mais comme pattern generaliste, cela a clairement un impact sur les performances. La premiere limite d'un systeme aujourd'hui, c'est sa bande passante memoire. Creer/detruire/acceder de la memoire a tout bout de champs pour pas grand chose a un impact sur les performances non negligeable.
Ainsi une API dans laquel on va juste rendre invisible explicitement le button sera plus efficace qu'une dans laquelle on va soit traverser un arbre ou parser une commande pour decider de rendre invisible ou detruire un button. Je trouve aussi que cela a tendance a mixer code definissant l'interface et logique du programme, cela veut dire que collaborer avec un designer n'est pas forcement trivial. Je pense qu'on peut faire mieux que ca.
Oui, c'est la téchnique du shadow DOM. Mais tu veux dire que tu peux recréer complètement tout tes widgets à la volé à chaque modification du modèle applicatif sans perte de performance ? J'ai un gros doute.
Non, j'expliquais comment fonctionne react et pourquoi il fonctionne comme ca. Tu n'as pas besoin d'avoir un shadow DOM ou equivalent quand tu fais du natif, car tu n'as pas ces barrieres couteuses.
Dans le cadre d'un toolkit natif, tu as deux morceaux, l'API de widget et la logique de rendu de ces widgets a l'ecran. Dans une API de type "immediat", tu vas avoir un evenement de type "paint" a chaque frame qui va te demander de redessiner le contenu de ton widget. La complexite du rendu est donc deporte dans le widget, voir l'application (cela depend de l'API du widget). Dans une API de type "retained", le code du widget modifie des primitives sur le canvas et c'est le canvas qui va alors voir si il y a un changement lors de la prochaine frame. Ca donne plus de possibilite d'optimisation, car le canvas a une vue globale de ce qu'il y a a faire.
Globalement, dans ces deux cas, tu peux faire des optimisations de type shadow DOM, ce qui limitera les appels sur les API des widgets. Dans le cas d'une API de type immediat, cela payera probablement. Par contre dans le cas, d'une API "retained", c'est tres peu probable voir l'inverse, car cela va augmenter la consommation de memoire et donc la consommation de bande passante qui est la principale ressource limitante pour une application native.
Quel est l'interet de dupliquer en memoire une information qui ne sera pas utiliser pour realiser le contenu de l'application a l'ecran? Quel est l'interet de calculer le delta de quelques choses qui sera ignore au final?
React et vue existe et on du sens dans le monde du DOM et du web. Car dans cette univers, tu as un document dont il est couteux de faire une modification et la barriere DOM / JS est lente. Le cout de modification d'une entree du DOM en JS n'est pas juste l'assignation d'une valeur et generalement pas en O(1). Dans cette univers, il est necessaire d'eviter de modifier la representation de ce qui doit etre redessiner pour des questions de performance. Il est donc necessaire pour un framework JS d'implementer une technique "retained" en interne pour avoir de bonne performance.
Dans le cas du natif, ce probleme de barriere DOM/JS et de performance de rendu n'est plus. Une API efficace native peut exposer que des operations qui sont relatif au rendu de la fenetre (Il n'est pas necessaire de maintenir l'etat de ce qui n'est pas l'ecran). Les acces a toutes les fonctions qui modifie le rendu peuvent etre en O(1) et negligeable en terme de cout d'utilisation (plusieur millier d'appel par frame, ne doivent declencher que un seul calcul par frame et idealement sans jamais bloquer un seul de ces appel).
Ceux sont des differences fondamentales entre les contraintes web et les contraintes natives.
S'il n'y a aucune contention à quoi sert le lock ?
J'ai du mal a comprendre la question. Un lock, c'est pour eviter un acces simultane en ecriture/lecture et eviter une race condition. Les contentions, c'est une question de nombre d'acces et de chance eleve d'avoir le lock deja pris quand on accede a la dite valeur. On peut avoir besoin d'un lock parce que on a une donnee qui est lu une fois lorqu'elle change par frame et qui sera ecrite souvent a la vitesse d'une IO. Mais clairement, cela ne causera pas de probleme de contention.
Je ne sais pas comment marche go pour ça les go routines sont allouées à un thread système et les threads systèmes sont exécuté sur n'importe quel cpu ?
Un pool de thread systeme est cree et matche le nombre de core disponible. Chaque goroutine sera alloue individuellement, aura sa propre stack et sera schedule en fonction des capacites/de la demande sur un thread systeme approprie. Il y a un tres faible controle de la part de l'application sur ou va etre execute une goroutine. Le scheduler essaye de faire de son mieux pour eviter de changer de CPU et enchainer les executions de goroutine pour eviter d'avoir une goroutine bloque sur une autre trop longtemps (L'ecriture dans un channel est souvent le point de logique qui va declencer un changement de goroutine si il y a une goroutine en attente sur le channel en question).
Hormis l'ajout du data binding en plus verbeux que QML
Cet phrase n'a que tres peu de sens. Les data binding sont un mecanisme qui permet de connecter un element graphique a une source de donnees. Le QML est quand a lui un user interface markup language destine a decrire le design et les interactions graphiques de l'application, idealement on ne met pas le code de l'application dans le QML. Ce n'est pas le seul et c'est un concept qui a plusieurs decennie maintenant: https://en.wikipedia.org/wiki/User_interface_markup_language .
L'inconvenient des UIML, c'est qu'il reflete l'intersection entre le canvas graphique utilise et le language auxquel il se connecte, avec des fois une contrainte supplementaire quand ils sont utilise pour definir le theme des widgets, de correspondre a la logique interne des dits widgets. Cela veut dire globalement que chaque UIML est unique et que meme l'introduction de CSS a la GTK, reste un CSS a la GTK qui a peu a voir avec le CSS du web vu que chacun utilise un canvas graphique different. Introduire un nouveau language est tres risque et il faut en avoir le besoin. Les UIML sont principalement utilise quand des interfaces tres customise sont developpe, mais une tres large partie des applications n'en utilisent pas.
L'approche de Fyne et Gio pour est de se baser sur Material Design ( https://material.io/ ). Cela veut dire que la capacite de changer le theme est defini par ce que la specification de material design autorise. Evidement, il y a moins de flexibilite et il n'y a pas besoin de developper un UIML pour ces toolkits. En contre partie, une application aura rapidement un look correct meme quand on n'a pas une grosse equipe pour faire le design.
De plus je ne trouve pas dans la doc la moindre explication sur l'implémentation du moteur de rendu. Il faut utiliser une Image pour faire de l'OpenGL ?
J'avoue ne pas comprendre le sens de cette phrase, mais pour faire simple un framework moderne se doit de faire une abstraction total du driver utilise. C'est une necessite pour la portabilite, mais cela permet aussi de changer completement la logique interne pour s'adapter a de nouvel API graphique.
Le seul avantage, c'est quand la puissance du CSS apporte une valeur ajoutée, par exemple si on veut afficher une typographie à la Wikipédia dans une application.
J'avoue que cette phrase aussi, je n'arrive pas a la comprendre. Le CSS et la typograhie sont des problemes assez orthogonaux. Wikipedia est en plus l'exemple ideal de quand utilise les technos web, car c'est de la pur documentation avec des hyper liens.
Je reste aussi sur ma faim côté UI. Les applications que j'ai développées en PyQt ces dernières années se basaient sur affichages en arbres, en liste ou en table. Trois widget/contrôles que je n'ai pas retrouvé dans les lib citées plus haut.
Je n'ai pas regarde pour Gio, mais pour fyne la liste des widgets et completement documente:
Si on ne parle pas d'API, cela veut dire qu'on parle uniquement de comparer un systeme qui utilise des locks vs un systeme qui utilise une queue. Dans le cas, qui nous concerne, pour l'implementation de fyne, il n'y a pas de data race, pas d'allocation, et les locks ne sont pas sous contention et donc se comporte comme deux appels atomics successif par lecture/ecriture sur le meme CPU. Techniquement, cela veut dire que le premier atomic va, en pire cas, declencher un vidage de cache dans les autre core du CPU pour obtenir la propriete de la memoire pointe par l'acces atomique. Comme il n'y a pas de contention, aucun autre CPU ne declenchera une perte du cache du core et le second acces sera equivalent a un acces memoire directe sans cout particulier. Ce sera cela le cout d'un lock dans ce scenario.
Maintenant, si tu prend une queue ideale, tu peux te retrouver avec une implementation qui a un seul appel a un atomic par ecriture/lecture dans la queue (CAS ou atomic sont equivalent en terme de cout, donc pas tres important). Par contre, tu es oblige d'allouer de la memoire ou de travailler de maniere bloquante. Dans le cas ideal, disons que tu pars du principe qu'il n'y a pas de contention non plus sur les acces a ta queue et que tu peux te permettre d'avoir juste une seule entree, donc pas non plus de probleme d'allocation memoire. Tu te retrouve exactement dans le cas precedent, un atomic pour faire l'ecriture avec une perte de cache dans les autres core. Par contre par design, tu as probablement plus de chance, comme tu as plus de thread dans ce design, de te retrouver avec la requete d'acces suivante sur un autre core et donc declenche une perte de cache.
Au final, un lock vs une queue dans le cas sans contention sont au mieux equivalent au pire au desaventage d'une queue. Maintenant si on n'est plus dans le cas sans contention, mais dans un cas avec contention, ce que je viens de dire n'est plus valable et le profile de performance sera different. Mais dans le cas de Fyne, il n'y a pas de contention du fait de l'API et de son usage.
Pour ce qui est de la copie c'est dommage. Je ne sais pas ce qu'il y a comme possibilité de réflexion et comme rtti pour pouvoir copier simplement. Une autre possibilité serait d'avoir un proxy qui donne une vue en lecture seule de la structure qu'il proxifie. Après ce n'est pas une obligation vuex ne fait pas ça et fais confiance à l'utilisateur.
Pour revenir sur le sujet du deep copie, c'est bien parce que quoi qu'on fasse, c'est une operation couteuse dans tous les languages et qu'il vaut mieux l'eviter autant que possible. De maniere generale, la contrainte, c'est toujours la bande passante memoire, un seul core peut facilement saturer toute ta bande passante memoire et il faut y faire attention. En forcant le developpeur a etre conscient des couts sans cacher les operations, le go renforce cette affirmation. Et reflexion et rtti sont des operations encore plus lente qu'il vaut mieux eviter en generale. Pas uniquement en go, mais dans tous les languages.
Pour ce qui est du proxy, c'est une possibilite. Mais franchement quel est le probleme que tu essaie de resoudre? Le systeme garde deja pour toi une copie des etats graphiques (uniquement ce qui a finit a l'ecran). Pas la peine de garder l'ensemble des widgets et d'en faire une copie si ceux ci ne finissent pas sur l'ecran. La memoire du delta ne sert pas a grand chose pour ca. Je pense qu'il y a un biais dans ta reflexion du a la mechanique utilise par les navigateurs web pour faire leur rendu. Ceux-ci sont bien plus proche des systemes de rendu immediat du fait de la complexite historique de leur tache. Du coup, on a rajoute des framework en JS pour essayer d'aider les navigateurs web a faire leur boulot. Ce n'est pas un probleme pour les toolkits natifs et c'est globalement devenu un standard de faire du "retained" pour la majorite d'entre eux. Il n'y a pas de besoin pour les utilisateurs de se poser se genre de problematique. Les API pour modifier les widgets sont en O(1) et le systeme ne fera un calcul de delta entre frame que lorsqu'une nouvelle frame pourra etre pousse a l'ecran.
Une des regles principales de l'ecosysteme est de faire des API synchrones avec une gestion des erreurs explicites et laisser la decision de parallelisme a l'appelant. De plus, il est recommender d'eviter autant que possible d'utiliser les channels dans une API, car leur type ne permet pas a la lecture du prototype de savoir comment les utiliser pour synchroniser deux morceaux de code (buffer/unbuffered et blocking function ne sont pas dans le prototype). Du coup, l'utilisation des channels est plutot quelques choses d'interne.
De plus, meme si les channels sont tres optimise en Go, leur cout n'est pas nul. Aussi bien en memoire que CPU. Et comparer a un lock qui quand il n'est pas un point de contention, se comporte comme un atomic, il y a une difference assez importante en terme de performance.
Enfin comme tu peux le voir, il n'y a pas de besoin de synchronisation pour tous les utilisateurs de cette API, seul les developpeurs des data bindings de type simple ont du prendre cela en consideration. Cela rend l'utilisation de l'API simple et efficace avec aucune allocation memoire une fois que le binding est construit.
Pour repondre a tes questions supplementaires concernant la copie profonde, cela n'existe pas dans le language, car cela transformerait une affectation O(1) en une complexite inconnue. Cela veut dire que la copie profonde est a implementer manuellement et explicitement de maniere a bien en voir le cout (et du cout, on evite de faire des copies autant que possible :) ). Il n'y a pas de structure immutable en Go, uniquement des champs publiques ou prives (mais une fois qu'il y a des champs prives, il est impossible de juste copier une structure, il faut fournir une fonction pour pouvoir le faire).
J'essaye de reflechir un peu plus au sujet, et je ne suis pas sur qu'il y ait grande difference sur le sujet en fait. Tout d'abord, les locks avec go, c'est obligatoire (Ou une primitive de synchronization). Les developpeurs en go s'attendent a pouvoir appeler une API depuis n'importe quel goroutine a n'importe quel moment. Il faut qu'elle soit thread safe. Tu remarqueras d'ailleur que pour les developpeurs de data binding, ils n'ont en general pas besoin de lock.
Deuxiemement concernant la difference entre databinding et flux. Dans la pratique, le Get est identique au Dispatch, le Set a un Action et les data binding de type simple au Store. Je ne vois aucune difference technique a part le choix des termes.
Je ne pense pas que tu puisse avec Fyne generer un cycle, car l'ui ne va generer un changement dans le data binding que si celui-ci est le resultat d'une action de l'utilisateur. Donc un changement dans le data binding, va faire une mise a jour de l'ui, mais l'ui ne va pas generer de mise a jour du data binding apres ce changement.
Par contre, effectivement, il y a des possibilites de change after view (si j'en comprend bien ce que tu decris), si il y a une entree utilisateur sur l'ui au meme moment que le data binding decide de faire un changement. Mais dans ce scenario, le data binding propagera tout de meme l'entree utilisateur ce qui laisse la possibilite au data binding de resoudre le conflit. Du coup, dans le cas d'un protocol reseau, on s'attenderait a ce que cela soit gerer dans le backend.
Dans les toolkit graphique, tout redessiner est très couteux, on gère donc des modifications qui deviennent un enfer à tenir cohérent.
C'est vrai uniquement dans le cadre de la famille des toolkit graphiques "immediate". Les toolkit graphiques "retained" se souviennent en permanence de ceux qu'ils ont construit pour les frames precedentes. Ils sont alors capable de faire un delta entre le buffer que le systeme leur donne et ce que l'application veut afficher a l'ecran. Cela va plus loin que ceux que les framework web peuvent faire, car on a du recyclage de buffer video (prive a l'application). C'est a dire que lorsque un buffer a ete affiche a l'ecran on peut le reutiliser. Pas la peine d'en effacer le contenu. On peut, donc calculer les zones de l'ecran qui ont change et ne redessiner que ce qui est necessaire. Bien entendu, les framework "retained" vont pouvoir aussi memoriser le contenu des differents trucs couteux a rendre a l'ecran et les stocker dans un cache associer aux objets a afficher. Comme ceux-ci reste en vie aussi longtemps qu'on en a besoin, la gestion des caches est simplifies et optimales. Enfin comme les framework "retained" ont une vision globale de la scene qu'ils ont a rendre, ils peuvent optimiser le "clipping" des objets a peindre/calculer pour limiter la consommation de CPU et bande passante.
Il est bien entendu possible pour une application qui fait du rendu immediat d'implementer tout cela, mais c'est beaucoup de boulot comme tu le fais remarquer qui a mon sens a plus sa place dans le toolkit que dans l'application.
Les data bindings de Fyne sont plutot insipire du systeme MVVM ( https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel ). L'idee est de connecter les elements de l'interface a un databinding. Celui-ci peut etre "un proxy"/ViewModel est alterer/combiner les valeurs d'un autre data binding.
Un exemple pour en expliquer le principe, c'est d'avoir un data binding StringWebSocket, qui recupere juste une chaine de charactere via WebSocket. Celui ci peut etre connecte a un JSonString data binding. Imaginons qu'on veut recombiner des champs de ce JSON pour en faire une autre chaine de charactere, du coup on utilise un data binding Sprintf qui prend en parametre les fils de ce data binding JSON. Enfin, on peut connecter cette chaine de charactere a un label qui affichera le resultat de toute cette chaine.
Evidement, si tu veux faire du HTTP, MQTT, ou quelques protocoles que ce soit, tu ne changes que le type du data binding en debut de chaine. Il est possible de coder son propre data binding. Un exemple d'une telle chaine de logique: https://github.com/fynelabs/mqttweather/blob/main/weather.go#L72 .
Pour ce qui est de l'optimisation du framework, c'est l'avantage a mon sens principal des framework en mode "retained" (aucune idee de comment traduire) par rapport a ceux "immediate". En mode "retained", tu as en permanence un etat de ce qui a etait envoye a l'ecran (techniquement sous Linux, tu as interet a te souvenir des 2 dernieres frames) et tu ne mets a jour que ce qui a change entre le buffer que le systeme t'a donne et ce que l'application veut afficher a un moment donnee. Cela veut aussi dire qu'il est plus facile de maintenir un cache qui a du sens, car toutes les donnees deja calcule sont attache aux objets present dans l'interface et leur cycle de vie est gere par le framework graphique de maniere transparente. Bien entendu, si on passe dans une bibliotheque avec une logique "immediate", il faut faire tout cela soi meme.
Absolument, si les dependences sont disponible statiquement, il n'y a pas de raison. La problematique est probablement une question de license pour les bindings. Mais dans le cadre de l'ecosysteme Go, les projets pure go font attention a prendre des licenses qui ne posent pas ce probleme. C'est le cas pour Gio UI et Fyne, dont les applications sont contenu dans un binaire unique pour toutes les plateformes supportes (BSD, Linux, Mac, Windows, iOS et Android).
Que l'implémentation de l'avx512 ne soit pas super utilisable, car faisant chuter les performances globales est un problème. Mais combien de logiciel sont optimisé pour du vectoriel? Même l'avx2 ou néon, c'est marginal. Les compilos n'arrivent que marginalement à générer du code vectoriel. Et ce n'est pas mieux avec opencl dont la portabilité est fun, sans compter la plaie d'avoir a transférer les données entre les deux environnement de développement.
Intel pense encore être le seul fournisseur de hardware et que tous les développeurs de la planète vont avoir le temps d'optimiser pour ses plateformes spécifiquement. On dirait qu'ils n'ont pas remarqué que la majorité des codes qui tournent sur nos machines ne sont pas écrit en assembleur spécifiquement pour Intel. Résultat leur machine sont chroniquement sous utiliser.
Au lieu de se pencher sur comment écrire du code vectoriel portable, on en est encore à devoir tout écrire à la main. Et le plus terrible dans l'histoire, c'est qu'Intel tenait un bon début de théorie avec ispc, le compilateur spmd. Mais il devrait bosser à ajouter une infrastructure spmd à go, rust et faire que les implémentations comme cppspmd soit utilisable et utilisé.
Ca fait plus de vingt ans qu'on a des jeux d'instructions vectorielles dans l'informatique grand publique et on commence tout juste à avoir la technologie pour les utiliser, mais faut pas compter sur les fournisseurs de hardware.
Perso, c'est l'inverse qui me choque. 32 bits pour des instructions simples? Ils sont au courant que la latence et bande passante mémoire, ca ne suit pas la loi de Moore? L'existence de l'extension c, c'est plus tôt, un oops, on n'avait pas fait attention au perf. C'est pas comme si on avait quelques décennies de connaissance sur le sujet.
L'autre point problématique c'est la licence et les brevets sur la spec. Il n'y a rien qui garantit que qui que ce soit qui contribue à la spec n'a pas un brevet sur le sujet dans un coin (et rien qui les forces à fournir une implémentent libre de brevet pour une implémentation libre). Comme projet, pour un gros constructeur, c'est une bonne option vu qu'ils ont probablement de quoi se défendre, mais pour les plus petit et le logiciel libre, c'est pas garantit.
Après toutes les start-up autour de risc v ont réussi à lever pas mal de fond, donc ca va continuer d'avancer et l'écosystème est probablement robuste, suffisamment pour faire stresser arm.
Je pense qu'il n'y a aucun intérêt à tester Tizen, car l'os est à peine maintenu pour être par qui que ce soit d'autre que Samsung. Par contre, en terme de perf, toutes les performances graphique de Tizen viennent de l'utilisation de enlightenment, et ca, c'est libre et disponible sur toutes les bonnes distributions. Le mode wayland devant marcher correctement et doit avoir de meilleur performance que weston, mais je n'ai pas encore pu tester, car je n'ai pas recu mon pinebook pour l'instant… Je ferais mes expériences la semaine prochaine.
Je viens de commander le mien, mais j'ai une question à laquelle je n'ai pas réussi à trouver de réponse. Est ce qu'il y a un accélérateur hardware pour la composition sans utilisation du gpu (drm hardware layer)?
En gros, est ce que tu sais si l'accélération avec wayland est du uniquement au gpu ou alors aussi à un compositeur hardware? Si le compositeur hardware existe, mais n'est pas utilisé il y a encore de la marge en terme d'amélioration des performances et de l'autonomie. En plus des optimisations néon qui ne sont pas présente dans beaucoup de soft.
Et sinon arch linux, tu recommandes sur le pinebook pro?
D'apres les etudes que j'ai vu venir d'Asie, il suffit de rester suffisament longtemps dans un courant d'air entre le point ou l'air est injecte, une personne malade meme asymptomatique et toi (la personne contaminante etant juste en amont du vent pour toi). Et le temps semble etre une fonction de la charge virale de la personne contaminante. Mais bon, il y a des exemples ou les convives d'un restaurant sous le vent d'une personne contaminante ou tous etaient contamine en un repas (Par contre pas le staff qui lui n'etait pas expose a la circulation de l'air dans la configuration de ce restaurant). Du coup, etre au bureau avec la clim, ce n'est pas une bonne chose si il y a quelqu'un de malade entre toi et la clim…
Du coup, 100% d'air exterieur, ca aide, mais pas tant que ca.
C'est tres frequent comme technologie en amerique du nord. En gros, tu as une chaudiere centrale qui chauffe de l'air qui est ensuite injecte partout dans le batiment. C'est assez mauvais comme technique en terme d'efficacite energetique, mais en coup de deploiment, c'est pas chere. Par contre, ca cree des courants d'air qui peuvent porter le virus…
Et la clim, tout comme les systèmes de chaleurs à air forcé, est responsable de beaucoup de cas de transmission de covid19. On va le voir rapidement dans les états comme le Texas. Vaux mieux avoir chaud seul cet été que frais à plusieurs.
[^] # Re: Trop simple ?
Posté par cedric . En réponse au journal Interface graphique en Go!. Évalué à 4.
Cela n'a pas la meme fonction et n'a pas non plus les memes impacts. Tout d'abord, l'objectif d'une telle optimisation base sur le n-buffering est de sauver de la bande passante. Compare au double DOM qui lui tente de sauver des performances lors de la traverse de la barriere JS/DOM (qui est necessaire, car les appels au DOM stop les optimisations de type JIT). Il n'y a pas d'amelioration de bande passante memoire ni de reduction de ce qui va etre rendu a l'ecran. Cela evite juste de faire des appels qui n'auraient du rien coute, mais qui coute dans le monde web. C'est aussi pour ca que l'implementation dans les navigateurs web d'un double DOM n'aurait pas d'impact sur les performances des applications JS.
De plus, les boundings box, c'est des objets tres sympa, ca tiens sur 4 entiers et un booleen. Tu peux les utiliser directement dans le GPU. Et enfin, tu n'as pas besoin de les reallouer entre deux frames, car elles sont tres facilement reutilisable. Tu peux optimiser ta structure memoire pour qu'elle soit bien lineaire et que les cache memoire apprecie. Pour plus de lecture: https://raphlinus.github.io/rust/graphics/gpu/2022/02/24/piet-gpu-clipping.html .
Enfin tu pourras en conclure que un navigateur web, meme si il fait du rendu d'un truc qui utilise react, aura toujours a gagner a implementer des optimisations de type n-bufferring. Et le double DOM serait probablement moins utile si il etait possible de faire des appels DOM directement depuis le code JIT au lieu de repasser en mode interprete.
[^] # Re: Trop simple ?
Posté par cedric . En réponse au journal Interface graphique en Go!. Évalué à 3.
React evite de construire des objets DOM, pas des objets JavaScript. Ceux-ci existent et consomme des ressources. Ils peuvent etre recycle sous certaine condition probablement, mais globalement, ca va passer par des cycles de GC.
[^] # Re: Trop simple ?
Posté par cedric . En réponse au journal Interface graphique en Go!. Évalué à 4.
Le double buffering, c'est juste sur le contenu du buffer graphique. C'est principalement utilise pour eviter les problemes de synchronisation avec l'ecran. L'idee, c'est que tu peux travailler dans un buffer pendant que le deuxieme buffer est pousse a l'ecran.
Theoriquement on devrait pouvoir se passer completement de ce buffer supplementaire qui impact la latence pour afficher ce qui ce doit au plus pres du moment ou le contenu va arriver a l'ecran. Tu as toujours au moins une latence de 16ms a 60Hz, mais ca peut varier car il n'y a pas de synchronisation explicite dans la chaine de rendu et du cout les applications travaillent souvent avec en fait 3 buffers. Pour une petite introduction sur le sujet: https://github.com/ishitatsuyuki/LatencyFleX . Aucun toolkit a ma connaissance n'en est la pour l'instant.
Maintenant, pour Wayland et dans certain cas sous X11, tu peux te retrouver a travailler dans le buffer que tu avais presente a l'ecran il y a 2 frames. Du coup, tu peux, si tu as une idee des changements qui ont eu lieu, faire un delta et uniquement toucher les morceaux du buffer qui ont change. Pour faire ce delta, tu ne travaille pas au niveau des pixels, cela serait trop couteux, mais au niveau des boundings box des primitives graphiques qui composent la scene que tu dois rendre. En regardant quel bounding box a visiblement change depuis les 2 ou 3 dernieres frame, tu peux construire un "masque" des zones a redessiner. Mais cela s'applique uniquement a Linux, les autres ecosystemes n'ont pas cette fonctionnalite et ne permettent pas de connaitre l'age d'un buffer. Du cout, peu de toolkit graphique implemente cette optimisation. Cela n'est peut etre plus vrai avec Vulkan, mais je n'en suis pas certain.
[^] # Re: Trop simple ?
Posté par cedric . En réponse au journal Interface graphique en Go!. Évalué à 4.
Techniquement, tous ces toolkits sont en go. Ca veut dire que tu as un GC et si tu remplace le contenu d'un conteneur par un autre arbre de widget, celui-ci fera exactement la meme chose qu'en react. Maintenant, je ne pense pas que ce soit un bon pattern pour l'usage de ces API, car cela implique de creer/detruire pas mal d'objet.
Meme avec un systeme optimise, cela a un cout qui impact les performances. Dans ton exemple, c'est probablement negliegable voir meme pas mesurable. Mais comme pattern generaliste, cela a clairement un impact sur les performances. La premiere limite d'un systeme aujourd'hui, c'est sa bande passante memoire. Creer/detruire/acceder de la memoire a tout bout de champs pour pas grand chose a un impact sur les performances non negligeable.
Ainsi une API dans laquel on va juste rendre invisible explicitement le button sera plus efficace qu'une dans laquelle on va soit traverser un arbre ou parser une commande pour decider de rendre invisible ou detruire un button. Je trouve aussi que cela a tendance a mixer code definissant l'interface et logique du programme, cela veut dire que collaborer avec un designer n'est pas forcement trivial. Je pense qu'on peut faire mieux que ca.
[^] # Re: Trop simple ?
Posté par cedric . En réponse au journal Interface graphique en Go!. Évalué à 3.
Non, j'expliquais comment fonctionne react et pourquoi il fonctionne comme ca. Tu n'as pas besoin d'avoir un shadow DOM ou equivalent quand tu fais du natif, car tu n'as pas ces barrieres couteuses.
Dans le cadre d'un toolkit natif, tu as deux morceaux, l'API de widget et la logique de rendu de ces widgets a l'ecran. Dans une API de type "immediat", tu vas avoir un evenement de type "paint" a chaque frame qui va te demander de redessiner le contenu de ton widget. La complexite du rendu est donc deporte dans le widget, voir l'application (cela depend de l'API du widget). Dans une API de type "retained", le code du widget modifie des primitives sur le canvas et c'est le canvas qui va alors voir si il y a un changement lors de la prochaine frame. Ca donne plus de possibilite d'optimisation, car le canvas a une vue globale de ce qu'il y a a faire.
Globalement, dans ces deux cas, tu peux faire des optimisations de type shadow DOM, ce qui limitera les appels sur les API des widgets. Dans le cas d'une API de type immediat, cela payera probablement. Par contre dans le cas, d'une API "retained", c'est tres peu probable voir l'inverse, car cela va augmenter la consommation de memoire et donc la consommation de bande passante qui est la principale ressource limitante pour une application native.
[^] # Re: Trop simple ?
Posté par cedric . En réponse au journal Interface graphique en Go!. Évalué à 4.
Quel est l'interet de dupliquer en memoire une information qui ne sera pas utiliser pour realiser le contenu de l'application a l'ecran? Quel est l'interet de calculer le delta de quelques choses qui sera ignore au final?
React et vue existe et on du sens dans le monde du DOM et du web. Car dans cette univers, tu as un document dont il est couteux de faire une modification et la barriere DOM / JS est lente. Le cout de modification d'une entree du DOM en JS n'est pas juste l'assignation d'une valeur et generalement pas en O(1). Dans cette univers, il est necessaire d'eviter de modifier la representation de ce qui doit etre redessiner pour des questions de performance. Il est donc necessaire pour un framework JS d'implementer une technique "retained" en interne pour avoir de bonne performance.
Dans le cas du natif, ce probleme de barriere DOM/JS et de performance de rendu n'est plus. Une API efficace native peut exposer que des operations qui sont relatif au rendu de la fenetre (Il n'est pas necessaire de maintenir l'etat de ce qui n'est pas l'ecran). Les acces a toutes les fonctions qui modifie le rendu peuvent etre en O(1) et negligeable en terme de cout d'utilisation (plusieur millier d'appel par frame, ne doivent declencher que un seul calcul par frame et idealement sans jamais bloquer un seul de ces appel).
Ceux sont des differences fondamentales entre les contraintes web et les contraintes natives.
[^] # Re: Trop simple ?
Posté par cedric . En réponse au journal Interface graphique en Go!. Évalué à 4. Dernière modification le 06 mars 2022 à 18:56.
J'ai du mal a comprendre la question. Un lock, c'est pour eviter un acces simultane en ecriture/lecture et eviter une race condition. Les contentions, c'est une question de nombre d'acces et de chance eleve d'avoir le lock deja pris quand on accede a la dite valeur. On peut avoir besoin d'un lock parce que on a une donnee qui est lu une fois lorqu'elle change par frame et qui sera ecrite souvent a la vitesse d'une IO. Mais clairement, cela ne causera pas de probleme de contention.
Un pool de thread systeme est cree et matche le nombre de core disponible. Chaque goroutine sera alloue individuellement, aura sa propre stack et sera schedule en fonction des capacites/de la demande sur un thread systeme approprie. Il y a un tres faible controle de la part de l'application sur ou va etre execute une goroutine. Le scheduler essaye de faire de son mieux pour eviter de changer de CPU et enchainer les executions de goroutine pour eviter d'avoir une goroutine bloque sur une autre trop longtemps (L'ecriture dans un channel est souvent le point de logique qui va declencer un changement de goroutine si il y a une goroutine en attente sur le channel en question).
Ca date un peu, mais c'est encore tres vrai un petit tour des limites de go avec pas mal sur le sujet des goroutines : https://tpaschalis.github.io/reaching-the-ceiling-of-single-instance-go/ . Et pour un cas pratique d'optimisation avec go: https://www.freecodecamp.org/news/million-websockets-and-go-cc58418460bb/ .
[^] # Re: Mais ou est l'innovation ???
Posté par cedric . En réponse au journal Interface graphique en Go!. Évalué à 5.
Cet phrase n'a que tres peu de sens. Les data binding sont un mecanisme qui permet de connecter un element graphique a une source de donnees. Le QML est quand a lui un user interface markup language destine a decrire le design et les interactions graphiques de l'application, idealement on ne met pas le code de l'application dans le QML. Ce n'est pas le seul et c'est un concept qui a plusieurs decennie maintenant: https://en.wikipedia.org/wiki/User_interface_markup_language .
L'inconvenient des UIML, c'est qu'il reflete l'intersection entre le canvas graphique utilise et le language auxquel il se connecte, avec des fois une contrainte supplementaire quand ils sont utilise pour definir le theme des widgets, de correspondre a la logique interne des dits widgets. Cela veut dire globalement que chaque UIML est unique et que meme l'introduction de CSS a la GTK, reste un CSS a la GTK qui a peu a voir avec le CSS du web vu que chacun utilise un canvas graphique different. Introduire un nouveau language est tres risque et il faut en avoir le besoin. Les UIML sont principalement utilise quand des interfaces tres customise sont developpe, mais une tres large partie des applications n'en utilisent pas.
L'approche de Fyne et Gio pour est de se baser sur Material Design ( https://material.io/ ). Cela veut dire que la capacite de changer le theme est defini par ce que la specification de material design autorise. Evidement, il y a moins de flexibilite et il n'y a pas besoin de developper un UIML pour ces toolkits. En contre partie, une application aura rapidement un look correct meme quand on n'a pas une grosse equipe pour faire le design.
J'avoue ne pas comprendre le sens de cette phrase, mais pour faire simple un framework moderne se doit de faire une abstraction total du driver utilise. C'est une necessite pour la portabilite, mais cela permet aussi de changer completement la logique interne pour s'adapter a de nouvel API graphique.
J'avoue que cette phrase aussi, je n'arrive pas a la comprendre. Le CSS et la typograhie sont des problemes assez orthogonaux. Wikipedia est en plus l'exemple ideal de quand utilise les technos web, car c'est de la pur documentation avec des hyper liens.
[^] # Re: Mais ou est l'innovation ???
Posté par cedric . En réponse au journal Interface graphique en Go!. Évalué à 4.
Je n'ai pas regarde pour Gio, mais pour fyne la liste des widgets et completement documente:
https://pkg.go.dev/fyne.io/fyne/v2/widget#List
https://pkg.go.dev/fyne.io/fyne/v2/widget#Table
https://pkg.go.dev/fyne.io/fyne/v2/widget#Tree
[^] # Re: Trop simple ?
Posté par cedric . En réponse au journal Interface graphique en Go!. Évalué à 5.
Si on ne parle pas d'API, cela veut dire qu'on parle uniquement de comparer un systeme qui utilise des locks vs un systeme qui utilise une queue. Dans le cas, qui nous concerne, pour l'implementation de fyne, il n'y a pas de data race, pas d'allocation, et les locks ne sont pas sous contention et donc se comporte comme deux appels atomics successif par lecture/ecriture sur le meme CPU. Techniquement, cela veut dire que le premier atomic va, en pire cas, declencher un vidage de cache dans les autre core du CPU pour obtenir la propriete de la memoire pointe par l'acces atomique. Comme il n'y a pas de contention, aucun autre CPU ne declenchera une perte du cache du core et le second acces sera equivalent a un acces memoire directe sans cout particulier. Ce sera cela le cout d'un lock dans ce scenario.
Maintenant, si tu prend une queue ideale, tu peux te retrouver avec une implementation qui a un seul appel a un atomic par ecriture/lecture dans la queue (CAS ou atomic sont equivalent en terme de cout, donc pas tres important). Par contre, tu es oblige d'allouer de la memoire ou de travailler de maniere bloquante. Dans le cas ideal, disons que tu pars du principe qu'il n'y a pas de contention non plus sur les acces a ta queue et que tu peux te permettre d'avoir juste une seule entree, donc pas non plus de probleme d'allocation memoire. Tu te retrouve exactement dans le cas precedent, un atomic pour faire l'ecriture avec une perte de cache dans les autres core. Par contre par design, tu as probablement plus de chance, comme tu as plus de thread dans ce design, de te retrouver avec la requete d'acces suivante sur un autre core et donc declenche une perte de cache.
Au final, un lock vs une queue dans le cas sans contention sont au mieux equivalent au pire au desaventage d'une queue. Maintenant si on n'est plus dans le cas sans contention, mais dans un cas avec contention, ce que je viens de dire n'est plus valable et le profile de performance sera different. Mais dans le cas de Fyne, il n'y a pas de contention du fait de l'API et de son usage.
Pour revenir sur le sujet du deep copie, c'est bien parce que quoi qu'on fasse, c'est une operation couteuse dans tous les languages et qu'il vaut mieux l'eviter autant que possible. De maniere generale, la contrainte, c'est toujours la bande passante memoire, un seul core peut facilement saturer toute ta bande passante memoire et il faut y faire attention. En forcant le developpeur a etre conscient des couts sans cacher les operations, le go renforce cette affirmation. Et reflexion et rtti sont des operations encore plus lente qu'il vaut mieux eviter en generale. Pas uniquement en go, mais dans tous les languages.
Pour ce qui est du proxy, c'est une possibilite. Mais franchement quel est le probleme que tu essaie de resoudre? Le systeme garde deja pour toi une copie des etats graphiques (uniquement ce qui a finit a l'ecran). Pas la peine de garder l'ensemble des widgets et d'en faire une copie si ceux ci ne finissent pas sur l'ecran. La memoire du delta ne sert pas a grand chose pour ca. Je pense qu'il y a un biais dans ta reflexion du a la mechanique utilise par les navigateurs web pour faire leur rendu. Ceux-ci sont bien plus proche des systemes de rendu immediat du fait de la complexite historique de leur tache. Du coup, on a rajoute des framework en JS pour essayer d'aider les navigateurs web a faire leur boulot. Ce n'est pas un probleme pour les toolkits natifs et c'est globalement devenu un standard de faire du "retained" pour la majorite d'entre eux. Il n'y a pas de besoin pour les utilisateurs de se poser se genre de problematique. Les API pour modifier les widgets sont en O(1) et le systeme ne fera un calcul de delta entre frame que lorsqu'une nouvelle frame pourra etre pousse a l'ecran.
[^] # Re: Trop simple ?
Posté par cedric . En réponse au journal Interface graphique en Go!. Évalué à 5.
Une des regles principales de l'ecosysteme est de faire des API synchrones avec une gestion des erreurs explicites et laisser la decision de parallelisme a l'appelant. De plus, il est recommender d'eviter autant que possible d'utiliser les channels dans une API, car leur type ne permet pas a la lecture du prototype de savoir comment les utiliser pour synchroniser deux morceaux de code (buffer/unbuffered et blocking function ne sont pas dans le prototype). Du coup, l'utilisation des channels est plutot quelques choses d'interne.
De plus, meme si les channels sont tres optimise en Go, leur cout n'est pas nul. Aussi bien en memoire que CPU. Et comparer a un lock qui quand il n'est pas un point de contention, se comporte comme un atomic, il y a une difference assez importante en terme de performance.
Enfin comme tu peux le voir, il n'y a pas de besoin de synchronisation pour tous les utilisateurs de cette API, seul les developpeurs des data bindings de type simple ont du prendre cela en consideration. Cela rend l'utilisation de l'API simple et efficace avec aucune allocation memoire une fois que le binding est construit.
Pour repondre a tes questions supplementaires concernant la copie profonde, cela n'existe pas dans le language, car cela transformerait une affectation O(1) en une complexite inconnue. Cela veut dire que la copie profonde est a implementer manuellement et explicitement de maniere a bien en voir le cout (et du cout, on evite de faire des copies autant que possible :) ). Il n'y a pas de structure immutable en Go, uniquement des champs publiques ou prives (mais une fois qu'il y a des champs prives, il est impossible de juste copier une structure, il faut fournir une fonction pour pouvoir le faire).
[^] # Re: Trop simple ?
Posté par cedric . En réponse au journal Interface graphique en Go!. Évalué à 4.
J'essaye de reflechir un peu plus au sujet, et je ne suis pas sur qu'il y ait grande difference sur le sujet en fait. Tout d'abord, les locks avec go, c'est obligatoire (Ou une primitive de synchronization). Les developpeurs en go s'attendent a pouvoir appeler une API depuis n'importe quel goroutine a n'importe quel moment. Il faut qu'elle soit thread safe. Tu remarqueras d'ailleur que pour les developpeurs de data binding, ils n'ont en general pas besoin de lock.
Deuxiemement concernant la difference entre databinding et flux. Dans la pratique, le Get est identique au Dispatch, le Set a un Action et les data binding de type simple au Store. Je ne vois aucune difference technique a part le choix des termes.
[^] # Re: Trop simple ?
Posté par cedric . En réponse au journal Interface graphique en Go!. Évalué à 3.
Je ne pense pas que tu puisse avec Fyne generer un cycle, car l'ui ne va generer un changement dans le data binding que si celui-ci est le resultat d'une action de l'utilisateur. Donc un changement dans le data binding, va faire une mise a jour de l'ui, mais l'ui ne va pas generer de mise a jour du data binding apres ce changement.
Par contre, effectivement, il y a des possibilites de change after view (si j'en comprend bien ce que tu decris), si il y a une entree utilisateur sur l'ui au meme moment que le data binding decide de faire un changement. Mais dans ce scenario, le data binding propagera tout de meme l'entree utilisateur ce qui laisse la possibilite au data binding de resoudre le conflit. Du coup, dans le cas d'un protocol reseau, on s'attenderait a ce que cela soit gerer dans le backend.
[^] # Re: Trop simple ?
Posté par cedric . En réponse au journal Interface graphique en Go!. Évalué à 5.
C'est vrai uniquement dans le cadre de la famille des toolkit graphiques "immediate". Les toolkit graphiques "retained" se souviennent en permanence de ceux qu'ils ont construit pour les frames precedentes. Ils sont alors capable de faire un delta entre le buffer que le systeme leur donne et ce que l'application veut afficher a l'ecran. Cela va plus loin que ceux que les framework web peuvent faire, car on a du recyclage de buffer video (prive a l'application). C'est a dire que lorsque un buffer a ete affiche a l'ecran on peut le reutiliser. Pas la peine d'en effacer le contenu. On peut, donc calculer les zones de l'ecran qui ont change et ne redessiner que ce qui est necessaire. Bien entendu, les framework "retained" vont pouvoir aussi memoriser le contenu des differents trucs couteux a rendre a l'ecran et les stocker dans un cache associer aux objets a afficher. Comme ceux-ci reste en vie aussi longtemps qu'on en a besoin, la gestion des caches est simplifies et optimales. Enfin comme les framework "retained" ont une vision globale de la scene qu'ils ont a rendre, ils peuvent optimiser le "clipping" des objets a peindre/calculer pour limiter la consommation de CPU et bande passante.
Il est bien entendu possible pour une application qui fait du rendu immediat d'implementer tout cela, mais c'est beaucoup de boulot comme tu le fais remarquer qui a mon sens a plus sa place dans le toolkit que dans l'application.
[^] # Re: Go with C
Posté par cedric . En réponse au journal Interface graphique en Go!. Évalué à 5.
Elle est encore tres centrale pour la majorite des toolkits graphiques natif aujourd'hui. Qt et GTK pour ne citer qu'eux en sont un exemple.
[^] # Re: Trop simple ?
Posté par cedric . En réponse au journal Interface graphique en Go!. Évalué à 3.
J'aimerais bien que tu expliques pourquoi tu penses qu'un 2 way data bindings consomme enormement de ressource par rapport a flux? Pour reference, un exemple avec le data binding MQTT de Fyne: https://github.com/fyne-io/fyne-x/blob/master/data/binding/mqttstring.go
[^] # Re: Trop simple ?
Posté par cedric . En réponse au journal Interface graphique en Go!. Évalué à 7. Dernière modification le 04 mars 2022 à 22:46.
Les data bindings de Fyne sont plutot insipire du systeme MVVM ( https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel ). L'idee est de connecter les elements de l'interface a un databinding. Celui-ci peut etre "un proxy"/ViewModel est alterer/combiner les valeurs d'un autre data binding.
Un exemple pour en expliquer le principe, c'est d'avoir un data binding StringWebSocket, qui recupere juste une chaine de charactere via WebSocket. Celui ci peut etre connecte a un JSonString data binding. Imaginons qu'on veut recombiner des champs de ce JSON pour en faire une autre chaine de charactere, du coup on utilise un data binding Sprintf qui prend en parametre les fils de ce data binding JSON. Enfin, on peut connecter cette chaine de charactere a un label qui affichera le resultat de toute cette chaine.
Evidement, si tu veux faire du HTTP, MQTT, ou quelques protocoles que ce soit, tu ne changes que le type du data binding en debut de chaine. Il est possible de coder son propre data binding. Un exemple d'une telle chaine de logique: https://github.com/fynelabs/mqttweather/blob/main/weather.go#L72 .
Pour ce qui est de l'optimisation du framework, c'est l'avantage a mon sens principal des framework en mode "retained" (aucune idee de comment traduire) par rapport a ceux "immediate". En mode "retained", tu as en permanence un etat de ce qui a etait envoye a l'ecran (techniquement sous Linux, tu as interet a te souvenir des 2 dernieres frames) et tu ne mets a jour que ce qui a change entre le buffer que le systeme t'a donne et ce que l'application veut afficher a un moment donnee. Cela veut aussi dire qu'il est plus facile de maintenir un cache qui a du sens, car toutes les donnees deja calcule sont attache aux objets present dans l'interface et leur cycle de vie est gere par le framework graphique de maniere transparente. Bien entendu, si on passe dans une bibliotheque avec une logique "immediate", il faut faire tout cela soi meme.
[^] # Re: Go with C
Posté par cedric . En réponse au journal Interface graphique en Go!. Évalué à 4.
Absolument, si les dependences sont disponible statiquement, il n'y a pas de raison. La problematique est probablement une question de license pour les bindings. Mais dans le cadre de l'ecosysteme Go, les projets pure go font attention a prendre des licenses qui ne posent pas ce probleme. C'est le cas pour Gio UI et Fyne, dont les applications sont contenu dans un binaire unique pour toutes les plateformes supportes (BSD, Linux, Mac, Windows, iOS et Android).
# Le problème de l'avx, c'est l'arrogance d'Intel et l'absence de redirection sur le développement log
Posté par cedric . En réponse au journal Le début de la fin pour Intel ?. Évalué à 6.
Que l'implémentation de l'avx512 ne soit pas super utilisable, car faisant chuter les performances globales est un problème. Mais combien de logiciel sont optimisé pour du vectoriel? Même l'avx2 ou néon, c'est marginal. Les compilos n'arrivent que marginalement à générer du code vectoriel. Et ce n'est pas mieux avec opencl dont la portabilité est fun, sans compter la plaie d'avoir a transférer les données entre les deux environnement de développement.
Intel pense encore être le seul fournisseur de hardware et que tous les développeurs de la planète vont avoir le temps d'optimiser pour ses plateformes spécifiquement. On dirait qu'ils n'ont pas remarqué que la majorité des codes qui tournent sur nos machines ne sont pas écrit en assembleur spécifiquement pour Intel. Résultat leur machine sont chroniquement sous utiliser.
Au lieu de se pencher sur comment écrire du code vectoriel portable, on en est encore à devoir tout écrire à la main. Et le plus terrible dans l'histoire, c'est qu'Intel tenait un bon début de théorie avec ispc, le compilateur spmd. Mais il devrait bosser à ajouter une infrastructure spmd à go, rust et faire que les implémentations comme cppspmd soit utilisable et utilisé.
Ca fait plus de vingt ans qu'on a des jeux d'instructions vectorielles dans l'informatique grand publique et on commence tout juste à avoir la technologie pour les utiliser, mais faut pas compter sur les fournisseurs de hardware.
[^] # Re: À suivre
Posté par cedric . En réponse au journal Sifive Hifive 1 revision B - Présentation de la carte - episode 1. Évalué à 4.
Perso, c'est l'inverse qui me choque. 32 bits pour des instructions simples? Ils sont au courant que la latence et bande passante mémoire, ca ne suit pas la loi de Moore? L'existence de l'extension c, c'est plus tôt, un oops, on n'avait pas fait attention au perf. C'est pas comme si on avait quelques décennies de connaissance sur le sujet.
L'autre point problématique c'est la licence et les brevets sur la spec. Il n'y a rien qui garantit que qui que ce soit qui contribue à la spec n'a pas un brevet sur le sujet dans un coin (et rien qui les forces à fournir une implémentent libre de brevet pour une implémentation libre). Comme projet, pour un gros constructeur, c'est une bonne option vu qu'ils ont probablement de quoi se défendre, mais pour les plus petit et le logiciel libre, c'est pas garantit.
Après toutes les start-up autour de risc v ont réussi à lever pas mal de fond, donc ca va continuer d'avancer et l'écosystème est probablement robuste, suffisamment pour faire stresser arm.
[^] # Re: Et Tizen ?
Posté par cedric . En réponse au journal 1er retour sur le Pinebook pro. Évalué à 3.
Je pense qu'il n'y a aucun intérêt à tester Tizen, car l'os est à peine maintenu pour être par qui que ce soit d'autre que Samsung. Par contre, en terme de perf, toutes les performances graphique de Tizen viennent de l'utilisation de enlightenment, et ca, c'est libre et disponible sur toutes les bonnes distributions. Le mode wayland devant marcher correctement et doit avoir de meilleur performance que weston, mais je n'ai pas encore pu tester, car je n'ai pas recu mon pinebook pour l'instant… Je ferais mes expériences la semaine prochaine.
# Hardware compositeur
Posté par cedric . En réponse au journal 1er retour sur le Pinebook pro. Évalué à 4.
Je viens de commander le mien, mais j'ai une question à laquelle je n'ai pas réussi à trouver de réponse. Est ce qu'il y a un accélérateur hardware pour la composition sans utilisation du gpu (drm hardware layer)?
En gros, est ce que tu sais si l'accélération avec wayland est du uniquement au gpu ou alors aussi à un compositeur hardware? Si le compositeur hardware existe, mais n'est pas utilisé il y a encore de la marge en terme d'amélioration des performances et de l'autonomie. En plus des optimisations néon qui ne sont pas présente dans beaucoup de soft.
Et sinon arch linux, tu recommandes sur le pinebook pro?
[^] # Re: Pourvu que ça dure
Posté par cedric . En réponse au journal Télétravail, premier pas vers une délocalisation générale ?. Évalué à 3.
D'apres les etudes que j'ai vu venir d'Asie, il suffit de rester suffisament longtemps dans un courant d'air entre le point ou l'air est injecte, une personne malade meme asymptomatique et toi (la personne contaminante etant juste en amont du vent pour toi). Et le temps semble etre une fonction de la charge virale de la personne contaminante. Mais bon, il y a des exemples ou les convives d'un restaurant sous le vent d'une personne contaminante ou tous etaient contamine en un repas (Par contre pas le staff qui lui n'etait pas expose a la circulation de l'air dans la configuration de ce restaurant). Du coup, etre au bureau avec la clim, ce n'est pas une bonne chose si il y a quelqu'un de malade entre toi et la clim…
Du coup, 100% d'air exterieur, ca aide, mais pas tant que ca.
[^] # Re: Pourvu que ça dure
Posté par cedric . En réponse au journal Télétravail, premier pas vers une délocalisation générale ?. Évalué à 2.
C'est tres frequent comme technologie en amerique du nord. En gros, tu as une chaudiere centrale qui chauffe de l'air qui est ensuite injecte partout dans le batiment. C'est assez mauvais comme technique en terme d'efficacite energetique, mais en coup de deploiment, c'est pas chere. Par contre, ca cree des courants d'air qui peuvent porter le virus…
[^] # Re: Pourvu que ça dure
Posté par cedric . En réponse au journal Télétravail, premier pas vers une délocalisation générale ?. Évalué à 2.
Et la clim, tout comme les systèmes de chaleurs à air forcé, est responsable de beaucoup de cas de transmission de covid19. On va le voir rapidement dans les états comme le Texas. Vaux mieux avoir chaud seul cet été que frais à plusieurs.