Normalmente, os utilitários de trabalho não exigem uma interface de usuário sã, com botões, listas, janelas, suporte para mouse e outras pequenas coisas, a maioria das Wishlist funcionais pode ser empacotada em scripts e às vezes executá-las com o parâmetro --help, e isso será ainda mais correto do ponto de vista da configuração e dimensionamento. Tudo piora quando não apenas a equipe de desenvolvimento, mas também pessoas de terceiros começam a usar as ferramentas. E eles nem sempre estão prontos para mergulhar nos pensamentos harmoniosos estabelecidos nas linhas de código. E então você precisa fazer um barulho na interface do usuário, e os desenvolvedores geralmente a tornam simples, prática, funcional e completamente chata. Há algum tempo, eu estava trabalhando em um pequeno sistema de controle de ventilação / aquecimento / câmera e também “o que o tio de capacete amarelo inventaria” para um estacionamento subterrâneo.
(Aqui estava uma foto do sistema da interface do usuário, mas o desenvolvedor pediu para removê-lo. Se você não quiser ler sobre passeios no campo rake, vincule-o ao github no final do artigo)
O sistema foi construído no SoC chinês sem nome, para o qual o fabricante decidiu portar a estrutura SDL da primeira versão. As ferramentas e scripts internos foram finalizados a tal ponto que se transformaram em um layout pesado e "bonito", com guias, listas, pop-ups, sombras, gradiente, transparência e outros itens.
Para realizar todas as belezas, o nanogui foi escolhido, simples e despretensioso, e ao mesmo tempo "poderoso" tudo o que era necessário. Estava exatamente no papel, mas os
barrancos se esqueceram do OpenGL. Os sistemas de controle de interface do usuário quase completamente implementados começaram a rodar no hardware e, em uma tela preta, todas as inicializações do OpenGL3 ficam sem erros, os buffers são configurados e os shaders serão compilados, mas não ... a tela preta, em que ângulo não parece.
No início, eles pecaram nas minhas mãos tortas, depois nas mãos do desenvolvedor Antokha responsável pelo driver e pelo hardware, depois lançaram um exemplo de teste de renderização em triângulo do SoC SDK e, novamente, a tela preta, a documentação e os exemplos geralmente são lidos por último.
Meu colega e eu pensamos em algo errado e fomos primeiro ao fórum chinês, e não tendo encontrado respostas claras para o desenvolvedor lá, a resposta foi decepcionante, não houve implementação em opengl, e provavelmente não, porque a linha estava sendo descontinuada.
- Mas e a estrutura SDL? - perguntamos
- Desenhamos pixel por pixel na memória de vídeo. - Nossos amigos chineses nos responderam.
Naquele dia, vi os olhos tristes de um programador que calcula quanto LoC ele enviará para / dev / null. Mas jogar uma solução pronta foi muito decepcionante
(na Internet há tudo) acontece que você pode viver sem o OpenGL no nanogui em uma renderização de software.
Somente a vida acontece muito lentamente, em um PC grande, alguns segundos por quadro, no milagre da engenharia chinesa, já são cerca de 20 a 25 segundos para desenhar. Eles decidiram não renderizar toda a interface do usuário de uma só vez, mas apenas as partes necessárias (alteradas) dos widgets, mas mesmo neste modo, com todos os hacks e otimizações, foram necessários mais de 10 segundos por quadro, inviáveis ...
Tendo fumado alguns exemplos de SDK, descobrimos que copiar texturas prontas para a memória de vídeo é "instantâneo" (comparado a 10 segundos, é claro), e leva de 1 a 512x512 sem transparência e 2ms com transparência, se você copiar várias dessas texturas uma após a outra e depois O tempo cresce de maneira não linear, catastroficamente, devido à quantidade limitada de buffer de memória de vídeo, cujo excesso levou a liberar o buffer e renderizar o que estava na tela (não a minha, ela já estava lá), ou seja, para uma interface não completamente inoperante, não podemos copiar mais de 50 a 100 texturas por quadro e não imediatamente, mas somente depois de esperar o driver de vídeo tirar os dados do buffer.
A próxima iteração foi a renderização do widget em sua própria textura no fluxo e, no momento em que a textura foi criada, o widget foi desenhado aproximadamente semelhante ao resultado final, apenas de forma quadrada, para desenhar todos os tipos de linhas, as formas poderiam estar imediatamente na memória de vídeo gratuitamente.
Quase derrotando o milagre do pensamento chinês "sem" uma GPU, você ainda não pode considerar os 20 FPS um resultado decente e, depois de quase concluir o projeto, pedi ao cliente permissão para adquirir parte da experiência em código aberto. O primeiro SDL não está muito na moda agora, então foi decidido usar o nanogui render no modo de software no SDL2 e colocá-lo no github. Talvez alguém precise :)
Depois de ler o artigo até o final, o% habruiser% tem o direito de perguntar por que era necessário bloquear esse monte de código
para cantos arredondados e sombras? Em primeiro lugar, é lindo, em segundo lugar, "aquele tio de capacete amarelo" já pagou pelo desenvolvimento do sistema e os cantos arredondados por lá, infelizmente (ou felizmente) acabaram na lista de tarefas, resta fazê-los com um gradiente e adicionar algumas sombras.
Este foi o verão original de 2017 na ensolarada cidade de Sochi.
É assim que o OpenGL renderizaÉ assim que o software é renderizado em um PCReferências :
Wjakob / nanogui originaisRenderização do software NanoVGRenderização do software NanoGUI + SDL +PS Não acredito que os desenvolvedores
chineses falando sobre a presença do OpenGL no sistema, verifique o desempenho de todos os componentes, para saber como :)