Fazendo um projeto de crowdsourced em Tela - página 32
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Foi exatamente assim que eu o construí. Basicamente, tomei a biblioteca padrão como base, porque ela tem trabalhado muito bem momentos de transferência de eventos e algumas outras coisas. Anatoly cria agrupamento para cada classe diferente de elementos, no padrão tudo é reduzido a um objeto base.
...
Em seus exemplos, Nikolay mostra que não é necessário se preocupar em armazenar todos os dados das áreas locais porque a repintura de toda a tela é tão rápida, que não precisa descer aos detalhes e é o suficiente para redesenhar toda a tela de uma só vez.Não é tão simples assim. Imagine, você desenhou uma tabela grande (tabela inteira), onde uma das células muda de valor 20 vezes por segundo. Se você redesenhar a tela inteira, a carga sobre o processador aumentará até 40% ou mais. Forma absolutamente errada de trabalhar com uma lona. Você precisa redesenhar elementos separados, caso contrário tabelas, vidros e diferentes animações locais sobrecarregarão o processador e atrasarão a execução de outras funções (se elas estiverem em um fio comum).
As experiências de Nikolay até agora provam o contrário. Ele refaz todo o conteúdo da tela de uma só vez, e é claramente visível no código.
Mas eu ainda sou a favor de mudanças locais. Mas esta abordagem tem suas próprias dificuldades, que eu ainda não resolvi.
As experiências de Nikolay até agora provam o contrário. Ele refaz todo o conteúdo da tela de uma só vez, e é claramente visível no código.
Mas eu ainda sou a favor de mudanças locais. Mas esta abordagem tem suas próprias dificuldades que eu ainda não resolvi.
Considero Nikolay meu amigo e ele atingiu grandes alturas no trabalho com telas, mas ainda não realizou experimentos completos com controles. Particularmente com mesas e vidros. Em todo caso, não tenho conhecimento de nenhum.
O resultado final é este: Uma tela é um conjunto de dados. Os dados são alterados e salvos novamente em eventos de mudança. Se a matriz inclui todos os pixels do espaço do gráfico - então seu tamanho = altura*largura do gráfico. Se houver uma mudança local dos valores de pixel dentro da matriz, não há necessidade de fazer um loop completo em toda a matriz e reiniciar todos os valores. Você precisa fazer um loop na área alterada, definir os valores e sair do loop. Caso contrário, não importa como você o corte, é um desperdício de recursos e tempo.
E há muitas dificuldades com esta abordagem. A principal delas é criar objetos próprios totalmente funcionais, encontrá-los e processá-los em sua própria tela. O CCanvas interno não é adequado para isso. Ele não "veria" seus elementos e você não pode acessá-los através dele. Não existe tal funcionalidade ali.
Eu considero Nikolai um amigo meu, e ele alcançou grandes alturas com a tela, mas ainda não fez experimentos completos com os controles. Especialmente com mesas e um secador. Em todo caso, não tenho conhecimento de nenhum.
O resultado final é este: Uma tela é um conjunto de dados. Os dados são alterados e salvos novamente em eventos de mudança. Se a matriz inclui todos os pixels do espaço do gráfico - então seu tamanho = altura*largura do gráfico. Se houver uma mudança local dos valores de pixels dentro da matriz, não há necessidade de fazer um loop completo em toda a matriz e redefinir todos os valores. Você precisa fazer um loop na área alterada, definir os valores e sair do loop. Caso contrário, não importa como você o corte, é um desperdício de recursos e tempo.
E há muitas dificuldades com esta abordagem. A principal delas é criar objetos próprios totalmente funcionais, encontrá-los e processá-los em sua própria tela. O CCanvas interno não é adequado para isso. Ele não "veria" seus elementos e você não pode acessá-los através dele. Não existe tal funcionalidade ali.
Entendo tudo isso muito bem e estou bem ciente disso. Eu criei minhas próprias classes de objetos e tudo funciona bem.
Entendo tudo isso muito bem e estou muito consciente disso. Tenho minhas classes de objetos criadas e tudo funciona bem.
Neste caso, você pode verificar criando uma tabela e atualizando-a de duas maneiras - localmente (cada célula separadamente) e todas de uma só vez a tabela inteira.
As animações do Nikolai têm, em sua maioria, uma baixa taxa de atualização e, portanto, o redesenho simultâneo de toda a tela não se apresenta como uma sobreposição. Mas se você aumentar a taxa de atualização em até 5 vezes por segundo, você pode ver um aumento no consumo de recursos da CPU. Se você precisar redesenhar toda a animação - sem saída, mas com uma única e pequena área interna - melhor apenas essa.
A freqüência em si - 5 vezes por segundo - pode ocorrer em uma tabela onde os valores mudam de forma assíncrona. Esta situação me ocorreu no MT4, quando liguei a mesa ao testador através de recursos. Lá, na velocidade 31 todos os parâmetros estão mudando tão rapidamente que um redesenho incorreto da tabela causou uma carga de CPU de 50% ou mais. Mesmo o redesenho local de elementos não o salvou completamente. Tive a idéia de desacelerar o ritmo de exibição dos valores. Os valores em si estavam mudando a um ritmo natural, mas eram emitidos para as células várias vezes com menos freqüência. Isto resolveu o problema.
Aqui está um exemplo. 1000 células devem mudar os valores a uma taxa de 25ms. Na realidade, as células mudam de valor cerca de uma vez a cada 500ms e a carga da CPU é de cerca de 50%. (Este é o MT4 e a tabela está desenhada).
https://www.mql5.com/ru/forum/293630/page160
Aqui está um exemplo com o testador. A tabela é desenhada, mas não poupa o processador de sobrecarga. :) (velocidade de teste 31, atualização da célula completa (sem pinos saltando)).
https://www.mql5.com/ru/forum/293630/page148
Não é tão simples assim. Imagine que você tem uma tabela grande (para todo o gráfico) onde uma das células muda de valor 20 vezes por segundo. Se você redesenhar a tela inteira, a carga sobre o processador aumentará até 40% ou mais. Forma absolutamente errada de trabalhar com uma lona. Você precisa redesenhar elementos separados, caso contrário tabelas, vidros e diferentes animações locais sobrecarregarão o processador e atrasarão a execução de outras funções (se elas estiverem em um fio comum).
Não tenho bem certeza de onde você está obtendo seus números. Vejam o exemplo perfeitamente simples do Nikolai https://www.mql5.com/ru/forum/227736/page44#comment_13445909. Em uma tela do tamanho de um gráfico, são gerados vários objetos que podem ser arrastados e soltos sobre o gráfico (na tela). O kanvas inteiro é redesenhado. Não há nenhuma desaceleração.
Não tenho bem certeza de onde você está obtendo seus números. Vejam o exemplo perfeitamente simples do Nikolai https://www.mql5.com/ru/forum/227736/page44#comment_13445909. Em uma tela do tamanho de um gráfico, são gerados vários objetos que podem ser arrastados e soltos sobre o gráfico (na tela). O kanvas inteiro é redesenhado. Não há lentidão.
Veja os exemplos acima.
Inseriu links para as hifas.Aqui está um exemplo de diminuição da emissão de valores para as células e redução da carga sobre o processador:
https://www.mql5.com/ru/forum/293630/page148
Não tenho bem certeza de onde você está obtendo seus números. Vejam o exemplo perfeitamente simples do Nikolai https://www.mql5.com/ru/forum/227736/page44#comment_13445909. Em uma tela do tamanho de um gráfico, são gerados vários objetos que podem ser arrastados e soltos sobre o gráfico (na tela). O kanvas inteiro é redesenhado. Não há nenhuma desaceleração.
A taxa de atualização nesse exemplo é normal. Portanto, não há desaceleração.