MQL ile yazılmış kullanıcı arayüzleri galerisi - sayfa 55

 
Bence arka tarafın görünmeyen kısmını çizmezseniz, pencerenin ilk çizimini en az üçte bir oranında hızlandırabilirsiniz. Henüz kesin bir şey söyleyemem, kontrol etmeniz gerekir. Sadece çerçeveyi ve şapkayı çizmesine izin verin . Gerisini atlayın. Her durumda bir kazanç olacaktır.
 
Andrey Barinov #:

Ayrıca tam ekran tuvali her değiştirdiğimde tamamen yeniden çiziliyor, ancak bu 50 ms'den uzun sürmüyor ...

En pahalı olanı metin çizmektir. Bu nedenle, her seferinde TextOut kullanmamak için bunları dizilerde saklıyorum. Çok daha hızlı oluyor.

Evet, TextOut kullanılıyor. Bununla ne yapılabileceğini düşüneceğim.

 
Genel olarak, bir sonraki sürümde çizim bloğunu yeniden düzenleyeceğim ve hızı artıracağım. Ama en önemlisi, motoru bitireceğim.
 
Реter Konow #:

Basit aritmetik burada işe yarıyor: 10 - 17 pencerenin alanlarının toplamı tam ekrandan çok daha büyük. Katılıyorum. Artı gölgeler, simgeler, çerçeveler oluşturmak için gerekli ikincil ek çizimler....

Ve TextOut hakkında kontrol edip yazacağım. İlginç bir fikir.

Basit aritmetiğinizi anlamıyorum :). Benim aritmetiğimde kullanıcı tarafından görülmeyen pikselleri çizmeye gerek yoktur ve çizim için tuvalin maksimum boyutu piksel cinsinden ekran boyutuyla sınırlıdır.

Kaç pencere olursa olsun, hepsini tek bir bit eşlemde katmanlar halinde çiziyorum. Yüz kadar pencere olabilir. Basit ilkeller çok az bir sürede çizilir. En uzunu yukarıda yazdığım gibi metinlerdir. Ancak ilk kullanımda TextOut yardımıyla ve daha sonra zaten hazır dizilerden.

 

Gelecekteki çalışmalar için bir planın onaylanması gerekiyor.

Her hafta bir güncelleme yayınlayacağım. Cumartesi ya da Pazar.

1. Bir sonraki sürümde motorun tam sürümünü yayınlayacağım. Hataları düzelteceğim ve render işlemini hızlandıracağım.

2. İkinci sürüm tablolara adanacak. Temel özellikleri geri yükleyeceğim.

3. Üçüncü sürüm - Dinamik tablolar yapacağım. Bunları bir hafta içinde uygulamayı umuyorum. Deneyeceğim.

4. Dördüncü sürüm - dinamik pencere. Bitmiş sürümü yayınlamaya çalışacağım.


Bu aşamada, oluşturucu, motor ve biçimlendirme dilinin temel sürümleri tamamlanmış sayılabilir.

Kesinlikle KIB koduyla yazılmış bir şablon dalı açacağım ve burada bitmiş pencereleri ve öğe gruplarını yayınlayacağım. Arayüzü oluşturmak isteyenlerin işini kolaylaştırmak için resimlerle birlikte.

Ve insanların tüm olasılıkları kullanabilmeleri için öğretici makaleler yazmaya çalışacağım.


Bu başlıkta elimden geldiğince kod, resim ve açıklayıcı materyal yayınlamaya devam edeceğim. Yukarıda belirtilen işleri yapmakla çok meşgul olacağım.

 
Perth yok, hala çok fazla. Tüm metin, gölgeler vb. ile arayüzünüz zayıf bir işlemcide 50 ms'de maksimuma ulaşır.
Bir hata arayın.
Profillemeyi çalıştırın. Zamanın %95'ini hangi fonksiyonların kullandığını görün.
Belki ChartGet veya XY işlevlerini kullanıyorsunuzdur (bir grafiğe bağlantınız olmamasına rağmen).
Her neyse, profillemeyi çalıştırın. Sadece 40 saniye sürecektir.
 
KIB kodunda yazılmışşablon dalları
Oluşturucu kodu ile karıştırılmamalıdır. Ayrı bir proje olarak yayınlanmalıdır.
 
Andrey Barinov #:

Basit aritmetiğinizi anlamıyorum :). Benim aritmetiğimde, kullanıcı tarafından görülemeyen pikselleri render etmeye gerek yoktur ve render için maksimum tuval boyutu piksel cinsinden ekran boyutuyla sınırlıdır.

Kaç pencere olursa olsun, hepsini tek bir bit eşlemde katmanlar halinde çiziyorum. Yüz kadar pencere olabilir. Basit ilkeller çok az bir sürede çiziliyor. En uzunu yukarıda yazdığım gibi metinlerdir. Ancak ilk kullanımda TextOut yardımıyla ve daha sonra zaten hazır dizilerden.

