tao popus a écrit 775 commentaires

D’ailleurs une différence avec VMWare, qui pourrait avoir une incidence dans le contexte de Kubernetes : dans PVE les disques sont fortement lié à une VM, dans VMWare tu peux très facilement déplacer un disque d’une VM à une autre.

On peut assez facilement détacher un disque via l'interface puis, dans une autre VM l'attacher si c'est un disque physique, ou, si c'est un fichier disque, déplacer le fichier disque dans son dossier via shell, lui dire de le rescanner, il est alors automatiquement intégré.

Aussi, PVE n’a pas de DRS et beaucoup de chose sont « au niveau du host » : tu veux créer une VM il faut absolument lui dire sur quel host tu veux le faire par exemple.

On crée une VM sur un host, mais on peut très bien la déplacer à chaud et sans interruption d'un host à l'autre si on les met en cluster. Est-ce que l'on peut faire cela avec VMWare ?

Donc, comme dit ci-dessus, n'utilisant qu'un cpu, et le cpu du Cortex-A7 étant très légèrement inférieur (on peut dire équivalent), 1.9 DMIPS/Mhz à celui du Cortex-A8 2.0 DMIPS/Mhz. on devrait avoir des performances toute à fait raisonnables sur un AllWinner A10 ou R8 avec TIC-80, du moins sur les jeux simple (1 seul GPU), il faudra peut être un peu plus pour les jeux avec beaucoup de sprites et d'effets, mais ça n'est pas non plus ce qui est recherché en 1er sur TIC-80.

Au passage, la console Gameshell qui utilise un AllWinner-R16J (4cortex-A7) dont il était question ici https://linuxfr.org/news/construisez-et-programmez-votre-console-de-jeux-open-source possède visiblement TIC80 par défaut (la capture décran est le Tetris de TIC-80), il y a le logo pour leur version aussi pour la Clockwork Pi fabriqué par les mêmes comporte le Logo de TIC-80 dans la partie apps.

Des publicités, appelées « liens sponsorisés » sont également venu se glissé dans les recherches lorsque l'on tape une URL. Visiblement, ça n'est malheureusement pas écrit dans le changelog.

Pour les désactiver, il faut :
* Aller à l'url about:config
* rechercher la chaîne browser.newtabpage.activity-stream.showSponsoredTopSites
passé à faux/false les 2 entrées.

Pour parler plus technique, d'après l'Allwinner R8 est en fait un Allwinner A13 renommé, une version light du A10 réservé aux tablettes, c'est pour ça qu'il est déjà directement géré par le noyau Linux mainline, qui gère le A13 depuis longtemps, mais qu'il n'est pas mentionné. il gère moins de mémoire que les Allwinner A10 et A20 (512M au lieu de 2GB), il n'a également qu'un seul core Mali-400. n'a pas de G2D (un blitter 2D relativement limité), et c'est bien un VPU Cedar, ce qui en fait un chip intéressant pour la vidéo.

J'ai ensuite refait des tests avec TIC-80 sur ma Cubieboard-2 (et on arrive à la même conclusion sur n'importe quelle machine). Il n'utilise qu'un seul cœur, il est donc mono-thread et on doit arriver à des perfs identiques entre le Cortex A8 (processeur le plus puissant à son époque) d'un R8, et un seul Cortex-A7, plus récent, mais surtout orienté meilleur ratio calcul/énergie :

on a 2 DMIPS/Mhz pour le Cortex-A8 contre 1.9 pour le cortex-A7). Donc, au niveau du CPU, ça se vaut, l'A7 à été principalement une simplification et (donc par la même) une optimisation énergétique par rapport à l'A8. Probablement, en se basant sur l'expérience des Cortex-A9, et surtout Cortex-A5 sorti entre les deux ?

Donc le GPU (qui est le même, avec un cœur au lieu de 2), doit jouer en fonction du nombre de « sprites » ou de polygones à l'écran, mais cela devrait être, pour pas mal de jeux/démos de TIC-80, une expérience identique sur le AllWinner R8 et le AllWinner A20.

