Tuval ve Etiketler - sayfa 7

Yeni yorum
 
Mihail Matkovskij :

Bu konuda daha fazla okuyabileceğim bir yer var mı? Her şeyi anlamama rağmen, konu yine de oldukça ilginç! Şimdi, bitmap güncellemeleri üzerinde kontrole sahip bir varyant yapmak ve test etmek için kalır. Bitmap etiketlerden daha hızlıysa şaşırırım.

Az sayıda Etiketle, BitMap MQL5'te değil, C ++ ile doldurulduğundan, kullanımlarının tuvale göre hız avantajları olduğunu tamamen kabul ediyorum. Hayır, pek olası olmasa da, metnin oluşumu tuvalde aynı şekilde gerçekleşmelidir, çünkü metin BitMap'in oluşumu her iki durumda da kazanma işlevleri tarafından gerçekleştirilir. Bence Label durumunda, bu nesneler hala olay özellikleriyle kaplıdır (fare ile sürüklenebilirler) ve bu sonuçta tasarımlarını daha ağır hale getirir.

 

Canvas'ın hızı bir sorudur.


CPU'ya entegre video kartı.


Bu kodu çalıştırıyorum.

 #include <fxsaber\Usage\Usage.mqh> // https://www.mql5.com/ru/code/33875

void OnInit ()
{  
  USAGE::MinInterval = 100 * 1000 ; // 100 ms.
  
   EventSetMillisecondTimer (( int )USAGE::MinInterval / 1000 );  
}

void OnTimer ()
{
  _USAGE // Расчет нагрузки.

  USAGE::GraphCreate( 1200 , 900 , 200 ); // Вывели график нагрузки.
}

void OnDeinit ( const int )
{
  USAGE::GraphDelete(); // Удалили график нагрузки.
}

Kısacası, OnTimer'ın her 100ms'de ne kadar süre çalıştığını ölçer. Aynı zamanda OnTimer içinde bir ölçüm programı oluşturur. Böyle bir sonuç çıkıyor.

