Por lo general, las utilidades de trabajo no requieren una interfaz de usuario sana, con botones, listas, ventanas, compatibilidad con mouse y otras cosas pequeñas, la mayoría de la lista de deseos de trabajo se puede empaquetar en scripts y, a veces, ejecutarlos con el parámetro --help, y esto será aún más correcto desde el punto de vista de la configuración y escalamiento. Todo empeora cuando no solo el equipo de desarrollo, sino también personas externas comienzan a usar las herramientas. Y no siempre están listos para profundizar en los pensamientos armoniosos establecidos en las líneas de código. Y luego tienes que hacer un escándalo de la interfaz de usuario, y los desarrolladores generalmente lo obtienen simple, cuadrado, funcional y completamente aburrido. Hace algún tiempo, estaba trabajando en un pequeño sistema de control de ventilación / calefacción / cámara y también "qué inventará el tío en un casco amarillo" para un estacionamiento subterráneo.
(Aquí había una imagen del sistema de interfaz de usuario, pero el desarrollador solicitó eliminarla. Si no desea leer sobre caminatas en el campo de rastrillo, entonces los enlaces al github al final del artículo)
El sistema fue construido en el SoC chino sin nombre, para lo cual el fabricante decidió portar el marco SDL de la primera versión. Las herramientas internas y los scripts se finalizaron de tal manera que se convirtieron en un diseño pesado y "hermoso" con pestañas, listas, ventanas emergentes, sombras, degradado, transparencia y otras cosas.
Para realizar todas las bellezas, se eligió el nanogui, simple y sin pretensiones, y al mismo tiempo "poderoso", todo lo que se necesitaba. Estaba exactamente en papel, pero los
barrancos se olvidaron de OpenGL. Los sistemas de control de UI casi completamente implementados comenzaron a ejecutarse en hardware, y hay una pantalla en negro, todas las inicializaciones de OpenGL3 se ejecutan sin errores, se establecen buffers y se compilan los sombreadores, pero no ... pantalla en negro, en qué ángulo no se ve.
Al principio pecaron en mis manos torcidas, luego en las manos del desarrollador de Antokha responsable del controlador y el hardware, luego lanzaron un ejemplo de prueba de un triángulo desde el SDK de SoC, y nuevamente la pantalla negra, la documentación y los ejemplos generalmente se leen al final.
Mi colega y yo pensamos que algo andaba mal y fuimos primero al foro chino, y al no haber encontrado respuestas claras para el desarrollador, la respuesta fue decepcionante, no hubo implementación de opengl, y lo más probable es que no, porque la línea se interrumpió.
- Pero, ¿qué pasa con el marco SDL? - preguntamos
- Dibujamos píxel por píxel en la memoria de video. - Nuestros amigos chinos nos respondieron.
Ese día vi los ojos tristes de un programador que calcula cuánto LoC enviará a / dev / null. Pero lanzar una solución preparada fue muy decepcionante,
(en Internet hay de todo) resulta que puedes vivir sin OpenGL en nanogui en un render de software.
Solo la vida resulta muy lenta, en una PC grande, un par de segundos por cuadro, en el milagro de la ingeniería china, ya son unos 20-25 segundos para dibujar. Luego decidieron no renderizar toda la IU a la vez, sino solo las partes necesarias (cambiadas) de los widgets, pero incluso en este modo, con todos los hacks y optimizaciones, tomó más de 10 segundos por fotograma, no viable ...
Después de haber fumado algunos ejemplos de SDK, descubrimos que copiar texturas preparadas en la memoria de video es "instantáneo" (en comparación con 10 segundos, por supuesto), y toma alrededor de 1 ms a 512x512 sin transparencia y 2 ms para lo mismo con transparencia, si copia varias de estas texturas una tras otra, luego el tiempo crece de forma no lineal catastrófica, esto se debió a la cantidad limitada de memoria intermedia de video, cuyo desbordamiento llevó a vaciar la memoria intermedia y mostrar lo que estaba en la pantalla (no el mío, ya estaba allí), es decir para una interfaz no del todo muerta, podemos copiar no más de 50-100 texturas por cuadro y no inmediatamente, sino solo después de esperar que el controlador de video recopile datos del búfer.
La siguiente iteración fue la representación del widget en su propia textura en la secuencia, y en el momento en que se creó la textura, el widget se dibujó aproximadamente de manera similar al resultado final, solo de forma cuadrada, para dibujar todo tipo de líneas, las formas podían estar inmediatamente en la memoria de video de forma gratuita.
Casi derrotando el milagro del pensamiento chino "sin" una GPU, todavía no se puede considerar que el 20 FPS sea un resultado decente, y casi al completar el proyecto, le pedí permiso al cliente para recoger parte de la experiencia en código abierto. El primer SDL no está muy de moda ahora, por lo que se decidió usar el renderizado nanogui en modo software en SDL2 y ponerlo en el github. Tal vez alguien necesitará :)
Después de leer el artículo hasta el final,% habruiser% tiene derecho a preguntar por qué era necesario bloquear este montón de código.
para esquinas redondeadas y sombras? En primer lugar, es hermoso (s), en segundo lugar, "ese tío en un casco amarillo" ya pagó por el desarrollo del sistema y las esquinas redondeadas allí, desafortunadamente (o afortunadamente) terminaron en la lista de tareas, queda por hacerlas con un degradado y agregar algunas sombras.
Este fue el verano original de 2017 en la soleada Sochi.
Así es como se procesa OpenGLAsí se representa el software en una PCReferenciasWjakob / nanogui originalRenderizado de software NanoVGRenderizado de software NanoGUI + SDL +PD: No creas que los desarrolladores
chinos hablan de la presencia de OpenGL en el sistema, comprueba el rendimiento de todos los componentes, para saber cómo :)