Au passage, presque hors sujet, mais, dans le mainline Mesa (sera dans la 20.3, d'ici à la fin du mois), les VBO (vertex Buffer Objet) ont été |intégrés pour la majorité des formats le mois dernier](https://gitlab.freedesktop.org/mesa/mesa/-/commit/12128fb1351eee6ec681039fe8483b3c39db7c8e) au pilote Lima pour ces GPU, ce qui devrait sensiblement améliorer les perfs (réductions des opérations à chaque tracés :) ).

J'ai jamais dit que c'était une source fiable à 100%, je suis le premier à critiquer sa méthode de travail.
Néanmoins c'est une source intéressante quand on sait séparer le bon grain de l'ivraie.

C'est tout le problème. Tu le cite, sans citer le bench, forcément tu n'aimes pas les liens qui permet de vérifier de quoi on parle, visiblement opposé à toute rigueur, la paroles en l'air étant un meilleur atout dans le sophisme :

Sinon pas besoin d'ajouter des liens sur Allwinner et de parler des pilotes ou du décodage vidéo. Ça ne fait qu'alourdir inutilement ta réponse.

Les liens intégrés alourdiraient plus la réponse que des paroles en l'air donc… Si déjà tu ne sais pas quelle est la différence entre un PC et un micro-ordinateur… (voir plus bas).

Sinon on s'en fiche totalement de big.LITTLE et des SoC Rockchip, ça n'a aucun rapport avec le sujet.
Je ne sais pas pourquoi tu es venu parasiter le sujet si cela ne t'intéresse pas…

Pour le jeu, pas mal de jeux Linux un peu anciens tournent sans problème… d'encore plus anciens portages, type Doom, également: C'est pas neuf, mais ça reste d'un autre niveau qu'animer des sprites comme sur un Amstrad ou Commodore des années 80 tout de même.

Doom à aussi des adaptation 8 bits sur les premier micro-ordinateurs des années 1980 (bien limités certes), Il tournait déjà sur PC (signifiant compatible IPM PC) dès 1993, 15 ans avant le premier Atom (2008.

Cela paraît peut être incroyable, mais techniquement, Tic-80 est beaucoup plus avancé que Doom. Il permet comme Doom d'afficher des polygones texturés mais que l'on peut faire tourner dans tous les sens. Doom utilisait une astuce, il n'y a pas de rotation sur l'axe z, il n'y a que des plans verticaux et horizontaux, et pas de rotation verticale de caméra, c'est un cas particulier qui simplifie énormément les calculs. Les personnages sont des images toujours face à la caméra (différentes images les représentes dans différentes positions), donc pas de calcul 3d, uniquement du zoom.

La première carte 3D grand public (encore un peu chère est la Matrox Mystique 220, 1997, mais le premier grand succès c'est la 3Dfx Voodoo Graphics, une carte spécialisée, où l'on reliait la sortie vidéo de la carte graphique principale et qui ensuite était reliée à l'écran, permettait d'afficher ses rendus 3d dans une fenêtre d'un bureau 2d calculé par la carte graphique, ou en plein écran.

Tic80 en plus des polygones texturés, affiche une grande quantité de sprites (plus précisément émulés par des polygones texturés ici, pour bénéficier de la puissance des GPU), ce qui aurait été impossible sur les PC de l'époque de Doom.

Sinon, le EeePC 901 utilise un chipset 945GME donc un GPU GMA 950. Je serais curieux de savoir comment il est géré sous Linux ? Est-ce que glmark2 fonctionne avec et quels sont ses résultats ?

Déjà tu entends quoi par PC ? parce que ce comme tu le cites les VIC20, C64 ou CPC464 affichaient déjà 16 couleurs simultanées.

Tu réponds par ce que je répond, en le contredisant en même temps, bravo, belle pirouette, j’espérai qu'on parlerait technique, qu'on ne s'arrêterait pas aux sophisme ici. ce qu'on appelle un PC, en informatique c'est un IBM PC ou compatible. Ce que je cite, ce sont des micro-ordinateurs comme je l'avait dit. Après pourquoi pas redéfinir tous les termes d'informatique pour le plaisir de dire n'importe quoi…

Ce que je dis c'est qu'assez rapidement vers mi-80 même ces appareils low-cost avaient au moins des palettes plus importantes que les 16 couleurs de ces fantasy consoles et que les consoles de salon avaient elles aussi davantage de capacités dès début 80.

Non, justement ça n'est pas ce que tu disais. Tu interprète de travers ce que disent les autres, mais également ce que tu dis, ça n'a peut d’intérêt, j'ai l'impression de perdre mon temps, j'arrête là.

Lua est l'un des langages de script les plus rapides et les plus légers, (l'opposé de js avec nodejs donc), il est beaucoup utilisé dans l'embarqué, dans les jeux vidéos (notamment dans les systèmes de plugins) et dans les systèmes à forte audience liés à internet.

Dans le domaine des applications/systèmes Openresty/luajit pairé à nginx qui est également assez utilisé pour les sites à très très fortes audience. Il est à l'origine fait par Alibaba, pour tengine, son fork de nginx dont certaines améliorations sont revenus dans le core de nginx, et était utilisé pour Taobao.

Mais en plus d'OpenResty, on peut aussi citer Mediawiki, le moteur de Wikipédia qui l'utilise comme principal langage de script. Le cache Redis C'est également, dans les services réseau, utilisé par PowerDNS, les outils d'analyse nmap et Wireshark

je sais pas si c'est normal ou une protection de ff, mais quelque soit le lien de cette page, quand je clic, je me retrouve en haut de la même page…

Il manque Olive-Editor, qui est vraiment bien, et le montage vidéo de Blender, qui est quasi-illimité, vu ce qui l'entoure.

Faux, de toute façon, les PC étaient alors inabordables pour la majorité des gens et étaient limités à 2 ou 4 couleurs…

Les micro-ordinateurs des années 80 (les ordinateurs utilisés par tout le monde), avait déjà des palettes de 8 couleurs (ZX Spectrum (1982), Oric 1 et Atmos (1984)), 16 couleurs (Vic-20 (1980 avait un mode bidouille 16 couleurs), MSX 1 (1983), Amstrad CPC (1984), etc…) ou plus (MSX 2, 1985, 256 couleurs parmi 512). Il y avait par contre en général des problèmes de proximité, et des processeurs vidéos (pour la gestion des sprites ou de cartes de blocs graphiques (comme pour les décors du TIC-80) plus ou moins avancés. et pas ou peu de processeurs graphiques (utilisé pour la copie de blocs ou des tracés géométriques). La véritable révolution étant l'Amiga, avec d'abord l'Amiga 1000 (1985, hors de prix), puis le 500 1987, abordable au grand public, qui possédaient des processeurs graphiques et vidéos avancés, mais n'avaient pourtant vraiment pas la puissance de microcontrôleurs d'aujourd'hui comme le STM32 (les Atmega 8 bits étant lui derrière).

On est quand même sur du dessin très simple : rotations à 90 degrés et étirements par des facteurs entiers pour les opérations les plus complexes.

A tiens, effectivement, la 80 ne fait plus que des mises à l'échelle en entier, c'est un peu dommage. j'avais fait un test où les mises à l'échelle n'était pas entières (mais toujours exactes au niveau du pixel).

Mais les opération d'affichage de sprites ou de copie de blocs d'images sont pour le moment plus efficaces, en utilisant des textures en OpenGL, déchargeant ainsi le CPU, qu'en copiant tout au CPU.

Et sinon, il y a également les fonctions tri (demo bananaparty) textri (demo textri),

Ah sinon, autre chose où il serait bon de me relire, je comparait le AllWinner A20, au R8, parce qu'assez proche, pour essayer d'évaluer sa puissance et non, pas pour dire qu'il était plus efficace. Hors l'Allwinner A20 à 2 cortex-A7 comme processeurs, orienté très très basse consommation (LITTLE), tandis-que le R8 à un Cortex-A8, deux générations plus anciennes donc, mais orienté vers plus de puissance de calcul. De la même façon le Rockchip RK3288 qui à cœurs Cortex-A17 (big, 32 bits orienté puissance de calcul), est plus puissant que le RK3328, 4*Cortex-A53, (LITTLE, 64 bits, orienté basse consommation), mais les big de sa génération (comme le RK3399) sont bien plus puissant.

C'est un peu dommage de ne pas bien lire, de surinterpréter et d'ajouter du bruit, ça ne va pas améliorer la lisibilité du fil de discussion.

Il n'y a pas vraiment d'API 2D généralisée, à la fois au niveau processeur graphique, pilote et système. L'utilisation d'OpenGL, reste donc la solution la plus efficace dans la majorité des cas, d'opération géométriques 2D. Surtout quand il s'agit de gérer de nombreux bitmap, de faire des zoom/rotation/translation avec transparence. Dans le pire des cas, Mesa le gérera très efficacement en logiciel avec LLVMpipe. La majorité des frameworks de ce genre, LÖVE et Godot (pour la 2D) compris choisissent donc cette solution, ça permet aussi de bénéficier des shaders pour certains effets.

Plein de supposition sur ce que je voulais dire, c'est intéressant. Il faudrait relire ce que j'ai écrit avant de supposer de ce que tu parlais et dont il n'a pas été question. C'est un peu navrant de ne pas pouvoir parler sereinement, de l'efficacité de telle ou telle solution, lorsque quelqu'un n'a qu'en tête les méfaits de windows, et que le reste devient déni. Je me contrefout complétement de windows et je n'ai pas envie de perdre de temps avec ce truc, il y a plein de choses à faire de mieux.

Quand j'ai commencé le sujet j'ai bien dit à cette époque il n'y avait pas de pilote, les générations suivantes, le GPU était un PowerVR, il n'y avait pas de pilote libre et il n'y en a toujours pas.

Sur le site indiqué, il n'y a pas les caractéristiques du R8, c'est donc une supposition, pas un fait, et c'est bien pour ça que j'ai dit :Je ne sais pas. Il n'y a pas forcément de corrélation entre les cœurs des puces graphiques et des microproceseurs, on trouve par exemple un Mali-400 2 cœurs sur un A64 (4*Cortex-A53, 64 bits, sur les 64b on voit plus généralement des Mali Txx ou Gxx).

Quant à Phoronix, autant les informations sur les évolutions sont parfois intéressante autant son porn-bench, ou un article sur deux on voit un titre du genre « une amélioration excitante », parce qu'un comparatif donne 2 % de plus dans 60% des cas et 1 % de moins dans d'autres soit très pertinent. Par plusieurs fois, les bench que j'ai vu, ARM vs x86, utilisaient des ARM de deux ou trois ans plus vieux, surtout quant il s'agissait de SBC de hackers. Dans ces conditions, je ne vois pas ce que ce genre de test apporte non plus. Je parlais ici de cas concrets, c'est à dire est-ce que c'est suffisamment réactif ou non pour être utilisable.

À part Diamondville, même Silverthorne (la série Z très basse conso) possède un GPU avec accélération 2D et 3D.

À l'époque du EEEpc701, comme déjà dit, il n'y avait pas de pilote pour Linux, l'Eeepc701 était un des premiers ordinateurs vraiment commerciaux sous Linux, avec distribution Xandros et un bureau un peu spécial pour son tout petit écran.

Le GMA900 propose du pixel shader, OpenGL ES est dispo dans Linux avec i915. Le manque d'accélération 2D n'est qu'une limitation des pilotes Windows, pas du matériel.

Je ne vois pas pourquoi tu nous parles de Windows on est sur Linuxfr et on parle de machines sous Linux ??? Je t'invite à relire le fil de la discussion depuis le début, j'ai l'impression que tu l'as lu en diagonale.

Déjà que je comprends pas pourquoi tu as commencé à parler des Atom alors que son netbook possède un Core-m de génération précédente.

Il comportait un processeur celeron m 900 à 630MHz, donc effectivement pas un Atom, mais pas non plus un core-m, j'ai mélangé, en tout cas un processeur vraiment lent, et n'importe quel ARM Cortex-A est plus rapide et j'en ai un sous le bureau pour confirmer. Les Atom qui ont suivit n'était pas des flèches non plus. j'ai pratiqué aussi sur un boîtier compact. Le truc à lâché rapidement, carte mère HS, mais c'est peut être un coup de malchance.

Bon, mais enfin, peu importe, pour revenir à nos moutons, j'ai compilé la dernière version de TIC-80 (il y a un problème à la détection des chemins include de GTK (utilisé uniquement pour le sélectionneur de fichier, mais j'ai contourné). Donc Tic-80 80, marche très bien sur AllWinner-A20 (Mali-400 MP2, je sais pas sirle R8 est MP1 ou MP2) avec le pilote libre Mali, sur un écran 800x600, en plein écran, bureau XFCE en désactivant le compositing. Avec l'état actuel du pilote ça a tendance à bouffer sur les perfs 3d des autres applis. ARM à fini par donner les docs des GPU aux développeurs du pilote Panfrost, je ne sais pas si ils ont donné les docs des premières séries pour Lima ?

J'ai essayé avec WITCHEM UP, WCQ NO.6 et la démo BANANAPARTY!.

Le Cortex-A8 à 1 GHz intégré à un SIMD, il est aidé par un processeur 2D, capable de géré 4 calques et de l'alpha blending + des effets, il y a un GPU 3D ARM Mali 400 et un décodeur vidéo x264,VP8,AVS, sur le AllWinner R8. Le Mali 400 est géré sous Linux par le driver Lima (au sein de Mesa 3D), il fait donc de l'OpenGL (GL ES avec pilote propriétaire, Full GL avec pilote libre), donc ça peut faire largement l'affaire pour TIC-80 (pas la version Web). Le décodeur vidéo doit être un Cedrus, également géré par pilote libre. Je vais me compiler tic-80 sur un A20 pour voir tiens.

La première génération d'Atom n'avait pas de décodeur vidéo, les intel n'ont jamais eu de processeur 2D. Il tournait à 900 Mhz (à fréquence équivalente, un Intel est plus lent qu'un processeur d'architecture RISC en général). Donc, non, le R8 est beaucoup plus puisant.

C'est du Pico-8

C'est plus un framework qu'un-e fantasy computer/console. Ces derniers embarquent aussi les éditeurs(code/audio/musique/tableaux) dans leur interface. Mais ça n'est pas inintéressant. Le fait que ça soit compiler permet certainement d'avoir une meilleur efficacité, et donc d'avoir plus de chance de fonctionner sur les petites machines.

Par contre, la course, ça n'est pas de la 3D, ça semble être de la 2D vectorielle, mais pas de la 3D. Sur toutes les consoles, ont voit de la pseudo 3D, ou de la 3D limitée avec les moyens du bord.. Ces machines utilisent l'accélération 3D, mais n'ont pas d'API 3D).

Les limites visuelles du 8 bits, sont aussi un genre esthétique, ou plutôt un ensemble de genres esthétiques, qui peut, comme toute esthétique, plaire ou déplaire, et qui donc plaît à certains. Le minimalisme a parfois du bon.

En 3D, il y a le low poly (peu de polygones) qui reprend des principes de limites volontaires de ressources, avec souvent, des formes pleines sans, textures, ou uniquement sur certains détails. Donnant un style épuré et minimaliste. On y retrouve l'esthétique de Virtua Racing de Sega (1992), volontairement repris à l'identique en 2004 sur PS2, sous le nom de Virtua Racing: FlatOut. Je trouve, très personnellement, que c'est plus agréable à regarder que de la 3D comportant des textures sans recherche esthétique, mais tentant juste de ressembler à peu près à la matière.

Il y a A Short Hike, qui mêle gros pixels, low poly, mais également des textures minimalistes, qui ont un impact important. Une très bonne utilisation de la gestalt (prononcer geshtalte). J'ai appris ce terme hier soir, il est vraiment très précis dans son concept et fondamental en ergonomie. La base est que l'esprit voit d'avantage la forme globale que ses détails et que les détails doivent être placés à bon escient pour influer sur la vision globale. La gestalt défini également les critères d'influence psychologique des différents types de détails.

Comme souligné, c'est pas mal basé sur OpenGL, hors le processeur graphique de l'eeePC 701 est un GMA 900, les pilotes 3D de ces générations n'était pas ouverts à l'époque, certains de ces chips graphiques sur les Atom sont des PowerVR, Intel à commencé à travailler sur des pilotes libres en 2006 vers la sortie des HDGraphics en tout cas. Peut être que le pilote i915 gère celui du EeePC 701 aujourd'hui ? Pour les EeePC suivant, PowerVR (d'Imagination Technologies), c'est mort; aucun pilote à ma connaissance. La FSF à mis ça sur les choses prioritaires, mais ils avait fait ça également sur la technologies Flash, résultat, un morceau de décodeur partiel qui ne pouvait que lire certaines vidéos (Gnash, parfois utilisé pour importer des fichiers flash dans les logiciels vecto cela dit).

