DirectX - página 8

 
Реter Konow:

Ontem fiz um exemplo de um tumbler com células redesenhadas independentemente de toda a tela da janela:https://www.mql5.com/ru/forum/333652/page4

Mostra, que o redesenho separado das células mantém a carga no limite de 20% (em vídeo mais por causa da gravação em vídeo), SEMPRE se as células forem redesenhadas TODO o tempo e a 40 fps. A dinâmica normal do secador com esta abordagem irá carregar 5-10% aproximadamente.

A carga é alta somente se for redesenhada uma grande área (~500*500 px) a alta taxa sem pausas (~40+ fps). Qualquer atraso ou redução na área de redesenho irá reduzir a carga muitas vezes.

Em seu exemplo, o vidro é bastante truncado, naturalmente, também em profundidade. É engraçado, mas aparentemente a renderização de uma pilha tem que ser feita em todos os núcleos com OpenCL, além disso, já que o cálculo é dividido em células separadas, mas aqui eu sou um teórico.

 
Aleksey Vyazmikin:

Em seu exemplo, o copo é bastante truncado, incluindo a profundidade. É engraçado, mas aparentemente o desenho do copo deve ser calculado em todos os núcleos com OpenCL, além disso, já que o cálculo é dividido em células separadas, mas aqui estou eu como teórico.

Ok, vou fazer um copo com mais células e verificar novamente.

 
Реter Konow:

OK, vou fazer um copo com mais células e verificar novamente.

Apenas não o faça estático, faça-o dinâmico.

 
Rafil Nurmukhametov:

O processador carrega bem, na figura anterior você pode ver uma posição aberta, a moldura ao redor do preço é de cor magenta, ali a posição é deficitária, na figura abaixo a posição é em excesso

Meu sentimento é que tal imagem não deve ser formada mais de 1-3 milissegundos. Se demorar mais do que isso, deve haver um bug em algum lugar.
 
Rafil Nurmukhametov:

Apenas não o faça estático, faça-o dinâmico.

O que você quer dizer com "dinâmico"? Para que nem todas as células mudem os valores ao mesmo tempo? Eu não entendo.

 
Nikolai Semko:
Meu sentimento é que tal imagem não deve formar mais de 1-3 milissegundos. Se demorar mais do que isso, há algo errado em algum lugar.

Agora você levantou a fasquia da perfeição... Por que você não baixa para 6-8 milissegundos?

 
Реter Konow:

O que você quer dizer com "dinâmico"? Para que nem todas as células mudem os valores ao mesmo tempo? Eu não entendo.

Para que o preço atual se mova através das células e não no meio, como no mt5

 
Rafil Nurmukhametov:

para fazer o preço atual mover-se através das células, não no meio como no copo mt5

Ou seja, sem centralização. Bem, para os instrumentos futuros, isto é o que você realmente precisa. Ok. (Esta é apenas uma maquete para testar a carga).

 
Rafil Nurmukhametov:

Agora você levantou a fasquia da perfeição... Você pode baixá-lo para 6-8 milissegundos?

é demais. Mesmo 3 é demais. 6-8 a 30 fps é 20-30% do tempo da CPU.
Você precisa usar o ArrayCopy o máximo possível, sempre que possível. A transparência também deve ser usada ao mínimo apenas onde for necessário.
Você pode fazer o perfil e ver onde a CPU vaza ao máximo.
Peter está certo, é claro, você deve redesenhar localmente onde houve mudanças, mas não redesenhar toda a tela toda vez.
E usar o DX em geral pode aliviar muito sua CPU
 

OK, fez o vidro no editor. Demorei duas horas. Isso é muito barulho. Você pode acelerar o processo por um fator de quatro, adicionando ferramentas.

Testado.

O resultado: menos de 20% da carga, com mudança constante em todas as células de pedido e lance, e um preço de célula, a 40 quadros por segundo. (A carga aumenta em 5-7 por cento quando a gravação é habilitada).


Repito minha opinião - em condições reais, a carga seria de 5 a 10%, dependendo da atividade do mercado.

Arquivos anexados:
GUI_Expert.ex5  600 kb