Galeria de UIs escritas em MQL - página 55

 
Acho que se você não desenhar a parte invisível da parte de trás, poderá acelerar o primeiro desenho da janela em pelo menos um terço. Ainda não tenho certeza, você precisa verificar. Deixe que ele desenhe apenas a moldura e o chapéu. Pule o resto. De qualquer forma, haverá um ganho.
 
Andrey Barinov #:

A tela de tela cheia também é redesenhada completamente toda vez que eu mudo, mas isso não leva mais de 50 ms...

O mais caro é desenhar o texto. Portanto, para não usar TextOut toda vez, eu os armazeno em matrizes. O resultado é muito mais rápido.

Sim, o TextOut é usado. Vou pensar no que pode ser feito com ele.

 
Em geral, até a próxima versão, refatorarei o bloco de desenho e aumentarei a velocidade, mas o mais importante é que terminarei o mecanismo.
 
Реter Konow #:

Bem, a aritmética simples funciona aqui: a soma das áreas de 10 a 17 janelas é muito maior do que a tela inteira. Concordo. Além dos desenhos adicionais secundários necessários para criar sombras, ícones, quadros....

E sobre o TextOut, vou verificar e escrever. Ideia interessante.

Não entendo sua aritmética simples :). Na minha aritmética, não há necessidade de desenhar os pixels que não são visíveis para o usuário, e o tamanho máximo da tela para desenho é limitado pelo tamanho da tela em pixels.

Eu desenho em camadas, independentemente do número de janelas, tudo em um único bitmap. Pode haver até cem janelas. As primitivas simples são desenhadas em um período de tempo minúsculo. O mais demorado, como escrevi acima, são os textos. Mas eles contam com a ajuda do TextOut no primeiro uso e, além disso, já vêm de matrizes prontas.

 

Um plano para trabalhos futuros precisa ser aprovado.

Farei uma atualização toda semana. Sábado ou domingo.

1. No próximo lançamento, lançarei uma versão completa do mecanismo. Corrigirei bugs e acelerarei a renderização.

2. A segunda versão será dedicada às tabelas. Restaurarei os recursos básicos.

3. a terceira versão - criarei tabelas dinâmicas. Espero implementá-las em uma semana. Vou tentar.

4. Quarta versão - janela dinâmica. Tentarei publicar a versão finalizada.


Nesse estágio, as versões básicas do construtor, do mecanismo e da linguagem de marcação podem ser consideradas completas.

Com certeza abrirei uma seção de modelos escritos em código KIB, onde publicarei janelas e grupos de elementos concluídos. Com ilustrações para facilitar a vida de quem quiser criar a interface.

E tentarei escrever artigos tutoriais para que as pessoas possam usar toda a gama de possibilidades.


Neste tópico, continuarei publicando códigos, imagens e material explicativo sempre que possível. Estarei muito ocupado com o trabalho mencionado acima.

 
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 um 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 um link para um gráfico).
De qualquer forma, execute a criação de perfil. Isso levará apenas 40 segundos.
 
Ramificações de modeloescritas em código KIBque
Não deve ser misturado com o código do construtor. Ele deve ser lançado como um projeto separado.
 
Andrey Barinov #:

Não entendo sua aritmética simples :). Na minha aritmética, não há necessidade de renderizar os pixels que não são visíveis para o usuário, e o tamanho máximo da tela para renderização é limitado pelo tamanho da tela em pixels.

Eu desenho em camadas, independentemente do número de janelas, tudo em um único bitmap. Pode haver até cem janelas. As primitivas simples são desenhadas em um período de tempo minúsculo. O mais demorado, como escrevi acima, são os textos. Mas eles contam com a ajuda do TextOut no primeiro uso e, além disso, já vêm de matrizes prontas.

Trabalhar com uma tela grande tem muitas limitações. Eu já havia pensado nessa opção e até mesmo discutido com Nikolay.

Deixe-me explicar: você faz isso porque usa a classe Ccanvas padrão. Há soluções prontas dentro da estrutura com a qual você trabalha. Mas eu não uso a classe Ccanvas. Todos os códigos de renderização são de desenvolvimento pessoal. É por isso que não me atenho ao conceito - uma tela para TUDO. Na minha opinião, essa é uma solução tecnicamente inconveniente e ineficiente em um ambiente gráfico. É mais fácil usar conjuntos de objetos bitmap e anexar recursos prontos a eles do que ter um bitmap e criar programaticamente a interação de imagens nele. Isso é até difícil de imaginar. Mas isso não é o principal.

Imagine como é muito mais difícil realizar o conceito de uma GUI com várias janelas se você tiver apenas UMA tela. Eu não assumiria uma tarefa dessas.

Mas nem mesmo isso é decisivo. O principal motivo para rejeitar a ideia de uma tela para todas as imagens: quando há apenas uma tela, mover as janelas da interface requer redesenho dentro do ambiente MQL. Por outro lado, se cada janela ocupar seu próprio objeto bitmap e for movida pela função ObjectSetInteger(), - o redesenho dos objetos movidos recai sobre funções padrão que funcionam fora do ambiente MQL. Portanto, é muito mais rápido.

Você só tem uma direção de desenvolvimento diferente, na qual outras soluções funcionam com mais eficiência.


Muito obrigado pela dica sobre o TextOut. Vou investigar esse ponto.

 
hini #:
As ramificações de modelo são escritasem código KIB que
Não deve ser misturado com o código do construtor. Ele deve ser lançado como um projeto separado.

Sim, para depuração, implementarei a desconexão do programa do usuário do mecanismo, se foi isso que você quis dizer. Provavelmente você não entendeu.

 
Реter Konow #:

Trabalhar com uma tela grande tem muitas limitações. Já pensei nessa opção e até discuti isso com Nikolay.

Deixe-me explicar: você faz isso porque usa a classe Ccanvas padrão. Há soluções prontas dentro da estrutura com a qual você trabalha. Mas eu não uso a classe Ccanvas. Todos os códigos de renderização são escritos por desenvolvimento pessoal. Portanto, não me apego ao conceito - uma tela para TUDO. Na minha opinião, essa é uma solução tecnicamente inconveniente e ineficiente em um ambiente gráfico. É mais fácil usar conjuntos de objetos bitmap e anexar recursos prontos a eles do que ter um bitmap e criar programaticamente a interação de imagens nele. Isso é até difícil de imaginar. Mas isso não é o principal.

Imagine como é mais difícil concretizar o conceito de uma GUI com várias janelas se você tiver apenas UMA tela. Eu não assumiria uma tarefa dessas.

Mas nem mesmo isso é decisivo. O principal motivo para rejeitar a ideia de uma tela para todas as imagens: quando há apenas uma tela, mover as janelas da interface requer redesenho dentro do ambiente MQL. Por outro lado, se cada janela ocupar seu próprio objeto bitmap e for movida por ObjectSetInteger(), o redesenho ao mover recai sobre funções padrão que funcionam fora do ambiente MQL. Portanto, é muito mais rápido.

Você só tem uma direção de desenvolvimento ligeiramente diferente, na qual outras soluções funcionam com mais eficiência.


Muito obrigado pela dica sobre o TextOut. Vou investigar esse ponto.

Só que NÃO estou usando o kanvas padrão :).

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


E, na prática, parece ser mais rápido redesenhar a tela inteira do que usar ObjectSetInteger, etc. ....