Galeria de UIs escritas em MQL - página 56

 
Andrey Barinov #:

Eu simplesmente NÃO estou usando a tela de estoque :).

E achei mais fácil implementar uma interface de várias janelas em um bitmap. Mas cada um faz o que quer!

Infelizmente, não em todos os casos. Para minhas tarefas, é tecnicamente mais fácil trabalhar com um conjunto limitado de bitmaps. E 100% mais rápido. Muito mais rápido.

Mas, para outros desenvolvimentos, outras soluções funcionam melhor e, portanto, sim, cada um tem a sua. :)

 
Nikolai Semko #:
Não Perth, ainda é demais. Sua interface com todo o texto, sombras etc. atinge o máximo de 50 ms em um processador fraco.
Procure o bug.
Execute a criação de perfis. Veja quais funções consomem 95% do tempo.
Talvez você esteja usando as funções ChartGet ou XY (embora não tenha uma ligação com um gráfico).
De qualquer forma, execute a criação de perfil. Isso levará apenas 40 segundos.

Sim, vou verificar tudo novamente. Mas esse não é o ponto. O bloco de desenho não se limita a desenhar. Há labirintos lógicos dentro dele que processam os eventos que chegam. Eles são necessários para determinar o que desenhar e o que não desenhar. Escolher de onde tirar as imagens, onde e como sobrepô-las. Se fosse uma simples função de desenho de 100 linhas, não haveria nada a dizer. Mas esse é um mecanismo enorme para garantir que TUDO seja desenhado.

Vale a pena levar isso em consideração)).

 
Andrey Barinov #:

Eu simplesmente NÃO estou usando a tela de estoque :).

...

E essa é uma surpresa agradável. :) O autodesenvolvimento é sempre legal. Mesmo que seja imperfeito.

Não me importo com a classe Ccanvas (até incluí sua funcionalidade nos arquivos do construtor), mas ainda não a utilizo. A palavra-chave é "ainda". Tenho grandes planos para ela. No futuro.

 
Verificarei a velocidade de renderização de uma tela verde em branco do tamanho do gráfico e a publicarei aqui.
 
Реter Konow #:

Sim, vou checar tudo novamente. Mas essa não é a questão. O bloco de desenho não apenas desenha. Há labirintos lógicos dentro dele que processam os eventos recebidos. Eles são necessários para determinar o que desenhar e o que não desenhar. Escolher de onde tirar as imagens, onde e como sobrepô-las. Se fosse uma simples função de desenho de 100 linhas, não haveria nada a dizer. Mas esse é um mecanismo enorme para garantir que TUDO seja desenhado.

Vale a pena levar isso em consideração)).

Não, quando implementado corretamente, o modelo de evento não leva mais do que um microssegundo (um milionésimo de segundo), mesmo que haja milhares de verificações.
Procure um bug.
E pare de ficar na defensiva! Ninguém está atacando você, eles só querem ajudá-lo.
Tenho defasagens perceptíveis (>300 ms) que começam com 100 mil objetos e estão vinculadas ao preço-tempo.
 
Nikolai Semko #:
Não, quando implementado corretamente, o modelo de evento não leva mais de um microssegundo (um milionésimo de segundo), mesmo que haja milhares de verificações.
Procure um bug.
E pare de ficar na defensiva! Ninguém está atacando você, eles só querem ajudá-lo.
Tenho atrasos perceptíveis (>300 ms) que começam com 100 mil objetos e estão vinculados ao preço-tempo.

Não estou na defensiva))) Ha ha. Estou apenas explicando. ))

Certo. Vou começar com um teste simples. Preencherei uma tela inteira com uma cor e medirei o tempo. Faça medições da sua função de renderização e, então, ficará mais claro se eu tenho freios no meu código. Talvez haja. Não estou discutindo. Preciso verificar.

 
Реter Konow #:

Não estou sendo defensivo). Ha ha. Só estou explicando. ))

Certo. Vou começar com um teste simples. Preencherei uma tela inteira com uma cor e medirei o tempo. Faça medições da sua função de renderização e, então, ficará mais claro se eu tenho freios no meu código. Talvez haja. Não estou discutindo. Preciso verificar.

Achei que talvez você nunca tenha trabalhado com criação de perfil. Você também não trabalha com depuração.


 
Nikolai Semko #:

Achei que talvez você nunca tivesse trabalhado com criação de perfil. Você também não trabalha com depuração.


Não com depuração. Não posso fazer isso por causa do código russo. Já trabalhei com criação de perfil. Mas há muito tempo. Gosto de codificar à moda antiga. É assim que as coisas são.

Farei isso amanhã. Nos últimos dias, tenho trabalhado das 6:00 da manhã às 10:00 e 11:00 da noite. De vez em quando. Estou um pouco cansado.
 
A velocidade provavelmente pode ser colocada em segundo plano e a otimização da velocidade não é algo que possa ser feito rapidamente; por enquanto, é melhor melhorar a funcionalidade.
 
hini #:
A velocidade provavelmente pode ser relegada a segundo plano, e a otimização da velocidade não é algo que possa ser feito rapidamente; por enquanto, é melhor melhorar a funcionalidade.
Bem, é sempre bom para um programador melhorar a velocidade. E, em geral, eu concordo. É razoável. A priorização adequada no desenvolvimento é muito importante. Especialmente em projetos tão grandes. Foi importante para mim saber o quanto a velocidade é importante para os usuários. Por assim dizer, para obter feedback. O aumento da velocidade por si só não fazia parte dos meus planos iniciais. Eu só queria que os usuários não ficassem com medo de atrasos quando olhassem para a interface. :)

É claro que a funcionalidade dos elementos ainda é minha prioridade. Motor, elementos, bugs. Isso é o principal.