In der Regel benötigen funktionierende Dienstprogramme keine vernünftige Benutzeroberfläche mit Schaltflächen, Listen, Fenstern, Mausunterstützung und anderen kleinen Dingen. Der größte Teil der funktionierenden Wunschliste kann in Skripten gepackt und manchmal mit dem Parameter --help ausgeführt werden. Dies ist unter dem Gesichtspunkt der Konfiguration sogar noch korrekter und Skalierung. Alles wird schlimmer, wenn nicht nur das Entwicklungsteam, sondern auch Dritte beginnen, die Tools zu verwenden. Und sie sind nicht immer bereit, sich mit den harmonischen Gedanken zu befassen, die in den Codezeilen niedergelegt sind. Und dann muss man die Benutzeroberfläche durcheinander bringen, und die Entwickler bekommen sie normalerweise einfach, quadratisch, funktional und völlig langweilig. Vor einiger Zeit arbeitete ich an einem kleinen Lüftungs- / Heizungs- / Kamerasteuerungssystem und auch an „was der Onkel in einem gelben Helm sich einfallen lässt“ für eine Tiefgarage.
(Hier ist ein Bild aus dem UI-System, aber der Entwickler hat darum gebeten, es zu entfernen. Wenn Sie nicht über Spaziergänge auf dem Rechenfeld lesen möchten, klicken Sie auf den Github am Ende des Artikels.)
Das System wurde auf dem chinesischen SoC ohne Namen aufgebaut, für den der Hersteller beschlossen hat, das SDL-Framework der ersten Version zu portieren. Die internen Tools und Skripte wurden so fertiggestellt, dass sie sich in ein gewichtiges und „schönes“ Layout mit Registerkarten, Listen, Popups, Schatten, Farbverläufen, Transparenz und anderen Extras verwandelten.
Um all die Schönheiten zu verwirklichen, wurde Nanogui ausgewählt, einfach und unprätentiös und gleichzeitig "mächtig", was alles brauchte. Es war genau auf dem Papier, aber die
Schluchten vergaßen OpenGL. Fast vollständig implementierte UI-Steuerungssysteme liefen auf Hardware, und dort gab es einen schwarzen Bildschirm, alle OpenGL3-Initialisierungen verliefen fehlerfrei, Puffer wurden gesetzt und Shader wurden kompiliert, aber kein ... schwarzer Bildschirm, in welchem Winkel nicht.
Zuerst sündigten sie an meinen krummen Händen, dann an den Händen des Antokha-Entwicklers, der für den Treiber und die Hardware verantwortlich ist, dann starteten sie ein Testbeispiel für ein Dreiecks-Rendering aus dem SoC SDK, und wieder werden der schwarze Bildschirm, die Dokumentation und die Beispiele normalerweise zuletzt gelesen.
Mein Kollege und ich dachten etwas falsch und gingen zuerst zum chinesischen Forum. Nachdem wir noch keine klaren Antworten für den Entwickler gefunden hatten, war die Antwort enttäuschend, es gab keine OpenGL-Implementierung und höchstwahrscheinlich auch nicht, da die Leitung eingestellt wurde.
- Aber was ist mit dem SDL-Framework? - Wir haben gefragt
- Wir zeichnen Pixel für Pixel in den Videospeicher. - Unsere chinesischen Freunde haben uns geantwortet.
An diesem Tag sah ich die traurigen Augen eines Programmierers, der berechnet, wie viel LoC er an / dev / null senden wird. Das Werfen einer vorgefertigten Lösung war jedoch sehr enttäuschend
(im Internet gibt es alles). Es stellt sich heraus, dass Sie ohne OpenGL in Nanogui auf einem Software-Render leben können.
Es ist nur möglich, sehr langsam zu leben, auf einem großen PC einige Sekunden pro Frame, nach dem chinesischen Wunder der Technik sind es bereits etwa 20 bis 25 Sekunden zum Zeichnen. Dann beschlossen sie, nicht die gesamte Benutzeroberfläche auf einmal zu rendern, sondern nur die erforderlichen (geänderten) Teile der Widgets, aber selbst in diesem Modus dauerte es bei all den Hacks und Optimierungen mehr als 10 Sekunden pro Frame, was nicht möglich war ...
Nachdem wir einige SDK-Beispiele geraucht hatten, stellten wir fest, dass das Kopieren von vorgefertigten Texturen in den Videospeicher „sofort“ erfolgt (im Vergleich zu natürlich 10 Sekunden). Wenn Sie mehrere dieser Texturen nacheinander kopieren, dauert es ungefähr 1 ms bis 512 x 512 ohne Transparenz und 2 ms für dasselbe mit Transparenz Die Zeit wächst nichtlinear katastrophal, was sich als Folge der begrenzten Menge an Videospeicherpuffer herausstellte, deren Überlauf dazu führte, dass der Puffer geleert und gerendert wurde, was sich auf dem Bildschirm befand (nicht meins, es war bereits vorhanden), d. h. Für eine nicht vollständig tote Schnittstelle können wir nicht mehr als 50-100 Texturen pro Frame kopieren und nicht sofort, sondern erst, nachdem der Videotreiber darauf gewartet hat, die Daten aus dem Puffer zu entnehmen.
Die nächste Iteration war das Rendern des Widgets in seine eigene Textur im Stream, und zum Zeitpunkt der Erstellung der Textur wurde das Widget ungefähr ähnlich wie das Endergebnis gezeichnet, nur auf quadratische Weise, um alle Arten von Linien zu zeichnen. Formen konnten sofort kostenlos im Videospeicher gespeichert werden.
Fast das Wunder des chinesischen Denkens „ohne“ GPU besiegt, kann man die 20 FPS immer noch nicht als anständiges Ergebnis bezeichnen. Nachdem ich das Projekt fast abgeschlossen hatte, bat ich den Kunden um Erlaubnis, einige der Erfahrungen in Open Source zu sammeln. Die erste SDL ist derzeit nicht sehr in Mode, daher wurde beschlossen, das Nanogui-Rendering im Softwaremodus auf SDL2 zu verwenden und auf den Github zu setzen. Vielleicht braucht jemand :)
Nachdem% habruiser% den Artikel bis zum Ende gelesen hat, hat er das Recht zu fragen, warum es notwendig war, diesen Code zu blockieren
für abgerundete Ecken und Schatten? Erstens ist es schön, zweitens "dieser Onkel in einem gelben Helm" hat bereits für die Entwicklung des Systems bezahlt und die abgerundeten Ecken dort sind leider (oder zum Glück) in der Aufgabenliste gelandet. Es bleibt, sie mit einem Farbverlauf zu versehen und einige Schatten hinzuzufügen.
Dies war der ursprüngliche Sommer 2017 im sonnigen Sotschi.
So rendert OpenGLSo wird Software auf einem PC gerendertReferenzen :
Original Wjakob / NanoguiNanoVG-Software rendernNanoGUI + SDL + Software rendernPS Glauben Sie nicht, dass die
chinesischen Entwickler über das Vorhandensein von OpenGL im System sprechen, überprüfen Sie die Leistung aller Komponenten, um zu wissen, wie :)