Erros, bugs, perguntas - página 976
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
...
É estranho, eu tenho a imagem oposta:
Tenho este resultado:
Fórum sobre comércio, sistemas de comércio automatizados e testes estratégicos
Erros, Erros, Perguntas
Renat, 2013.04.27 13:32
Eu também farei os testes e escreverei os resultados.Esqueci-me completamente que ao testar as etiquetas, o desenho é completamente derivado do sistema MQL5 e desenhado no fluxo da interface. Na MQL5, apenas as descrições das etiquetas são modificadas.
Ao desenhar um bitmap, todo o desenho é realizado dentro da MQL5 e apenas um único BitBlt muito rápido permanece no fluxo da interface.
Ou seja, os testes são completamente incorrectos porque o mapeamento de marcadores não é testado de todo. A actualização do gráfico é um comando assíncrono que apenas envia uma notificação para a linha de interface a renderizar. Como se pode ver na imagem do ecrã com os custos ChartRedraw.
Argb_normalize é melhor não usar, uma vez que dá um custo extra para a normalização da cor. É melhor pintar coisas simples em cores puras.
O canal alfa tem um apelo estético. Quando o texto é exibido "transparentemente" em cima dos gráficos/bolas, aconclusão óbvia a tirar é que existe uma separação de utilizações.
No caso de querer apenas exibir uma mensagem/estatística, a etiqueta de texto é mais rápida. No caso decriar controlos (tais como botões) - bitmap, e sem opções. Depois pode preencher toda a área rectangular com cor sólida, sem canal/transparência alfa, sem demasiada frustração.
A remoção da função ChartRedraw() do laço está incorrecta, porque a "operação atómica" da mudança de propriedade da etiqueta de texto não é tratada pelo motor de vídeo do terminal.
Sim, exactamente da mesma forma como o trabalho com a matriz não é tratado pelo motor de vídeo.
o problema é descobrir o que funciona mais rapidamente - mudar um bitmap ou mudar um rótulo.
a criação de bitmap perde - isso é certo.
e a apresentação do gráfico em ambos os casos é discutível e secundária.
Basta pensar nos resultados. Vê que 4 segundos por ciclo de mudança de rótulos ???? é um disparate.
as alterações das etiquetas devem ser verificadas apenas na alteração, não interferindo com o subsistema de renderização do gráfico.
caso contrário, veria números comparáveis com um bitmap.
Esqueci-me completamente que ao testar as etiquetas, o desenho é completamente derivado do sistema MQL5 e desenhado no fluxo da interface. Na MQL5, apenas as descrições das etiquetas são modificadas.
Ao desenhar um bitmap, todo o trabalho é realizado dentro da MQL5.
Mas o rótulo ainda muda mais rapidamente do que o bitmap em termos de velocidade. Por causa das lentas funções do GDI.
Por outras palavras, o teste está completamente errado, uma vez que o mapeamento de marcas não é testado de todo. A actualização do gráfico é um comando assíncrono que apenas envia uma notificação para o fio de interface a ser desenhado. Que é o que se pode ver na imagem do ecrã com custos ChartRedraw.
Exactamente.
Penso que precisamos de testar sob algumas tarefas pesadas específicas . quem irá levar a cabo uma tarefa de referência como esta?
- Desenho de um gráfico (por exemplo, onda sinusoidal) usando um monte de etiquetas (rectângulo) e usando um bitmap.
- desenhar uma tabela de excel (rectângulo + rótulo de texto) e como um bitmap.
e outras opções onde os gráficos MT podem ser substituídos por bitmaps.
verificar o consumo de recursos para suportar um bitmap e muitos objectos MT . + dependência do tamanho das áreas a serem preenchidas.
Outra coisa que se pode ver no teste de rótulos é que existe uma operação de escrita de sentido único muito económica, sem rótulos lidos. Neste caso, há uma piperização rápida máxima do fluxo de comando para a escrita (neste caso, utilizamos propositadamente um sistema eficiente).
Mas se misturar a escrita com a leitura de dados de objectos, o que é frequentemente o caso no trabalho real, então a velocidade cai drasticamente.
Actualização: Também no exemplo de teste de marcadores há erro crítico - apenas uma modificação vai para um marcador, não 26. Dêem uma vista de olhos à fonte.
Ou seja, os testes são completamente incorrectos, uma vez que não testam de todo o mapeamento de rótulos.
As alterações da etiqueta devem ser testadas puramente para alterações, sem que o subsistema de renderização gráfica seja varrido para dentro.
Eu, é claro, discordaria. Argumento: é desejável que o utilizador veja a situação mudar (stats) o mais frequentemente possível, em cada tick. Portanto, após a actualização das estatísticas, estas devem ser mostradas = ChartRedraw().
Isto é, por assim dizer, em termos da aplicação imediata/carácter prático do desempenho.
Quanto aos padrões de referência esféricos no vácuo - isto é opcional.
mas a marca ainda muda mais rapidamente do que o bitmap em termos de velocidade. Por causa das lentas funções do GDI.
Há também umerro críticono exemplo do teste de etiqueta - apenas uma etiqueta é modificada, não 26. Olha para a fonte.
O texto muda em todas (metade) das etiquetas, que são concebidas para exibir o valor do indicador e não a sua descrição. Quando se executa o guião, pode-se ver isso.
Ou não o compreendo. De que linha em particular estamos a falar?