%15-20 yiyor. Görünüşe göre, fren ekran kartı. Ama soru farklı. Fiyat grafiğini fare ile sürüklemeye başlarsam (LMB'yi tutarken sola-sağa hareket ettirin), yük iki katına çıkar. Bunu yukarıdaki animasyonda açıkça görebilirsiniz. Bu özelliğin nedeni nedir?


Bir kez daha tekrarlıyorum. Fiyat grafiğini fare ile hareket ettirirseniz OnTimer iki kat daha uzun çalışır.

 
fxsaber :

Canvas'ın hızı bir sorudur.


CPU'ya entegre video kartı.


Bu kodu çalıştırıyorum.

Kısacası, OnTimer'ın her 100ms'de ne kadar süre çalıştığını ölçer. Aynı zamanda OnTimer içinde bir ölçüm programı oluşturur. Böyle bir sonuç çıkıyor.

%15-20 yiyor. Görünüşe göre, fren ekran kartı. Ama soru farklı. Fiyat grafiğini fare ile sürüklemeye başlarsam (LMB'yi tutarken sola-sağa hareket ettirin), yük iki katına çıkar. Bunu yukarıdaki animasyonda açıkça görebilirsiniz. Bu özelliğin nedeni nedir?


Bir kez daha tekrarlıyorum. Fiyat grafiğini fare ile hareket ettirirseniz OnTimer iki kat daha uzun çalışır.

Büyük olasılıkla, kitaplıklarınız gerekirse tuval boyutunu değiştirmek için (grafik boyutu değiştiyse) CHARTEVENT_CHART_CHANGE kontrolüne sahiptir, ancak bunu öğrenmek için çok yavaş (hala) eşzamansız ChartGet işlevlerini çalıştırmanız gerekir..
Bu frenlere yol açar.
MQ'nun CHARTEVENT_CHART_CHANGE olayını ayırması ve bunu ayrı olarak, örneğin CHARTEVENT_CHART_SIZE_CHANGE yapması daha mantıklı olacaktır. CHARTEVENT_CHART_CHANGE olayına çok fazla şey dolduruluyor: yeni bir çubuğun gelmesi, kaydırma çubukları, fiyat skalasının dikey olarak değiştirilmesi, pencere boyutunun değiştirilmesi.

 
Nikolai Semko :
Az sayıda Etiketle, BitMap MQL5'te değil, C ++ ile doldurulduğundan, kullanımlarının tuvale göre hız avantajları olduğunu tamamen kabul ediyorum. Hayır, pek olası olmasa da, metnin oluşumu tuvalde aynı şekilde gerçekleşmelidir, çünkü metin BitMap'in oluşumu her iki durumda da kazanma işlevleri tarafından gerçekleştirilir. Bence Label durumunda, bu nesneler hala olay özellikleriyle kaplıdır (fare ile sürüklenebilirler) ve bu sonuçta tasarımlarını daha ağır hale getirir.

Gerçekten de, etiketler daha hızlı olabilir. Grafikte kaç tane olduğuna bağlı olarak... Güncellemelerin kontrolünü yaptım ve gerçekten sonuçlara şaşırdım. Sınırlama, yanılmıyorsam 24 fps, göze hoş gelen minimum kare hızından alındı. Yaklaşık 41 milisaniye çıktı. Canvas için bir sınır belirledim ve bakın, şaşırdım. Amansız etiket yenilemeye kıyasla uçup gidiyor! Ama aynı limiti Etiket gösterimi için belirlediğimde, Kanvas tabanlı gösterimden bile daha hızlıydı. Ama kendimin önüne geçmeyeceğim, tüm test sonuçlarını daha sonra sunacağım.

 
fxsaber :

Fiyat grafiğini fare ile sürüklemeye başlarsam (LMB'yi tutarken sola-sağa hareket ettirin), yük iki katına çıkar. Bunu yukarıdaki animasyonda açıkça görebilirsiniz. Bu özelliğin nedeni nedir?

Windows olay modeli ile - fareyi hızlı bir şekilde hareket ettirseniz bile, odakta hangi uygulama olursa olsun işlemci üzerindeki yük artmaya başlar

Not: Win10 görev yöneticisinde kontrol ettim ... nedense işlemci üzerindeki yükte bir artış göstermiyor, Win7'de tam olarak aynı P'de fareleri hızlı hareket ettirirseniz yük arttı - Win10'un olduğundan şüpheliyim olay modelini büyük ölçüde değiştirdi, büyük olasılıkla görev yöneticisi farklı çalışıyor

 
Nikolai Semko :

Büyük olasılıkla, kitaplıklarınız gerekirse tuval boyutunu değiştirmek için (grafik boyutu değiştiyse) CHARTEVENT_CHART_CHANGE kontrolüne sahiptir, ancak bunu öğrenmek için çok yavaş (hala) eşzamansız ChartGet işlevlerini çalıştırmanız gerekir..
Bu frenlere yol açar.
MQ'nun CHARTEVENT_CHART_CHANGE olayını ayırması ve bunu ayrı olarak, örneğin CHARTEVENT_CHART_SIZE_CHANGE yapması daha mantıklı olacaktır. CHARTEVENT_CHART_CHANGE olayına çok fazla şey dolduruluyor: yeni bir çubuğun gelmesi, kaydırma çubukları, fiyat skalasının dikey olarak değiştirilmesi, pencere boyutunun değiştirilmesi.

Bunların hiçbiri yukarıdaki kodda yok.

 
Igor Makanu :

Windows olay modeli ile - fareyi hızlı bir şekilde hareket ettirseniz bile, odakta hangi uygulama olursa olsun işlemci üzerindeki yük artmaya başlar

Not: Win10 görev yöneticisinde kontrol ettim ... nedense işlemci üzerindeki yükte bir artış göstermiyor, Win7'de tam olarak aynı P'de fareleri hızlı hareket ettirirseniz yük arttı - Win10'un olduğundan şüpheliyim olay modelini büyük ölçüde değiştirdi, büyük olasılıkla görev yöneticisi farklı çalışıyor

Teşekkürler, bilmiyordum. Farenin MQL programını iki kez yavaşlatabilmesine şaşırdım.

ZY Böyle bir sonuç sadece bende mi?
fxsaber :

%15-20 yiyor. Görünüşe göre, fren ekran kartı.

 
fxsaber :

Teşekkürler, bilmiyordum. Farenin MQL programını iki kez yavaşlatabilmesine şaşırdım.

O zaman keneler ve diğer şeyler ile gecikmelerin ortaya çıkması doğaldır. Mayın tarlası gibi bir olay modeliyle HFT.

 
fxsaber :

Bunların hiçbiri yukarıdaki kodda yok.

Evet, bunun dahili bir grafik olduğunu görmedim.
Profil oluşturmaya bakılırsa, grafik kayarken frenlerin kaynağı şu satırda:

Aktif kaydırma ile profil oluşturma:

Kaydırmadan etkin fare hareketiyle profil oluşturma (LMB'ye basılmadan):

Not: Bu nedenle, frenlerin kaynağı hala tuval değil, nesnelerdir.

 
Mihail Matkovskij :

Ayrıca tabloyu da kontrol edebilirsiniz. Ancak, bunu test cihazında yapmanın daha kolay olacağını düşündüm.

Bu yanlış bir yaklaşımdır. Ayrıca, görsel test cihazı, test sürecini tamamen yavaşlatmamak için farklı bir ertelenmiş oluşturma modeline sahiptir.

Görünen o ki, dediğiniz gibi, etiketlerde metin oluşturmak, OBJ_BITMAP_LABEL oluşturmaktan daha fazla zaman alıyor.

Öyle demedim.

Bariz hataları işaret ettim ve işleme sisteminin nasıl çalıştığını açıkladım.

1234567891011121314...18
Yeni yorum