Je pense quand même que pour utiliser une IA efficacement il faut aussi faire fonctionner son cerveau. l'IA est quand un outil formidable pour nous aider a mettre le pied à l'étrier sur des sujets qu'on ne maitrise pas forcément. Après, tout l'enjeu est de faire l'effort supplémentaire de tester et vérifier, et c'est ainsi qu'une veritable compréhension et connaissance se construisent durablement.
Et c'est vrai, quand après un certains nombre d'aller-retour avec l'IA je trouve la solution, j'aime bien lui demande de faire la synthèse de ce qui a été fait pour finalement arriver a résoudre le problème. Je constitue ainsi une petite base de connaissance sur des sujets auxquels je ne suis pas forcément confronté régulièrement et pour lesquelles la mémoire a tendance à l'oubli. Exemple ici: si dans un an je veux reproduite la même setup sur un autre pc, je sors ma fiche… Et plus besoin de faire appel a l'IA pour me rappeller comment faire…
C'est là que l'expérience devient intéressante… Et que la question de la forme et du contenu se pose… Oui, j'ai fait l'effort de lire jusqu'au au bout et attentivement ce message malgré la nausée d'emojis et autre effets de style douteux… Et je me suis concentré sur le contenu… J'ai essayé de comprendre les instructions, les messages et les idées que vous aviez demandé à l'IA d'exprimer.
Parce que c'est comme cela que je conçoit l'usage d'une ia. Je soumets mes recherches, mes réflexions personnelles, ma compréhension et mes conclusions à son analyse (en lui demandant explicitement de ne pas chercher à me flatter…). Ensuite, je lui expose la trame des idées et des messages que je souhaiterais faire passer et lui demande de me proposer une formulation structurée (je suis comme cela, j'aime répéterque ce qui se conçoit bien s'énonce clairement) que je vais adapter si j'en estime le besoin…
Par rapport a votre message initiale, j'ai fait le postulat que vous aviez une approche similaire… Pour en conclure que même si vous aviez à l'évidence demandé une rédaction à la stylistique outrancière et provocatrice, le message sous-jacent néanmoins résonnait de manière infiniment plus positive et constructive que ce que j'ai lu de certains humains ici…
Alors non, il n'y avait aucun cynisme dans la réponse… Mais si effectivement vous n'avez donné aucune instruction par au message et aux idées à faire passer, c'est d'autant plus effrayant de réaliser qu'une IA est peut être capable de plus d'empathie et de bienveillance qu'une personne réelle… Moi, c'est plutôt cela qui me donne la nausée…
WindowMaker est écrit en C pur et n'est pas une application GNUstep et ne répond donc pas aux clés GSScaleFactor et GSFontHinting.
Comme indiqué dans la doc que vous mettez en lien, cette solution ne s'applique qu'aux applications basées sur le framework AppKit. Dès que vous lancez une application non-Gnustep (Firefox, Thunderbird, LibreOffice, etc..), vous retomberez dans le problème de scaling… sauf à configurer chaque framework individuellement… et à condition que vous n'utilisiez pas d'application basée sur des frameworks qui n'offrent pas de solution de scaling équivalente (ex: OpenMotif).
Bref, cela fait beaucoup de chipotages et de prises de tête par rapport à la solution Xorg rappelée dans ce journal, pour atteindre un résultat visuel au mieux imperceptible, au pire inexistant :)
Merci néanmoins pour ce message car les recherches que j'ai faites à sa suite m'ont conduit à découvrir le projet NEXTSPACE (https://github.com/trunkmaster/nextspace); je pense que j'ai trouvé là exactement ce que je cherchais pour mon projet de retro-programming… Peux-être que je partagerai mon expérience dans un prochain journal. Qui sait !
Face au déferlement de commentaires et notes négatives, je voudrais quand même faire quelques mises au point.
Tout d'abord, je m'excuse platement d'avoir utiliser l'IA pour accélérer la rédaction et la formalisation de ce journal. A l'heure où j'écris ce message, je constate qu'il y a au moins 22 personnes ici qui n'ont jamais utilisé l'IA pour cet usage. D'irréductibles gaulois, auxquels je tire ma révérence… Bravo à eux, respect!
Je m'interroge quand même sur ce qui motive ces 22 (probablement plus d'ici à ce que je finisse d'écrire ce message) avis négatifs:
1) Est-ce parce que le sujet abordé est sans intérêt? C'est vrai, qui donc aujourd'hui aurait envie d'utiliser WindowMaker pour programmer en Objective-C/GNUstep, qui donc aujourd'hui s'amuserait sur Mario sur un NES, qui donc aujourd'hui prendrait plaisir à rouler dans une ancêtre, qui, qui, qui… Je suis probablement seul au monde :D
2) Est-ce parce que l'article a été rédigé avec l'aide de l'IA? C'est vrai, qui donc aujourd'hui utilise l'IA pour l'aider un rédiger un texte? Encore heureux que je n'ai pas poster du code fait à l'aide de l'IA… J'aurais été banni sans droit de réponse… Quoique, quand même, c'est bien l'IA qui m'a indiqué quoi mettre dans mon fichier xorg.conf…
3) Peut-être, et cela serait plus gênant et rendrait la critique plus légitime, que les explications apportées dans ce journal sont discutables… Je me serais laissé emporté par la satisfaction d'avoir la solution à mon problème et des explications cohérentes avec les observations que j'ai faites ces derniers jours… Mais dans ce cas, j'aurais aimé qu'un expert corrige et fasse progresser la compréhension du sujet… Et m'explique aussi d'où pourrait venir ce biais pour des solutions bancales qui semblent communément admises sur les forums…
Alors, reprenons quelques critiques
1) Savoir s'il est "acceptable de faire rédiger à des IA des articles sur tout et n'importe quoi et d'ensuite spammer des sites web communautaires avec lesdits articles" posent deux jugements de valeur: (a) le sujet de l'article est sans intérêt (b) poster un article rédigé à l'aide de l'IA équivaut à spammer…
Chacun est libre de juger de le pertinence et de l'intérêt de cette critique.
2) Les doutes sur la "netteté cristalline": bien sûr, si on s'en réfère au seules relations mathématique, la netteté de la solution détaillée dans ce journal ne peut théoriquement pas atteindre celle d'une chaine HiDPI totale. Mais l'optique et la physique sont plus pragmatiques et nous apprennent que vu la densité de pixels des écran HiDPI, (a) à 30 cm, seul un œil exercé peut remarquer un très léger "adoucissement" du texte. (b) A 40 cm, la différence est imperceptible et à 50 cm le résultat optique est strictement identique. Comme quoi, le dogmatisme de certains leur fait oublié la réalité.
3) non, ce n'est pas du HiDPI qui est fait dans ce journal: tout a fait d'accord, et je n'ai pas l'impression que le contenu ou la formulation de ce journal puissent faire penser le contraire. Les plus-vieux d'entre nous auront d'ailleurs peut-être saisi le clin d'oeil "HiDPI ready". Par contre, comme expliqué dans une de mes réponses, ce journal présente la meilleure approche pour obtenir une expérience visuelle optimale sur ces "vieux" gestionnaires de fenêtre, en s'assurant que chaque composant dans la chaîne d'affichage fasse ce pourquoi il est le plus performant.
Voilà, si un modérateur souhaite supprimer ce journal, qu'il n'hésite pas… Un solution simple et élégante à un problème sans intérêt ne mérite probablement pas un journal sur LinuxFR :)
Bien sûr que ce n'est pas du HiDPI au sens strict.
D'ailleurs, l'article ne prétend pas faire du HiDPI.
Ici, je fais part de la solution qui offre le meilleur résultat, selon mon expérience, pour les environnement non HiDPI, à contre-courant des solutions que l'on trouve en fait sur internet et qui "trompent" l'IA.
Je voudrais quand même rappeler un élément de physique "optique" essentiel: à une distance normale de travail, la différence visuelle absolue entre une dalle native 1080p et une dalle HiDPI forcée en 1080p est quasiment indécelable pour l'oeil humain. A 30 cm, seul un oeil excercé peut remarquer un très léger "adoucissement" du texte. A 40 cm, la différence est imperceptibe et à 50 le résultat optique est strictement identique.
Peux-être que les plus vieux ici auront d'aileurs saisi le clin d'oeil "HiDPI ready" ;)
Permettez-moi de re-phraser et simplifier ma réponse
Non, je ne désactive pas les capacités physiques de mon écran: je réorganise le travail pour que chaque composant fasse ce pour quoi il est le plus performant.
1) Le logiciel (Firefox, Thunderbird, etc…) travaille en 1 pour 1 (pixel-perfect). En réglant Xorg à la racine, les applications dessinent leurs fenêtres, icônes et polices sur un canevas virtuel exact. Il n'y a aucun calcul d'extrapolation applicative, aucune déformation de police et aucun sous-échantillonnage logiciel.
2) Le matériel prend ensuite le relais: la carte graphique et le processeur d'affichage de la dalle reçoivent ce signal 1080p propre et l'affichent sur la grille 2.8k de l'écran.
Comme les dalles HiDPI modernes ont une densité extrêmement élevée (les pixels physiques sont extrêmement petits—bcp, bcp trop petits pour être visibles à l'oeil nu), la mise à l'échelle matérielle effectuée par le composant vidéo donne un rendu net et reposant pour les yeux… probablement meilleur que sur une dalle physique de 1920x1080…
Vous savez, dans la vie, on peut avoir de multiples intérêts parfois "contradictoires". D'un côté du rétro-programming Objective-C/Cocoa (sur PowerMac G4) et Objective-C/GNUstep et de l'autre faire de la retouche photo ou de la conception 3D avec du matériel moderne… Auquel cas, il est plus économe et facile de pouvoir utiliser un seul et unique matériel…
Sur le fond de votre réponse, je vais nuancer: le vrai HiDPI vectoriel nécessite un soutien complet de la chaîne applicative (Wayland, GTK4, QT6) que des WMs légers sous X11 ne possèdent pas. Le choix ici n'est pas entre "vrai HiDPI" et "1080p"), mais entre 1) un scaling logiciel dynamique (xrandr) qui calcule en 2.8K puis applique un filtre bilinéaire baveux (destruction de l'alignement subpixel). 2) une définition de grille native dans Xorg où l'application effectue son rendu à 1:1 laissant le scaler matériel s'en occuper. Sur une dalle de 15 pouces de 2.8K, la densité de pixels est tellement élevée que la mise à l'échelle matérielle 1:1 offre un confort visuel très élevé et immédiatement supérieur au bricolage xrand… tout en préservant 100% de la légerté de Window Maker…
Et si vous avez des doutes quant à la qualité visuelle, n'hésitez pas à tester ce que j'ai mis dans cette article… Qui sait…
En tout cas, une chose est sûr, je suis heureux d'avoir fait appel à une IA plutôt qu'à l'aide de certains membres ici ….
Bonjour
Merci pour ce retour, et votre réaction est légitime. Je n'ai sans doute pas été suffisamment explicite sur la démarche globale qui a motivé de partager cet article.
Mon objectif de départ était un projet de niche : faire tourner des window managers aujourd'hui considérés comme anciens ou déclassés (comme Window Maker ou IceWM) sur des écrans HiDPI modernes. Pour résoudre ce genre de casse-tête technique, j'ai d'abord sollicité l'IA, qui reste un formidable agrégateur de connaissances (et de méconnaissances) sur un sujet.
C'est là que l'expérience est devenue intéressante. Face à cette problématique, l'IA a tourné en rond. Toutes les solutions qu'elle me proposait étaient bancales. Concrètement, elles créaient une surface "physique" contrainte en 1920x1080 sur l'ensemble de l'écran (le curseur de la souris restait bloqué dans cette zone), alors que les applications continuaient de croire que l'écran était dans sa résolution maximale (ex: en maximisant une fenêtre, seule une partie restait visible à l'écran, et le reste devenait inaccessible). Le résultat visuel était baveux.
En basculant sur des recherches classiques et sur les forums, j'ai réalisé que l'IA ne faisait que recracher les même "solutions" que je retrouvais dans différents forums. Ce n'est qu'en m'appuyant sur mon propre vécu d'il y a 25 ou 30 ans que j'ai pu réorienter l'IA vers les fondamentaux du problème, ce qui a débloqué une solution fonctionnelle immédiatement.
L'idée de l'article était donc de documenter ce processus de recherche et la confrontation aux limites du « consensus du Web ». Quant à savoir si utiliser l'IA pour formaliser cette démarche constitue une pollution du site, je laisse chacun seul juge.
En revanche, je reconnais être probablement tombé moi-même dans les travers de l'outil en laissant l'IA formuler des explications techniques peut-être bancales pour décrire le comportement réel observé sous Window Maker et IceWM. Pour cela, je m'en excuse : j'ai clairement surestimé la qualité de la restitution technique brute fournie.
Libre aux modérateurs de supprimer cet article s'il ne respecte pas la charte du site.
[^] # To prevent misinformation...
Posté par brainois . En réponse au journal HiDPI - retour aux fondamentaux Xorg. Évalué à -4 (+3/-4).
Je ne sais vraiment pas quoi répondre. Je reste pantois…
https://www.gnustep.org/information/wm.html
WINGS Is Not GNUstep…
[^] # Re: Mise au point...
Posté par brainois . En réponse au journal HiDPI - retour aux fondamentaux Xorg. Évalué à -3 (+5/-5).
Je pense quand même que pour utiliser une IA efficacement il faut aussi faire fonctionner son cerveau. l'IA est quand un outil formidable pour nous aider a mettre le pied à l'étrier sur des sujets qu'on ne maitrise pas forcément. Après, tout l'enjeu est de faire l'effort supplémentaire de tester et vérifier, et c'est ainsi qu'une veritable compréhension et connaissance se construisent durablement.
Et c'est vrai, quand après un certains nombre d'aller-retour avec l'IA je trouve la solution, j'aime bien lui demande de faire la synthèse de ce qui a été fait pour finalement arriver a résoudre le problème. Je constitue ainsi une petite base de connaissance sur des sujets auxquels je ne suis pas forcément confronté régulièrement et pour lesquelles la mémoire a tendance à l'oubli. Exemple ici: si dans un an je veux reproduite la même setup sur un autre pc, je sors ma fiche… Et plus besoin de faire appel a l'IA pour me rappeller comment faire…
[^] # Re: Enfin...
Posté par brainois . En réponse au journal HiDPI - retour aux fondamentaux Xorg. Évalué à -6 (+3/-6). Dernière modification le 28 août 2026 à 11:50.
C'est là que l'expérience devient intéressante… Et que la question de la forme et du contenu se pose… Oui, j'ai fait l'effort de lire jusqu'au au bout et attentivement ce message malgré la nausée d'emojis et autre effets de style douteux… Et je me suis concentré sur le contenu… J'ai essayé de comprendre les instructions, les messages et les idées que vous aviez demandé à l'IA d'exprimer.
Parce que c'est comme cela que je conçoit l'usage d'une ia. Je soumets mes recherches, mes réflexions personnelles, ma compréhension et mes conclusions à son analyse (en lui demandant explicitement de ne pas chercher à me flatter…). Ensuite, je lui expose la trame des idées et des messages que je souhaiterais faire passer et lui demande de me proposer une formulation structurée (je suis comme cela, j'aime répéterque ce qui se conçoit bien s'énonce clairement) que je vais adapter si j'en estime le besoin…
Par rapport a votre message initiale, j'ai fait le postulat que vous aviez une approche similaire… Pour en conclure que même si vous aviez à l'évidence demandé une rédaction à la stylistique outrancière et provocatrice, le message sous-jacent néanmoins résonnait de manière infiniment plus positive et constructive que ce que j'ai lu de certains humains ici…
Alors non, il n'y avait aucun cynisme dans la réponse… Mais si effectivement vous n'avez donné aucune instruction par au message et aux idées à faire passer, c'est d'autant plus effrayant de réaliser qu'une IA est peut être capable de plus d'empathie et de bienveillance qu'une personne réelle… Moi, c'est plutôt cela qui me donne la nausée…
Wouah…
[^] # Enfin...
Posté par brainois . En réponse au journal HiDPI - retour aux fondamentaux Xorg. Évalué à -5 (+5/-7).
…Une critique constructive, argumentée et parfaitement audible…
Merci pour ça.
Cordialement
[^] # Re: Et à la fin on fait n'improte quoi
Posté par brainois . En réponse au journal HiDPI - retour aux fondamentaux Xorg. Évalué à -2 (+5/-4).
Bonjour,
WindowMaker est écrit en C pur et n'est pas une application GNUstep et ne répond donc pas aux clés GSScaleFactor et GSFontHinting.
Comme indiqué dans la doc que vous mettez en lien, cette solution ne s'applique qu'aux applications basées sur le framework AppKit. Dès que vous lancez une application non-Gnustep (Firefox, Thunderbird, LibreOffice, etc..), vous retomberez dans le problème de scaling… sauf à configurer chaque framework individuellement… et à condition que vous n'utilisiez pas d'application basée sur des frameworks qui n'offrent pas de solution de scaling équivalente (ex: OpenMotif).
Bref, cela fait beaucoup de chipotages et de prises de tête par rapport à la solution Xorg rappelée dans ce journal, pour atteindre un résultat visuel au mieux imperceptible, au pire inexistant :)
Merci néanmoins pour ce message car les recherches que j'ai faites à sa suite m'ont conduit à découvrir le projet NEXTSPACE (https://github.com/trunkmaster/nextspace); je pense que j'ai trouvé là exactement ce que je cherchais pour mon projet de retro-programming… Peux-être que je partagerai mon expérience dans un prochain journal. Qui sait !
Cordialement
Brainois
[^] # Re: Mise au point...
Posté par brainois . En réponse au journal HiDPI - retour aux fondamentaux Xorg. Évalué à -10 (+2/-10).
Bonjour
Si elles sont constructives et argumentée, je n'ai aucun problème. Cfr mon point 3).
Mais celles-là je ne les ai pas encore lues.
Cordialement
# Mise au point...
Posté par brainois . En réponse au journal HiDPI - retour aux fondamentaux Xorg. Évalué à -8 (+9/-17).
Bonjour à tous,
Face au déferlement de commentaires et notes négatives, je voudrais quand même faire quelques mises au point.
Tout d'abord, je m'excuse platement d'avoir utiliser l'IA pour accélérer la rédaction et la formalisation de ce journal. A l'heure où j'écris ce message, je constate qu'il y a au moins 22 personnes ici qui n'ont jamais utilisé l'IA pour cet usage. D'irréductibles gaulois, auxquels je tire ma révérence… Bravo à eux, respect!
Je m'interroge quand même sur ce qui motive ces 22 (probablement plus d'ici à ce que je finisse d'écrire ce message) avis négatifs:
1) Est-ce parce que le sujet abordé est sans intérêt? C'est vrai, qui donc aujourd'hui aurait envie d'utiliser WindowMaker pour programmer en Objective-C/GNUstep, qui donc aujourd'hui s'amuserait sur Mario sur un NES, qui donc aujourd'hui prendrait plaisir à rouler dans une ancêtre, qui, qui, qui… Je suis probablement seul au monde :D
2) Est-ce parce que l'article a été rédigé avec l'aide de l'IA? C'est vrai, qui donc aujourd'hui utilise l'IA pour l'aider un rédiger un texte? Encore heureux que je n'ai pas poster du code fait à l'aide de l'IA… J'aurais été banni sans droit de réponse… Quoique, quand même, c'est bien l'IA qui m'a indiqué quoi mettre dans mon fichier xorg.conf…
3) Peut-être, et cela serait plus gênant et rendrait la critique plus légitime, que les explications apportées dans ce journal sont discutables… Je me serais laissé emporté par la satisfaction d'avoir la solution à mon problème et des explications cohérentes avec les observations que j'ai faites ces derniers jours… Mais dans ce cas, j'aurais aimé qu'un expert corrige et fasse progresser la compréhension du sujet… Et m'explique aussi d'où pourrait venir ce biais pour des solutions bancales qui semblent communément admises sur les forums…
Alors, reprenons quelques critiques
1) Savoir s'il est "acceptable de faire rédiger à des IA des articles sur tout et n'importe quoi et d'ensuite spammer des sites web communautaires avec lesdits articles" posent deux jugements de valeur: (a) le sujet de l'article est sans intérêt (b) poster un article rédigé à l'aide de l'IA équivaut à spammer…
Chacun est libre de juger de le pertinence et de l'intérêt de cette critique.
2) Les doutes sur la "netteté cristalline": bien sûr, si on s'en réfère au seules relations mathématique, la netteté de la solution détaillée dans ce journal ne peut théoriquement pas atteindre celle d'une chaine HiDPI totale. Mais l'optique et la physique sont plus pragmatiques et nous apprennent que vu la densité de pixels des écran HiDPI, (a) à 30 cm, seul un œil exercé peut remarquer un très léger "adoucissement" du texte. (b) A 40 cm, la différence est imperceptible et à 50 cm le résultat optique est strictement identique. Comme quoi, le dogmatisme de certains leur fait oublié la réalité.
3) non, ce n'est pas du HiDPI qui est fait dans ce journal: tout a fait d'accord, et je n'ai pas l'impression que le contenu ou la formulation de ce journal puissent faire penser le contraire. Les plus-vieux d'entre nous auront d'ailleurs peut-être saisi le clin d'oeil "HiDPI ready". Par contre, comme expliqué dans une de mes réponses, ce journal présente la meilleure approche pour obtenir une expérience visuelle optimale sur ces "vieux" gestionnaires de fenêtre, en s'assurant que chaque composant dans la chaîne d'affichage fasse ce pourquoi il est le plus performant.
Voilà, si un modérateur souhaite supprimer ce journal, qu'il n'hésite pas… Un solution simple et élégante à un problème sans intérêt ne mérite probablement pas un journal sur LinuxFR :)
Bonne soirée.
Brainois
[^] # Re: Et à la fin on fait n'improte quoi
Posté par brainois . En réponse au journal HiDPI - retour aux fondamentaux Xorg. Évalué à -1 (+4/-5).
Bonjour Christophe
Bien sûr que ce n'est pas du HiDPI au sens strict.
D'ailleurs, l'article ne prétend pas faire du HiDPI.
Ici, je fais part de la solution qui offre le meilleur résultat, selon mon expérience, pour les environnement non HiDPI, à contre-courant des solutions que l'on trouve en fait sur internet et qui "trompent" l'IA.
Je voudrais quand même rappeler un élément de physique "optique" essentiel: à une distance normale de travail, la différence visuelle absolue entre une dalle native 1080p et une dalle HiDPI forcée en 1080p est quasiment indécelable pour l'oeil humain. A 30 cm, seul un oeil excercé peut remarquer un très léger "adoucissement" du texte. A 40 cm, la différence est imperceptibe et à 50 le résultat optique est strictement identique.
Peux-être que les plus vieux ici auront d'aileurs saisi le clin d'oeil "HiDPI ready" ;)
[^] # Re: Et à la fin on fait n'improte quoi
Posté par brainois . En réponse au journal HiDPI - retour aux fondamentaux Xorg. Évalué à -6 (+1/-7).
Et moi, je n'ai pas trouvé de référence pour expliquer votre réponse dénigrante…
[^] # Re: Et à la fin on fait n'improte quoi
Posté par brainois . En réponse au journal HiDPI - retour aux fondamentaux Xorg. Évalué à 0 (+5/-5).
Permettez-moi de re-phraser et simplifier ma réponse
Non, je ne désactive pas les capacités physiques de mon écran: je réorganise le travail pour que chaque composant fasse ce pour quoi il est le plus performant.
1) Le logiciel (Firefox, Thunderbird, etc…) travaille en 1 pour 1 (pixel-perfect). En réglant Xorg à la racine, les applications dessinent leurs fenêtres, icônes et polices sur un canevas virtuel exact. Il n'y a aucun calcul d'extrapolation applicative, aucune déformation de police et aucun sous-échantillonnage logiciel.
2) Le matériel prend ensuite le relais: la carte graphique et le processeur d'affichage de la dalle reçoivent ce signal 1080p propre et l'affichent sur la grille 2.8k de l'écran.
Comme les dalles HiDPI modernes ont une densité extrêmement élevée (les pixels physiques sont extrêmement petits—bcp, bcp trop petits pour être visibles à l'oeil nu), la mise à l'échelle matérielle effectuée par le composant vidéo donne un rendu net et reposant pour les yeux… probablement meilleur que sur une dalle physique de 1920x1080…
[^] # Re: Et à la fin on fait n'improte quoi
Posté par brainois . En réponse au journal HiDPI - retour aux fondamentaux Xorg. Évalué à 2 (+9/-7).
Vous savez, dans la vie, on peut avoir de multiples intérêts parfois "contradictoires". D'un côté du rétro-programming Objective-C/Cocoa (sur PowerMac G4) et Objective-C/GNUstep et de l'autre faire de la retouche photo ou de la conception 3D avec du matériel moderne… Auquel cas, il est plus économe et facile de pouvoir utiliser un seul et unique matériel…
Sur le fond de votre réponse, je vais nuancer: le vrai HiDPI vectoriel nécessite un soutien complet de la chaîne applicative (Wayland, GTK4, QT6) que des WMs légers sous X11 ne possèdent pas. Le choix ici n'est pas entre "vrai HiDPI" et "1080p"), mais entre 1) un scaling logiciel dynamique (xrandr) qui calcule en 2.8K puis applique un filtre bilinéaire baveux (destruction de l'alignement subpixel). 2) une définition de grille native dans Xorg où l'application effectue son rendu à 1:1 laissant le scaler matériel s'en occuper. Sur une dalle de 15 pouces de 2.8K, la densité de pixels est tellement élevée que la mise à l'échelle matérielle 1:1 offre un confort visuel très élevé et immédiatement supérieur au bricolage xrand… tout en préservant 100% de la légerté de Window Maker…
Et si vous avez des doutes quant à la qualité visuelle, n'hésitez pas à tester ce que j'ai mis dans cette article… Qui sait…
En tout cas, une chose est sûr, je suis heureux d'avoir fait appel à une IA plutôt qu'à l'aide de certains membres ici ….
[^] # Re: Consensus
Posté par brainois . En réponse au journal HiDPI - retour aux fondamentaux Xorg. Évalué à 6 (+16/-10).
Bonjour
Merci pour ce retour, et votre réaction est légitime. Je n'ai sans doute pas été suffisamment explicite sur la démarche globale qui a motivé de partager cet article.
Mon objectif de départ était un projet de niche : faire tourner des window managers aujourd'hui considérés comme anciens ou déclassés (comme Window Maker ou IceWM) sur des écrans HiDPI modernes. Pour résoudre ce genre de casse-tête technique, j'ai d'abord sollicité l'IA, qui reste un formidable agrégateur de connaissances (et de méconnaissances) sur un sujet.
C'est là que l'expérience est devenue intéressante. Face à cette problématique, l'IA a tourné en rond. Toutes les solutions qu'elle me proposait étaient bancales. Concrètement, elles créaient une surface "physique" contrainte en 1920x1080 sur l'ensemble de l'écran (le curseur de la souris restait bloqué dans cette zone), alors que les applications continuaient de croire que l'écran était dans sa résolution maximale (ex: en maximisant une fenêtre, seule une partie restait visible à l'écran, et le reste devenait inaccessible). Le résultat visuel était baveux.
En basculant sur des recherches classiques et sur les forums, j'ai réalisé que l'IA ne faisait que recracher les même "solutions" que je retrouvais dans différents forums. Ce n'est qu'en m'appuyant sur mon propre vécu d'il y a 25 ou 30 ans que j'ai pu réorienter l'IA vers les fondamentaux du problème, ce qui a débloqué une solution fonctionnelle immédiatement.
L'idée de l'article était donc de documenter ce processus de recherche et la confrontation aux limites du « consensus du Web ». Quant à savoir si utiliser l'IA pour formaliser cette démarche constitue une pollution du site, je laisse chacun seul juge.
En revanche, je reconnais être probablement tombé moi-même dans les travers de l'outil en laissant l'IA formuler des explications techniques peut-être bancales pour décrire le comportement réel observé sous Window Maker et IceWM. Pour cela, je m'en excuse : j'ai clairement surestimé la qualité de la restitution technique brute fournie.
Libre aux modérateurs de supprimer cet article s'il ne respecte pas la charte du site.
Bien à vous ;)