DirectX - sayfa 7
Ticaret fırsatlarını kaçırıyorsunuz:
- Ücretsiz ticaret uygulamaları
- İşlem kopyalama için 8.000'den fazla sinyal
- Finansal piyasaları keşfetmek için ekonomik haberler
Kayıt
Giriş yap
Gizlilik ve Veri Koruma Politikasını ve MQL5.com Kullanım Şartlarını kabul edersiniz
Hesabınız yoksa, lütfen kaydolun
Güzel. Peki ya Si'ye bir bardak koyarsanız, değişimin açılışındaki işlemci yükü ne olacak?
Sipariş defterinde açık bir pozisyonun grafik görüntüsü var mı? Bunu standart bir bardakta gerçekten özlüyorum.
İşlemci iyi yükleniyor, önceki resimde açık bir pozisyon görebilirsiniz, fiyatın etrafındaki çerçeve macenta rengi, orada pozisyon kırmızı, aşağıdaki resimde pozisyon siyah
hepsi bir tuvalde
İşlemci iyi yükleniyor, önceki resimde açık bir pozisyon görebilirsiniz, fiyatın etrafındaki çerçeve macenta rengi, orada pozisyon kırmızı, aşağıdaki resimde pozisyon siyah
Ve yenileme hızına bir sınır koyarsanız - saniyede 10 defadan fazla değil mi? Frenler, ticaret panelinin frizlerine yol açacaktır - hayır?
Konum durumu göstergesini görüyorum - uygun görünüyor!
Ve yenileme hızına bir sınır koyarsanız - saniyede 10 defadan fazla değil mi? Frenler, ticaret panelinin frizlerine yol açacaktır - hayır?
...
Rafil'in bunu nasıl uyguladığını tam olarak bilmiyorum, ancak hücreler tuvalin tamamından ayrı olarak yeniden çizilirse, bu, yükle ilgili sorunu çözecektir.
Bunun için:
1. Her hücre, dizide kendi koordinatları ve boyutları olan, üstte metin bulunan bağımsız bir dikdörtgen etiket olmalıdır.
2. Değer değiştirme olayında önce dikdörtgeni (arka planı) sonra metin yeniden çizilir. Yeniden çizim alanı, tüm tuvalin alanından onlarca kat daha küçüktür ve bu nedenle yük yüzde onlarca düşecektir.
Rafil'in bunu nasıl uyguladığını tam olarak bilmiyorum, ancak hücreler tuvalin tamamından ayrı olarak yeniden çizilirse, bu, yükle ilgili sorunu çözecektir.
Bunun için:
1. Her hücre, dizide kendi koordinatları ve boyutları olan, üstte metin bulunan bağımsız bir dikdörtgen etiket olmalıdır.
2. Değer değiştirme olayında önce dikdörtgeni (arka planı) sonra metin yeniden çizilir. Yeniden çizim alanı, tüm tuvalin alanından onlarca kat daha küçüktür ve bu nedenle yük yüzde onlarca düşecektir.
Emir defterinin özü şu ki, fiyat hareket ettiğinde tamamen yeniden çizilmesi gerekecek, ancak görselleştirmenin sol kısmı - evet, seçenekler olabilir ama bence ayrı bir küme nesnesi (mumlar?) Çizilmiş ve sadece yeni bilgi geldiğinde yeniden çizilir.
Emir defterinin özü şu ki, fiyat hareket ettiğinde eo tamamen yeniden çizilmesi gerekecek ama görselleştirmenin sol kısmı - evet seçenekler olabilir ama bence ayrı bir küme nesnesi (mumlar?) Çizilmiş ve sadece yeni bilgi geldiğinde yeniden çizilir.
Hiç gerekli değil. Bardaktaki fiyatlar bir anda değişmez ve bazı hücreler periyodik olarak boşta kalır. Tüm tuvali yeniden çizmenin bir anlamı yok.
Aynı şey sol taraf için de geçerli. Bununla birlikte, ciddi bir yük yoktur. Yalnızca grafik kaydırmada ve geçerli çubukta. Ama çok değil.
Hiç gerekli değil. Bardaktaki fiyatlar bir anda değişmez ve bazı hücreler periyodik olarak boşta kalır. Tüm tuvali yeniden çizmenin bir anlamı yok.
İsteğe bağlı, ancak fiyat hareket ediyor, bu da hücrelerdeki değerin değiştiği anlamına geliyor - başka nasıl? Diğer bir şey ise fiyat ile dikdörtgenin koordinatlarını değiştirirseniz bu da tuval içinde çizim oluyor sanırım.
İsteğe bağlı, ancak fiyat hareket ediyor, bu da hücrelerdeki değerin değiştiği anlamına geliyor - başka nasıl? Diğer bir şey ise fiyat ile dikdörtgenin koordinatlarını değiştirirseniz bu da tuval içinde çizim oluyor sanırım.
Fiyat hareket eder, sipariş defteri merkezileştirilir ve yeniden çizilmesi gerekir. Kimse tartışmıyor. Yeniden çizim alanıyla ilgili.
Birçok hücre boştadır ve her DOM olayında değerleri değiştirmez. Örneğin, limit emirlerin hacimleri bazen sadece birkaç hücrede değişirken, diğerlerinde fiyat ve hacimler değişmeden kalır. Bu durumda, tüm tuvali yeniden çizmek, kaynak israfıdır. Hücrelerdeki değişiklikleri kontrol etmek ve yeni bir değerin gelmesi durumunda ayrı ayrı çizmek gerekir.
Bu basit yaklaşım, yükü önemli ölçüde azaltacaktır.
Ayrıca, hücrelerde değerlerin görüntülenme sıklığını azaltabilirsiniz.
Fiyat hareket eder, sipariş defteri merkezileştirilir ve yeniden çizilmesi gerekir. Kimse tartışmıyor. Yeniden çizim alanıyla ilgili.
Birçok hücre boştadır ve her DOM olayında değerleri değiştirmez. Örneğin, limit emirlerin hacimleri bazen sadece birkaç hücrede değişirken, diğerlerinde fiyat ve hacimler değişmeden kalır. Bu durumda, tüm tuvali yeniden çizmek, kaynak israfıdır. Hücrelerdeki değişiklikleri kontrol etmek ve yeni bir değerin gelmesi durumunda ayrı ayrı çizmek gerekir.
Bu basit yaklaşım, yükü önemli ölçüde azaltacaktır.
Ayrıca, hücrelerde değerlerin görüntülenme sıklığını azaltabilirsiniz.
Evet, fikrinizi anlıyorum, ancak fiyat ve hacim değişiklikleriyle ilgili bilgiler genellikle (tahmin ederim) pazarın açılışında eşzamanlı olarak gelebilir.
Kendi bardağını yapmak istediğini hatırlıyorum - bir sonuç var mı?
Evet, fikrinizi anlıyorum, ancak fiyat ve hacim değişiklikleriyle ilgili bilgiler genellikle (tahmin ederim) pazarın açılışında eşzamanlı olarak gelebilir.
Kendi bardağını yapmak istediğini hatırlıyorum - bir sonuç var mı?
Burada dün, tüm pencerenin tuvalinden bağımsız olarak hücreleri yeniden çizilen bir cam örneği yaptım: https://www.mql5.com/ru/forum/333652/page4
Hücrelerin ayrı ayrı yeniden çizilmesinin yükü %20 (video kaydı nedeniyle videoda daha fazla), hücreler TÜMÜ yeniden çizilirse EVEN ve 40 fps'de tuttuğu gösterilmiştir. Bu yaklaşımla camın olağan dinamikleri yaklaşık %5-10 oranında sevk edilecektir.
Yük, yalnızca geniş bir alanın (~ 500 * 500 piksel) yüksek bir frekansta duraklamalar olmadan (~ 40+ fps) yeniden çizilmesi durumunda yüksektir. Yeniden çizim alanındaki herhangi bir gecikme veya azalma, yükü birkaç kat azaltır.