Tek bir büyük tuval ile çalışmanın pek çok sınırlaması var. Bu seçenek hakkında zaten düşündüm ve hatta Nikolay ile tartıştım.

Açıklayayım: bunu yapıyorsunuz çünkü standart Ccanvas sınıfını kullan ıyorsunuz. Çerçevesinde çalıştığınız hazır çözümler var. Ama ben Ccanvas sınıfını kullanmıyorum. Tüm render kodları kişisel gelişimdir. Bu yüzden HER ŞEY için bir tuval konseptine sadık kalmıyorum. Bence bu, grafiksel bir ortamda teknik olarak uygunsuz ve verimsiz bir çözüm. Bitmap nesne kümeleri kullanmak ve bunlara hazır kaynaklar eklemek, tek bir bitmap'e sahip olmaktan ve üzerindeki görüntülerin etkileşimini programlı olarak oluşturmaktan daha kolaydır. Bunu hayal etmek bile zor. Ancak asıl mesele bu değil.

Sadece TEK bir tuvaliniz varsa, çok pencereli GUI kavramını gerçekleştirmenin ne kadar zor olduğunu bir düşünün. Ben olsam böyle bir görevi üstlenmezdim.

Ancak bu bile belirleyici değil. Tüm görüntüler için tek bir tuval fikrini reddetmenin ana nedeni: yalnızca bir tuval olduğunda, arayüz pencerelerini taşımak MQL ortamında yeniden çizim gerektirir. Buna karşılık, her pencere kendi bitmap nesnesini kaplarsa ve ObjectSetInteger() işlevi tarafından taşınırsa, - taşınan nesnelerin yeniden çizilmesi MQL ortamının dışında çalışan standart işlevlere düşer. Bu nedenle çok daha hızlıdır.

Sadece diğer çözümlerin daha etkili çalıştığı farklı bir geliştirme yönünüz var.


TextOut ile ilgili ipucu için çok teşekkür ederim. Bu noktayı araştıracağım.

 
hini #:
Şablon dallarıKIB kodu ile yazılmıştır.
Oluşturucu kodu ile karıştırılmamalıdır. Ayrı bir proje olarak yayınlanmalıdır.

Evet, hata ayıklama için kullanıcı programının motorla bağlantısını kesmeyi uygulayacağım, eğer kastettiğiniz buysa. Muhtemelen yanlış anlaşıldı.

 
Реter Konow #:

Tek bir büyük tuvalle çalışmanın pek çok sınırlaması var. Böyle bir seçeneği zaten düşündüm ve hatta Nikolay ile tartıştım.

Açıklayayım: Standart Ccanvas sınıfını kullandığınız için bunu yapıyorsunuz. Çalıştığınız çerçevede hazır çözümler var. Ama ben Ccanvas sınıfını kullanmıyorum. Tüm render kodları kişisel gelişim ile yazılıyor. Bu yüzden HER ŞEY için tek bir canvas konseptine bağlı kalmıyorum. Bence bu, grafiksel bir ortamda teknik olarak uygunsuz ve verimsiz bir çözüm. Bitmap nesne kümeleri kullanmak ve bunlara hazır kaynaklar eklemek, tek bir bitmap'e sahip olmaktan ve üzerindeki görüntülerin etkileşimini programlı olarak oluşturmaktan daha kolaydır. Bunu hayal etmek bile zor. Ancak asıl önemli olan bu değildir.

Sadece TEK bir tuvaliniz varsa, çok pencereli bir GUI konseptini gerçekleştirmenin ne kadar zor olduğunu hayal edin. Ben olsam böyle bir görevi üstlenmezdim.

Ancak bu bile belirleyici değildir. Tüm görüntüler için tek bir tuval fikrini reddetmenin ana nedeni: yalnızca bir tuval olduğunda, arayüz pencerelerini taşımak MQL ortamında yeniden çizim gerektirir. Buna karşılık, her pencere kendi bitmap nesnesini kaplarsa ve ObjectSetInteger() ile taşınırsa, - taşıma sırasında yeniden çizim MQL ortamının dışında çalışan standart işlevlere düşer. Bu nedenle çok daha hızlıdır.

Sadece diğer çözümlerin daha verimli çalıştığı biraz farklı bir geliştirme yönünüz var.


TextOut ile ilgili ipucu için çok teşekkür ederim. Bu noktayı araştıracağım.

Ben sadece standart kanvas kullanmıyorum:).

Ve tek bir bitmap üzerinde çok pencereli bir arayüz uygulamayı daha kolay buldum. Ama herkesin kendi tercihi!


Ve pratikte tüm kanvası yeniden çizmek ObjectSetInteger kullanmaktan daha hızlı gibi görünüyor, vb....