Galeria de UIs escritas em MQL - página 57

 

@Nikolai Semko

Nikolai, agora inesperadamente veio a resposta para a pergunta"por que demora tanto para desenhar uma tela".

As janelas consistem em duas telas! Essas telas são quase iguais em tamanho. Portanto, a área de desenho deve ser multiplicada por dois. Mas isso é só o começo.

No espaço da janela, há grandes elementos de rolagem (V_BOX), que também são desenhados completamente preenchidos com a cor original. Ou seja, se a V_BOX ocupar a parte principal da janela, a área de desenho deverá ser multiplicada por três. Mas! ele tem uma tela adicional. A imagem é rolada nessa tela. A base do elemento é apenas uma barra de rolagem. Resumindo: a área de desenho deve ser multiplicada por quatro (especialmente se a barra de rolagem for longa). E só então os elementos são desenhados.

Parece que isso é tudo... Podemos colocar um ponto,multiplicar a área da janela por três ou quatro. Mas não!

Ospróprios elementos também têm várias camadas. Cada um tem uma base. A base é sempre desenhada do zero, preenchida com a cor original. Em seguida, as molduras são desenhadas sobre a base. Em seguida, os ícones são desenhados sobre as partes já desenhadas do elemento. E, por fim, os textos são desenhados em cima de tudo.

Como resultado, o usuário vê apenas a cor final em cada pixel específico. Mas, no local desse pixel, as cores mudaram várias vezes à medida que a janela inteira é desenhada.


Agora multiplique isso por 15 janelas.... Fica claro que não há nenhum bug especial no código - medi especialmente a velocidade de execução de partes do bloco de desenho, e 50 ms para uma tela inteira também funciona para mim. O problema é que acabo tendo muito mais telas.


Tenho uma ideia de como alterar o código e acelerar o desenho em 2 ou 3 vezes. Mas farei isso depois do trabalho principal.

Quero agradecê-lo por insistir em verificar o código. Você estava certo. Esse é o caso quando a crítica foi útil.

Além disso, agradeço a @AndreyBarinov pela dica com o texto. Talvez eu consiga pensar em algo.

Nikolai Semko - BeeXXI Corporation
Nikolai Semko - BeeXXI Corporation
  • 2024.07.15
  • www.mql5.com
Профиль трейдера
 
Реter Konow #:

@Nikolai Semko

...e 50ms em tela cheia também funciona para mim. ....

O teste é aproximado. Medi a velocidade de abertura de uma janela com três telas de tamanho quase igual (janela de ícones) e obtive cerca de 70 ms. Se você somar a área de todas as telas (sem elementos), terá aproximadamente a área da tela do laptop de 17". Isso não inclui a área da base dos elementos e os próprios ícones, que foram desenhados na parte superior da tela. Portanto, sim, cerca de 50 ms para preencher com cores a área de uma tela cheia fictícia. Ainda não medi isso exatamente. Por que, quando o "elefante" está bem no meio da sala? :)

 
Eu estava falando de 50 ms como uma interface sobrecarregada e não otimizada. 3-10 ms é normal

No entanto, faça alguns perfis. Você fará muitas descobertas em seu código.
 
Nikolai Semko #:
Eu estava falando de 50 ms como uma interface sobrecarregada e não otimizada. 3-10 ms é normal

Mas faça alguns perfis. Você fará muitas descobertas em seu código.
Nikolai, esses são apenas números. Você precisa de detalhes específicos. Pelo menos o tamanho da tela. Assim, você poderá fazer cálculos precisos.
 
O desenho na tela é uma inicialização de matriz. É fácil descobrir a velocidade máxima - a função com o loop de preenchimento da matriz a revelará. O tamanho da matriz deve corresponder à soma dos pixels da tela condicional.
 
Você é como Stirlitz, que não queria ir para a plantação de batatas.
Faça o perfil...
 
Nikolai Semko #:
Você é como Stirlitz, que não queria ir para a plantação de batatas.
Faça o perfil...
Eu fiz. Vou lhe enviar um gif.
 


Você precisa de um estudo aprofundado dos ciclos dentro do bloco de desenho. O perfil superficial não oferece um quadro completo. Mas já está claro qual é o objetivo. Escrevi aqui no

. Acho que não estou errado.

(versão preliminar do bloco de desenho, que uso para testes)
 
Реter Konow #:

...

Tenho uma ideia de como alterar o código e acelerar a renderização em 2 ou 3 vezes. Mas farei isso depois do trabalho principal. ...

Analisei a complexidade da tarefa e o valor do resultado final.

Conclusão: não faz sentido fazer isso.

Não faz sentido acelerar o primeiro desenho. Um segundo e meio para criar 15 janelas com gráficos complexos e barras de rolagem é um resultado normal. O primeiro desenho pode ser ocultado dos olhos do usuário, executando-o antes de abrir as janelas. Visualmente, as janelas aparecerão instantaneamente após uma pausa de meio segundo. Se, é claro, ele quiser que 15 janelas sejam abertas ao mesmo tempo, o que é improvável.

Não é necessário desenhar a parte de trás da janela. Haverá um ganho de aproximadamente 20 ms. Isso não parece impressionante.

Na semana passada, o principal foi alcançado: usar imagens salvas em todos os eventos, exceto na primeira compilação. Esse é um grande ganho na velocidade da interface.

O restante dos atrasos tem a ver com o redesenho de janelas ao mudar o foco ou com chamadas desnecessárias. Correções fáceis. Não quero que esse grande ganho seja ignorado por causa do tempo de carregamento, que não é tão importante. No entanto, mudei meu próprio foco de atenção. Você deveria ter mudado.

Aqui, encerro a questão da velocidade da primeira renderização, por causa de sua irrelevância e irrelevância para o desenvolvimento atual.

Próxima atualização no domingo. Lançarei um mecanismo com um mecanismo conceitualmente completo de interação do software com o programa do usuário.
 
Реter Konow #:
Analisei a complexidade da tarefa e o valor do resultado final.

A conclusão foi que não fazia sentido.

Criar 15 janelas com gráficos complexos e barras de rolagem em um segundo e meio é um resultado normal. É possível desenhar o primeiro gráfico antes de abrir a janela para que ele não seja visto pelo usuário. Visualmente, a janela aparecerá imediatamente após uma pausa de meio segundo. Obviamente, se o usuário quiser ter 15 janelas abertas ao mesmo tempo, isso é improvável.

Não é necessário desenhar a parte de trás da janela. Haverá um ganho de aproximadamente 20 ms. Isso não parece incrível.

Na semana passada, atingimos nosso principal objetivo: usar imagens salvas para todos os eventos, exceto a primeira compilação. Isso representa um enorme aumento de velocidade para a interface.

O restante dos atrasos estava relacionado ao redesenho da janela ao mudar o foco ou a chamadas desnecessárias. Isso é fácil de corrigir. Não quero ignorar esse grande aprimoramento por causa dos tempos de carregamento, que não são tão importantes. No entanto, mudei meu foco. Você deveria ter

Aqui, encerrei o primeiro problema de velocidade de renderização porque ele não é relevante ou importante para o desenvolvimento atual.

A próxima atualização será no domingo. Apresentarei um mecanismo com um mecanismo conceitualmente completo de interação entre o software e o programa do usuário.

Sim, é muito importante que o software totalmente funcional seja lançado primeiro.