En règle générale, les utilitaires de travail ne nécessitent pas une interface utilisateur saine, avec des boutons, des listes, des fenêtres, la prise en charge de la souris et d'autres petites choses, la plupart des listes de souhaits peuvent être regroupées dans des scripts et parfois les exécuter avec le paramètre --help, et cela sera encore plus correct du point de vue de la configuration et mise à l'échelle. Tout empire lorsque non seulement l'équipe de développement, mais aussi des tiers commencent à utiliser les outils. Et ils ne sont pas toujours prêts à se plonger dans les pensées harmonieuses énoncées dans les lignes de code. Et puis vous devez faire toute une histoire avec l'interface utilisateur, et les développeurs l'obtiennent généralement simple, carré, fonctionnel et complètement ennuyeux. Il y a quelque temps, je travaillais sur un petit système de contrôle de ventilation / chauffage / caméra et aussi «ce que l'oncle dans un casque jaune va trouver» pour un parking souterrain.
(Voici une image du système d'interface utilisateur, mais le développeur a demandé de la supprimer. Si vous ne voulez pas lire les promenades sur le champ de râteau, puis des liens vers le github à la fin de l'article)
Le système a été construit sur le SoC chinois non nominatif, pour lequel le fabricant a décidé de porter le cadre SDL de la première version. Les outils et scripts internes ont été finalisés à un point tel qu'ils se sont transformés en une mise en page lourde et «belle» avec des onglets, des listes, des popups, des ombres, un dégradé, la transparence et d'autres goodies.
Pour réaliser toutes les beautés, nanogui a été choisie, simple et sans prétention, et en même temps «puissante» tout ce qu'il fallait. C'était exactement sur papier, mais les
ravins ont oublié OpenGL. Les systèmes de contrôle d'interface utilisateur presque complètement implémentés ont commencé à fonctionner sur le matériel, et là un écran noir, toutes les initialisations OpenGL3 se passent sans erreurs, les tampons sont définis et les shaders sont compilés, mais pas ... d'écran noir, sous quel angle ne pas regarder.
Au début, ils ont péché sur mes mains tordues, puis sur les mains du développeur Antokha responsable du pilote et du matériel, puis ils ont lancé un exemple de test de rendu triangulaire à partir du SDC SoC, et encore l'écran noir, la documentation et les exemples sont généralement lus en dernier.
Mon collègue et moi avons pensé que quelque chose n'allait pas et nous sommes d'abord rendus sur le forum chinois, et n'ayant pas encore trouvé de réponses claires pour le développeur, la réponse était décevante, il n'y avait pas d'implémentation opengl, et très probablement pas, car la ligne était interrompue.
- Mais qu'en est-il du cadre SDL? - nous avons demandé
- Nous attirons pixel par pixel dans la mémoire vidéo. - Nos amis chinois nous ont répondu.
Ce jour-là, j'ai vu les yeux tristes d'un programmeur qui calcule la quantité de LoC qu'il enverra à / dev / null. Mais lancer une solution prête à l'emploi a été très décevant
(sur Internet, il y a tout), il s'avère que vous pouvez vivre sans OpenGL dans nanogui sur un logiciel de rendu.
Seule la vie se révèle très lentement, sur un grand PC quelques secondes par image, dans le miracle de l'ingénierie chinoise, il faut déjà environ 20-25 secondes pour dessiner. Ensuite, ils ont décidé de ne pas rendre l'intégralité de l'interface utilisateur à la fois, mais uniquement les parties nécessaires (modifiées) des widgets, mais même dans ce mode, avec tous les hacks et optimisations, cela a pris plus de 10 secondes par image, non viable ...
Après avoir fumé quelques exemples de SDK, nous avons découvert que la copie de textures prêtes à l'emploi dans la mémoire vidéo est "instantanée" (par rapport à 10 secondes bien sûr), et cela prend environ 1 ms à 512 x 512 sans transparence et 2 ms pour la même chose avec transparence, si vous copiez plusieurs de ces textures l'une après l'autre, puis le temps augmente de façon non linéaire catastrophique, cela s'est avéré être dû à la quantité limitée de tampon de mémoire vidéo, dont le débordement a conduit à vider le tampon et à rendre ce qui était à l'écran (pas le mien, il était déjà là), c'est-à-dire pour une interface pas tout à fait morte, nous ne pouvons pas copier plus de 50-100 textures par image et pas immédiatement, mais seulement après avoir attendu que le pilote vidéo collecte les données du tampon.
L'itération suivante a été le rendu du widget dans sa propre texture dans le flux, et au moment où la texture a été créée, le widget était dessiné à peu près de la même manière que le résultat final, uniquement de manière carrée, pour dessiner toutes sortes de lignes, les formes pouvaient être immédiatement dans la mémoire vidéo gratuitement.
Vaincre presque le miracle de la pensée chinoise «sans» un GPU, vous ne pouvez toujours pas appeler les 20 FPS un résultat décent, et après avoir presque terminé le projet, j'ai demandé au client la permission de reprendre une partie de l'expérience en open source. Le premier SDL n'est plus très à la mode maintenant, il a donc été décidé d'utiliser le rendu nanogui en mode logiciel sur SDL2 et de le mettre sur le github. Peut-être que quelqu'un aura besoin :)
Après avoir lu l'article jusqu'au bout,% habruiser% a le droit de se demander pourquoi il était nécessaire de bloquer ce tas de code
pour les coins arrondis et les ombres? Premièrement, c'est beau (s), deuxièmement, «cet oncle dans un casque jaune» a déjà payé pour le développement du système et les coins arrondis là-bas, malheureusement (ou heureusement) ont fini dans la liste des tâches, il reste à les faire avec un dégradé et à ajouter des ombres.
C'était l'été original de 2017 sous le soleil de Sotchi.
Voici comment OpenGL rendVoici comment le logiciel s'affiche sur un PCRéférences :
Original wjakob / nanoguiRendu logiciel NanoVGRendu logiciel NanoGUI + SDL +PS Ne croyez pas que les développeurs
chinois parlent de la présence d'OpenGL dans le système, vérifiez les performances de tous les composants, pour savoir comment :)