Bon, les premiers Atom étaient aussi des veaux, je pense qu'à peut près n'importe quel ARMv7 (les ARM Cortex 32 bits) va plus vite

AAah, non, si on suit acheter, il y a la carte de développement, et sur sa photo, on voir R16J sur la puce, donc, ça n'est pas le H3, mais un autre qui à sensiblement les mêmes caractéristiques. Par contre, elle est n'est pas encore, du coup, gérée par le noyau mainline :(. Je ne comprend pas qu'AllWinner reste toujours bloqué sur ce noyau depuis plus de 5 ou 6 ans maintenant…

Oublié de mettre qu'il a un bon décodeur vidéo (4k and Full HD 1080p, il gère le x265 et vp8) et gère l'HDMI en plus de son GPU.

Ah ben, voila, c'est cool, ça utilise un micro-conntrôleur 32 bits à 80 Mhz ESP8266 (on la trouve sur des cartes à 2$). Au moins c'est un minimum puissant par rapport aux ATMega, ça doit être à peu près la puissance de calcul d'un 68040 avec ça ^{^} (si on émule un 68040 ça sera plus lent hein) mais bon, pas de GPU, pas de DSP (contrairement à l'excellent DSP de son successeur, l'ESP32).
Ça à vraiment rien à voir avec, pour citer les consoles de cette liste, la clockworkpi qui utilise un vrai microprocesseur, probablement un AllWinner H3 (ou peut être son dérivé moins cher, le H2+ qui est très populaire) quad-cœur 32 bits (Cortex-A7 à 1.296 GHz) avec un GPU un peu puissant (ARM Mali-400, double cœurs).

émulation, n'est pas forcément opposé à libre. Déjà parce que pas mal d'émulateurs, à commencé par MAME ou RetroArch sont libres, mais aussi parce qu’il y a au moins une communauté du homebrew par console. Il y a un peu de demo-scene également, qui utilisent des techniques d'aujourd'hui sur des micro-ordinateurs ou console d'il y a 30 ou 40 ans et en tirent pleinement partie, des choses qu'on aurait pas cru possible à l'époque.

là je vois que la majorité utilisent des microcontrôleurs ATmega 8 bits (sans doute en copiant-collant la première Arduino), ça n'est pas forcément le meilleur choix, à la fois en terme de prix, de puissance et d’efficacité. Les STM32 (qui sont plus populaires dans l'embarqué, on trouve des cartes à partir de 2€ soit au moins la moitié du prix d'un équivalent en ATMega 8 bits et en 32 bits et ont des fréquences au minimum 4 fois plus élevées. Je ne compare pas aux prix de ces consoles qui ont demandé conception, développement, packaging bien sûr, juste de cartes simples et de leur microcontrôleurs. Certains STM32, ou les ESP32 ont en plus un DSP (voir le son de l'Axoloti pour STM32, et de différents autres pour l'ESP32), ce qui peut aider pour les calculs 3D ou la synthèse de son de qualité professionnelle. Ils ont en plus tous deux plein d'OS, de langages (Arduino, µPython, Faust, etc) et d'outils de développement. L'arrivée depuis 2 ans des microcontrôleurs RISC-V (on en trouve dans les mêmes prix en versions 32 bits) seraient aussi une bonne vision à plus long terme.

Il y a que la clockworkpi qui semble équipé d'un microprocesseur (quadcore A7 + MaliGPU) et donc, donc complétement incomparable aux autres niveau puissance. C'est un SoC Allwinner (dans le dépôt du noyau on voit Sunxi) avec noyau 4.14, donc probablement config officielle d'Allwinner, plein de gros blob tous proprios en guise de pilote. La communauté SunXi ayant porté en mainline depuis au moins la 4.16 ou 4.18. Bon cela dit, rien n'empêche de remplacer par une 5.x avec des pilotes libres (Lima pour le GPU, il commence à vraiment bien tourner, même le lapin avec réfraction (glmark2 -b refract) de GLmark2 tourne bien, etc…)

J'avais oublié de mentionner Enve C'est très jeune (la première version à 1 an), mais déjà très complet

Il vaut mieux utiliser l'appimage, étant donné la complexité pour compiler, surtout skia qui est gigantesque. C'est vraiment très complet :
* C'est vectoriel et ça importe/exporte en SVG (manipulation complète basée sur Skia). Inkscape est un bon compagnon pour créer les modèles
* Dessin à main levée et Bézier/b-spline (et ellipses, rectangles)
* Opérations booléennes sur les chemins
* Système de calques et groupes
* Effets poussés (blur, etc) pouvant être apliqué par calque/groupe.
* Texte vectoriel
* Utilise LibMypaint, pour faire des effets dynamiques sur les traits avec ses brosses.
* Format ouvert XML bien documenté
* La documentation avec petites animations dans la fenêtre d'aide est très claire.