Galeria de UIs escritas em MQL - página 53
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
Rether, você poderia mudar o catálogo para inglês em versões futuras? Os arquivos de código-fonte que contêm os nomes do catálogo são substituídos por texto.
Sim, é claro. Já pensei nisso. Farei uma versão de lançamento especial com os nomes do catálogo em inglês.
Não estou verificando os arquivos, apenas os comentários aqui. Mas esse "atraso", para mim, parece não estar relacionado à velocidade, mas ao uso do ChartRedraw antes de criar completamente o novo recurso. Porque ele pisca com uma tela em branco e depois mostra a nova tela.
Com certeza. Pensei um pouco sobre isso. Farei um lançamento especial que incluirá o nome do catálogo em inglês.
Eu sugeriria não fazer uma versão especial com catálogos em inglês, mas fazer apenas uma versão em inglês, mudando apenas o nome do catálogo para inglês, e a próxima etapa seria mudar o nome do arquivo para inglês, e você ainda escreverá o código-fonte em russo.
Eu concordo. Vou mudar gradualmente para nomes de diretórios em inglês. Dessa forma, será mais racional.
Não verifiquei os arquivos, apenas os comentários aqui. Mas esse "atraso" para mim não parece estar relacionado à velocidade, mas ao uso do ChartRedraw antes que o novo recurso seja totalmente criado. Porque ele exibe uma tela em branco e depois mostra a nova tela.
Ideia interessante, vou tentar testá-la. Obrigado.
E então, uma atualização...
Esta é uma atualização provisória. Lançarei a próxima versão em alguns dias. Haverá uma nova funcionalidade para a interação do programa com os controles.
Devo dizer o seguinte: trabalho em duas versões - a 2470 e a nova. A maior parte do desenvolvimento é feita na versão antiga. A compilação é mais rápida lá - 4 segundos contra 26-32 segundos. A nova compilação funciona de forma um pouco diferente e isso é visualmente perceptível. Às vezes é mais rápida, às vezes é mais lenta. Talvez seja essa a sensação. É difícil encontrar uma diferença, mas, para mim, ela parece estar presente. A interface na versão antiga voa. Na nova. Quase voa. Talvez eu ache que é porque estou acostumado com ela.
No entanto, há nuances. Por exemplo, há um problema com a troca de gráficos, quando são retornados valores incorretos de altura e largura do gráfico. Isso faz com que a barra de tarefas salte. Consegui contornar esse problema, mas a barra de tarefas não reage a outros eventos de redimensionamento de gráficos. No final, decidi deixá-la como estava. A barra de tarefas saltará na troca de gráficos (desde que haja um problema de retorno de valores incorretos), mas se adaptará normalmente em outros eventos.
Mas isso não é tudo. Acontece que os eventos de redimensionamento do gráfico não ocorrem instantaneamente e há uma pausa de meio segundo. Esse atraso é sobreposto ao tempo de redesenho da barra de tarefas e você obtém um atraso decente. Aqui eu sou impotente.
Vou dizer o seguinte: é claro que acelerei significativamente os gráficos, mas ainda há algumas outras soluções não otimizadas no código. Estou trabalhando duro para resolvê-los. A maior parte diz respeito à transição do foco da janela e à fila de redesenho. Ocorrem algumas chamadas desnecessárias. Atrasos na barra de tarefas. Corrigi o que tinha tempo para corrigir, embora não tudo. Mas o resto é questão para os próximos dias. Caso contrário, não há muito o que melhorar... talvez apenas pentear e perfumar o código para torná-lo perfumado)).
Em geral, se depurarmos todas as soluções não otimizadas restantes, ele voará... bem, dentro das velocidades disponíveis para um programa MQL, é claro.
Veja a versão.
E assim, uma atualização...
...
Deixe-me colocar desta forma: os gráficos, é claro, foram significativamente acelerados, mas ainda há algumas outras soluções não otimizadas no código. Estou trabalhando duro para resolvê-las. A maior parte diz respeito à transição do foco da janela e à fila de redesenho. Ocorrem algumas chamadas desnecessárias. Atrasos na barra de tarefas. Corrigi o que tinha tempo para corrigir, embora nem tudo. Mas o resto é questão para os próximos dias. Caso contrário, não há muito o que melhorar... talvez apenas pentear e perfumar o código para torná-lo perfumado)).
Em geral, se depurarmos todas as soluções não otimizadas restantes, ele voará... bem, dentro das velocidades disponíveis para um programa MQL, é claro.
Veja a versão.
Deixe-me esclarecer: estamos falando de velocidade aqui. Se você corrigir as falhas de redesenho da janela no evento de mudança de foco, a velocidade da interface estará no limite superior de um programa MQL. Os atrasos da barra de tarefas podem ser parcialmente corrigidos. Encontrei uma boa solução: aplicar na mecânica da barra de tarefas o princípio de uma janela dinâmica - ela não fica mais lenta ao ser redimensionada, quando é puxada pelo quadro. Ela se ajustará mais rapidamente e de forma mais imperceptível. E, é claro, precisamos cancelar redesenhos desnecessários. Isso é obrigatório. Mas se os próprios eventos CHARTEVENT_CHART_CHANGE chegarem ao programa com um atraso, o atraso visível das reações da barra de tarefas será inevitável, embora não tenha nada a ver com isso.
Caso contrário, há muitas direções de desenvolvimento e aprimoramento da interface.
Mais algumas palavras sobre a velocidade da interface.
Passei muito tempo verificando atrasos e procurando freios de renderização. O bloco responsável pelo layout do kanvas foi criado de tal forma que, antes de inicializar a matriz que vai criar um recurso na função ResourceCreate(), ele define os limites do loop nos detalhes da janela. Ele faz isso com a ajuda de filtros de condição configurados para verificar os eventos recebidos. Cada evento que chama o bloco recebe limites de desenho. Por exemplo, no evento da reação do elemento ao passar o cursor, o filtro com os limites do loop somente nos detalhes de um elemento específico é ativado. O bloco seleciona apenas seus detalhes na imagem obtida. E durante o ciclo de detalhes, ele desenha seletivamente apenas esses detalhes entre o restante da imagem. Ele encontra com precisão os locais para inicializar e desenhar o detalhe correto do elemento correto. Ao mesmo tempo, ele ignora corretamente o restante do espaço da imagem.
Mas a aceleração não é apenas isso. O bloco não inicializa os pontos da tela se a cor deles corresponder ao valor necessário. Além disso, ele não "percorre" a matriz, mas "salta", percorrendo as distâncias. Isso reduz os ciclos em centenas de milhares de iterações.
E não é só isso. Como a matriz de imagens é global (declarada em nível global), ela sempre armazena a alteração da última imagem em sua memória. E se as alterações continuarem a ocorrer na mesma tela, em vez de limpar sua matriz a cada vez, a imagem armazenada será usada. Se o nome do recurso não for alterado no próximo evento, não haverá necessidade de chamar ResourceReadImage() nem de enviar a matriz de tela novamente para ser preenchida. O bloco continua a trabalhar com os dados restantes sem chamar ResourceReadImage() e atualiza a imagem com ResourceCreate() após a alteração.
Isso economiza muito tempo nas chamadas ResourceReadImage(). E também na limpeza e no preenchimento da matriz. É um bom uso da memória global, não é?
Ao redesenhar janelas, o bloco não é chamado de forma alguma. Os componentes da janela são apagados e criados, e os recursos salvos anteriormente são anexados a eles. Não há renderização.
Com tudo isso, ainda há atrasos, e eles são inevitáveis. Vou explicar o que está acontecendo.
Na primeira abertura de uma janela, ou na primeira abertura de uma guia, ou no evento de uma lista de árvore, ou ao minimizar/desmodelar espaços grandes, há um redesenho completo obrigatório das telas. Até o momento de criar recursos de imagem que podem ser vinculados/alterados com eficiência muitas vezes depois, SEMPRE é necessário desenhar uma imagem completa do zero. O primeiro desenho é SEMPRE o mais demorado. Não há nada para salvar, não há imagem salva. É quando você abre a imagem pela primeira vez que sempre vê atrasos. Isso é inevitável.
No entanto, há uma boa solução aqui também: mover os atrasos da abertura de janelas para o evento de carregamento. O que quero dizer é: na etapa de carregamento do construtor em segundo plano, desenhe todas as imagens e salve-as em recursos com antecedência, para que tudo esteja pronto ao abrir. Assim, o usuário não verá nenhum atraso ao abrir as janelas pela primeira vez. É claro que isso é ótimo, mas há uma desvantagem. O atraso da primeira abertura se transformará em um atraso de carregamento e seu tempo aumentará. É difícil dizer quanto. Acho que, em média, em um segundo. Depende da interface específica.
Acho que essa opção é preferível. Prefiro deixar a interface do designer/usuário carregar um pouco mais, mas não haverá mais atrasos na abertura visual.
Gostaria de ouvir suas opiniões sobre isso.
Adicionado:
Houve uma ideia de salvar os recursos da interface após o primeiro carregamento em um arquivo. Assim, os carregamentos subsequentes serão muito mais rápidos, pois os recursos necessários já estão à disposição do designer/motor. Preciso pensar sobre isso.