Fazendo um projeto de crowdsourced em Tela - página 18
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
Infelizmente, as tentativas atuais de lidar com o problema do atraso na atualização da imagem, salvando uma matriz com uma "máscara digital", não foram bem sucedidas. No entanto, também não é um fracasso. Simplesmente não foi possível tirar uma conclusão definitiva sobre a causa do atraso e encontrar uma solução global para o problema.
Ao pensar em métodos gerais de armazenar a imagem acabada na memória e trabalhar com suas áreas, passei por várias opções. As que eu pensava que eram uma boa solução, mas após profunda reflexão, revelaram-se impraticáveis.
E assim - minhas conclusões:
1. Se você quiser salvar imagens em arrays, deve haver muitos arrays. Ou seja, cada recurso requer sua própria matriz de memória constante. Em minha implementação, o número de telas (recursos, telas) poderia ser várias vezes maior do que o número de janelas.
Explicarei por quê:
Em alguns casos esta abordagem é muito mais conveniente do que desenhar todos os objetos da janela em uma tela, por exemplo, ao rolar uma mesa em um elemento "campo de visão (VEIW BOX)", é conveniente colocar os elementos da mesa em uma tela separada dentro deste elemento e rolar esta tela como um objeto inteiro. A velocidade de rolagem é mais rápida. Assim, cada um desses elementos carrega um kanvas separado dentro dele. Caso contrário, ele terá que sobrescrever toda a imagem da janela salva na memória. Isto com certeza levará muito mais tempo.
Além disso, é bastante inconveniente desenhar todas as janelas em uma tela, como movê-las então? Suponha que criemos uma "mega" tela para toda a área gráfica. Todas as nossas janelas serão desenhadas sobre ele. Depois de desenhar as janelas sobre a tela, tentaremos movê-las, mas para isso teremos que reescrever todo o quadro desta "mega" tela. O quadro é muito grande e a quantidade de valores reescritos será enorme. Mesmo se a imagem for salva, teremos que sobrescrever uma enorme área na memória a cada deslocamento do cursor. Obviamente, isto é ineficiente.
2. Pensando em um método para salvar imagens e trabalhar com elas, lembrei-me da função "ResourceReadImage()". Esta função lê o recurso e coloca sua máscara numérica em uma matriz. Portanto, - não há necessidade de salvar a imagem, pois ela já está salva em nível terminal e pode ser chamada usando esta função. Isto simplifica muito a tarefa. E assim: você pode buscar a imagem com "ResourceReadImage()", colocá-la em um array e depois alterar os valores do array, relativos a um elemento particular que está "sob o evento" da interface. Esta abordagem parece mais atraente, na minha opinião. Entretanto, a questão permanece - quanto tempo levará para preencher a matriz com uma imagem usando "ResourceReadImage()"? Obviamente, isto também depende da área do kanvas. Ele pode não ser visualmente perceptível, mas em qualquer caso deve ser carregado apenas uma vez enquanto o cursor estiver localizado em uma determinada área de kanvas. Ao mudar para outra tela, você pode limpar a matriz e carregar a imagem da outra tela.
De qualquer forma, não tenho uma solução final no momento. Tenho que tentar com a função "ResourceReadImage()", medir o tempo de carregamento da imagem e desenvolver um sistema de trabalho com áreas de imagem na matriz.
Isso é tudo por enquanto.Реter Konow:
Na minha implementação da interface, o número de telas (recursos, telas) pode ser várias vezes maior do que o número de janelas, o que é exigido pela prática.
Sua prática o exige.
Mas como mostra sua própria prática - esta implementação é defeituosa em termos de velocidade e conveniência.
Como mostra a prática, é mais conveniente trabalhar com uma tela e não há obstáculos para desenhar temporariamente a janela da mesa em sua tela e depois usar BitBlt na tela principal.
Não sei por que você planejou "deve haver muitas matrizes". "Mas você se vê que é um beco sem saída.
Isto é o que sua prática exige.
Mas como mostra sua própria prática - tal implementação é falha em termos de velocidade e conveniência.
Como mostra a prática, é mais conveniente trabalhar com uma tela e não há obstáculos para desenhar temporariamente a janela da mesa em sua tela e depois usar BitBlt na tela principal.
Não sei por que você planejou "deve haver muitas matrizes, além do mais - indefinidamente muitas... "Mas você se vê que é um beco sem saída.
Talvez você tenha encontrado uma solução melhor. Eu adoraria vê-lo. Se você puder, poste um gif onde você pode ver claramente a velocidade de resposta dos itens em um clique. Afixarei meu gif depois. Você vai ver do que estou falando e eu vou ver do que você está falando.
Eu não gravei o vídeo, mas estou lhe enviando um exemplo. É um esboço rápido.
Há 600 listas suspensas.
Mova o mouse - com cada evento e mudança de cor o CCanvas em geral é redesenhado. você obtém essa interatividade.
Você pode ver o tamanho final nas propriedades do bitmap - 1500x600 px (comparado ao seu atraso de 800x500 e 250ms). O que equivale a 900.000 pixels, e todos são redesenhados instantaneamente. Nenhum segundo está fora de questão.
Cada lista é apresentada primeiro em sua própria tela em seu próprio tamanho (para não transbordar) e, em seguida, arada sobre o conjunto. Portanto, temos 600 chamadas ResourceCreate por evento do mouse.
Isto significa, como você pode ver pela velocidade de reação, que os quadros são suficientes para mostrar os desenhos animados.
Os desenvolvedores de MT deram uma ferramenta satisfatória sem atrasos (quero dizer ResourceCreate bitmaps)
Eu não gravei o vídeo, mas estou lhe enviando um exemplo.
há 600 listas suspensas.
Mova o mouse - com cada evento e mudança de cor o CCanvas em geral é redesenhado.
Você pode ver o tamanho final nas propriedades do bitmap - 1500x600 px (comparado ao seu atraso de 800x500 e 250ms). O que equivale a 900.000 pixels, e todos são redesenhados instantaneamente. Nenhum segundo está fora de questão.
Cada lista é apresentada primeiro em sua própria tela em seu próprio tamanho (para não transbordar) e, em seguida, arada sobre o conjunto. Portanto, temos 600 chamadas ResourceCreate por evento do mouse.
Isto significa, como você pode ver pela velocidade de reação, que os quadros são suficientes para mostrar os desenhos animados.
Os desenvolvedores de MT deram uma ferramenta satisfatória sem atrasos (quero dizer ResourceCreate bitmaps)
Bem, isso é bom o suficiente para confirmar suas palavras... Entretanto, repito minha pergunta de ontem: a imagem está salva?
Eu disse ontem - se você armazenar uma vez criada a imagem, mudar apenas uma área específica nela, e enviar para ResourceCreate() imediatamente, não haverá atraso. Seu método de trabalho com telas ainda não me é familiar. Ainda não sei como você conseguiu este resultado.
Tenho outra pergunta: usando a classe CCanvas para criar o exemplo acima, você poderia descrever o princípio da implementação desta solução?
Talvez sejam utilizadas operações bitwise para processar a imagem. Eu ainda não lidei com eles.
P.S. Entretanto, eu mesmo gosto de resolver segredos) Vou resolver este problema de qualquer maneira.
usando a classe CCanvas para criar o exemplo acima, você pode descrever o princípio de implementação desta solução?
o princípio é linear - percorrer a lista de controles e desenhar cada um deles em uma posição requerida na tela.
Somente as funções CCanvas são utilizadas para desenhar os controles. Eu não desenhei nada de meu próprio desenho.
por exemplo, essas listas em forma colapsada são desenhadas como dois elementos - neste exemplo, botões (isto é diferente em outros estilos)
as funções de lona são chamadas
FillRectangle // preencher fundo
Rectângulo // moldura ao redor
FontSet // fonte definida
TextOut // texto de saída
É possível que as operações bitwise sejam utilizadas para processar a imagem.
não.
a imagem está salva?
sim, na matriz que está em CCanvas
se você armazenar uma imagem uma vez criada, alterar apenas uma área específica nela, e enviá-la imediatamente para ResourceCreate(), não haverá atraso.
não é bem assim.
No meu exemplo, todo o conjunto é redesenhado. A matriz é limpa e toda a tela é preenchida novamente em cada novo desenho. Então ResourceCreate é chamado.
No meu exemplo, todo o conjunto é redesenhado. A matriz é limpa e toda a tela é preenchida novamente em cada novo desenho. Então ResourceCreate é chamado.
Obrigado pela elaborada resposta.
Estranhamente, é a mesma coisa para mim. A imagem de toda a janela é totalmente recriada em cada evento de interface. Ele é construído em uma matriz unidimensional local, que é enviada para ResourceCreate após a conclusão deste procedimento.
Não sei por que isso está me atrasando... Amanhã vou postar um gif onde mostrarei a correlação entre o tamanho da janela e a velocidade de resposta do item.
Isso tudo é muito estranho...
Obrigado pela resposta detalhada.
Estranhamente, é a mesma coisa para mim. A imagem de toda a janela é totalmente recriada em cada evento de interface. Ele é construído em uma matriz unidimensional local, que é enviada para ResourceCreate após a conclusão deste procedimento.
Não sei por que isso está me atrasando... Amanhã vou postar um gif onde mostrarei a dependência entre o tamanho da janela e a velocidade de resposta do item.
Isso tudo é muito estranho...
Se não for difícil, faça uma animação gif com carga de CPU no gerenciador de tarefas. Ou é mais fácil afixar o arquivo compilado, como fezSergeev. Para que se possa testá-lo ele mesmo.
OK, vou fazer um vídeo da carga da CPU. Mas sobre o arquivo compilado - ainda não vou publicá-lo.
Apenas com muita vergonha de insetos...)))
Quando eu os consertar, prometo afixá-los.
OK, vou fazer um vídeo da carga da CPU. Mas sobre o arquivo compilado - ainda não vou publicá-lo.
Apenas com muita vergonha de insetos...)))
Quando eu os consertar - prometo postar.