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

Yeni yorum
 

@Nikolai Semko

Nikolai, şimdi beklenmedikbir şekilde "bir tuvaliçizmek neden bu kadar uzun sürüyor" sorusunun cevabı geldi.

Pencereler iki tuvalden oluşuyor ! Bu tuvallerin boyutları neredeyse eşit. Yani çizim alanı ikiyle çarpılmalıdır. Ama bu sadece başlangıç.

Pencere alanında büyük kaydırma elemanları (V_BOX) vardır ve bunlar da tamamen orijinal renkle dolu olarak çizilir. Yani, eğer V_BOX pencerenin ana kısmını kaplıyorsa, çizim alanı üç ile çarpılmalıdır. Ama ek bir tuvali vardır. Görüntü bu tuval üzerinde kaydırılır. Elemanın tabanı sadece bir kaydırma çubuğudur. Kısacası - çizim alanı dört ile çarpılmalıdır (özellikle kaydırma çubuğu uzunsa). Ve ancak o zaman öğeler çizilir.

Hepsi bu gibi görünüyor... Bir nokta koyabiliriz.Pencerenin alanını üç veya dört ile çarparız. Ama hayır!

Öğelerin kendileri de çok katmanlıdır. Her birinin bir tabanı vardır. Taban her zaman sıfırdan çizilir, orijinal renkle doldurulur. Daha sonra çerçeveler tabanın üzerine çizilir. Daha sonra, simgeler öğenin önceden çizilmiş kısımlarının üzerine çizilir. Ve son olarak, metinler her şeyin üzerine çizilir.

Sonuç olarak, kullanıcı her bir pikselde yalnızca son rengi görür. Ancak bu pikselin bulunduğu yerde, tüm pencere çizilirken renkler birkaç kez değişmiştir.


Şimdi bunu 15 pencere ile çarpın.... Kodda özel bir hata olmadığı anlaşılıyor - çizim bloğunun parçalarının yürütülme hızını özel olarak ölçtüm ve tam ekran için 50 ms benim için de çalışıyor. Sadece çok daha fazla ekranla karşılaşıyorum.


Kodu nasıl değiştireceğime ve çizimi 2 veya 3 kat nasıl hızlandıracağıma dair bir fikrim var. Ama bunu ana çalışmadan sonra yapacağım.

Kodu kontrol etmekte ısrar ettiğin için teşekkür ederim. Haklıydınız. Eleştirinin yardımcı olduğu durum budur.

Ayrıca, metinle ilgili ipucu için @AndreyBarinov'a teşekkürler. Belki bir şeyler bulabilirim.

Nikolai Semko - BeeXXI Corporation
Nikolai Semko - BeeXXI Corporation
  • 2024.07.15
  • www.mql5.com
Профиль трейдера
 
Реter Konow #:

@Nikolai Semko

...ve 50 ms tam ekran benim için de çalışıyor. ....

Test yaklaşıktır. Neredeyse eşit boyutta üç tuval içeren bir pencereyi (simgeler penceresi) açma hızını ölçtüm ve ~70 ms elde ettim. Tüm tuvallerin alanını toplarsanız (öğeler olmadan), o zaman dizüstü bilgisayar ekranının alanı 17". Bu, tuvalin üstüne çizilen öğelerin tabanının alanını ve simgelerin kendilerini içermez. Yani evet, varsayımsal bir tam ekranın alanını renkle doldurmak için ~50 ms. Henüz tam olarak ölçmedim. Neden, "fil" odanın tam ortasındayken? :)

 
Aşırı yüklenmiş ve optimize edilmemiş bir arayüz olarak 50 ms'den bahsediyordum. 3-10 ms normaldir

Yine de biraz profilleme yapın. Kodunuzda pek çok keşif yapacaksınız.
 
Nikolai Semko #:
Aşırı yüklenmiş ve optimize edilmemiş bir arayüz olarak 50 ms'den bahsediyordum. 3-10 ms normaldir

Yine de biraz profilleme yapın. Kodunuzda pek çok keşif yapacaksınız.
Nikolai, bunlar sadece rakamlar. Ayrıntılara ihtiyacın var. En azından ekran boyutu. O zaman doğru hesaplamalar yapabilirsiniz.
 
Tuval üzerine çizim bir dizi başlatma işlemidir. Maksimum hızı bulmak kolaydır - dizi doldurma döngüsüne sahip işlev bunu ortaya çıkaracaktır. Dizi boyutu, koşullu ekranın piksellerinin toplamına karşılık gelmelidir.
 
Patates tarlasına gitmek istemeyen Stirlitz gibisin.
Profilini çıkar.
 
Nikolai Semko #:
Patates tarlasına gitmek istemeyen Stirlitz gibisin.
Profilini çıkar.
Yaptım. Sana bir gif gönderirim.
 


Çizim bloğu içindeki döngüleri derinlemesine incelemeniz gerekir. Yüzeysel profilleme tam bir resim vermez. Ancak konunun ne olduğu zaten açık. Burada yazdım

. Sanırım yanılmıyorum.

(çizim bloğunun taslak versiyonu, testler için kullanıyorum)
 
Реter Konow #:

...

Kodu nasıl değiştireceğime ve render işlemini 2 veya 3 kat nasıl hızlandıracağıma dair bir fikrim var. Ama bunu ana çalışmadan sonra yapacağım. ...

Görevin karmaşıklığını ve nihai sonucun değerini analiz ettim.

Sonuç: Bunu yapmanın bir anlamı yok.

İlk çizimi hızlandırmanın bir anlamı yoktur. Karmaşık grafiklere ve kaydırma çubuklarına sahip 15 pencere oluşturmak için bir buçuk saniye normal bir sonuçtur. İlk çizim, pencereleri açmadan önce gerçekleştirilerek kullanıcının gözünden gizlenebilir. Görsel olarak, pencereler yarım saniyelik bir duraklamadan sonra anında görünecektir. Tabii ki 15 pencerenin aynı anda açılmasını istiyorsa, ki bu pek olası değildir.

Pencerenin arka tarafını çizmek zorunda değilsiniz. Yaklaşık 20 ms'lik bir kazanç olacaktır. Bu kulağa etkileyici gelmiyor.

Geçen hafta en önemli şey başarıldı: ilk derleme hariç tüm etkinliklerde kayıtlı görüntüleri kullanmak. Bu, arayüz hızında büyük bir kazançtır.

Geri kalan gecikmeler, odak değiştirirken pencerelerin yeniden çizilmesi veya gereksiz çağrılarla ilgilidir. Kolay düzeltmeler. Bu büyük kazanımın yükleme süresi yüzünden göz ardı edilmesini istemiyorum, ki bu o kadar da önemli değil. Ancak, ben kendi ilgi odağımı değiştirdim. Sizde de olmalı.

Burada, mevcut gelişmeyle ilgisizliği ve alakasızlığı nedeniyle ilk renderın hızı konusunu kapatıyorum.

Bir sonraki güncelleme Pazar günü. Kullanıcı programı ile kavramsal olarak eksiksiz bir yazılım etkileşimi mekanizmasına sahip bir motor sunacağım.
 
Реter Konow #:
Görevin karmaşıklığını ve nihai sonucun değerini analiz ettim.

Sonuç, bunun hiçbir anlam ifade etmediğiydi.

Bir buçuk saniyede karmaşık grafiklere ve kaydırma çubuklarına sahip 15 pencere oluşturmak normal bir sonuçtur. Pencereyi açmadan önce ilk grafiği çizmek mümkündür, böylece kullanıcı tarafından görülmez. Görsel olarak, pencere yarım saniyelik bir duraklamadan hemen sonra görünecektir. Elbette, kullanıcı aynı anda 15 pencerenin açık olmasını istiyorsa, bu pek olası değildir.

Pencerenin arkasını çizmek zorunda değilsiniz. Yaklaşık 20 ms'lik bir kazanç olacaktır. Kulağa şaşırtıcı gelmiyor.

Geçen hafta ana hedefimize ulaştık: ilk derleme hariç tüm etkinlikler için kayıtlı görüntüleri kullanmak. Bu, arayüz için büyük bir hızlandırma.

Gecikmelerin geri kalanı, odak değiştirirken pencerenin yeniden çizilmesi veya gereksiz çağrılarla ilgiliydi. Bunu düzeltmek kolay. Çok da önemli olmayan yükleme süreleri nedeniyle bu büyük gelişmeyi görmezden gelmek istemiyorum. Ancak, odak noktamı değiştirdim. Şunlara sahip olmalısınız

Burada, ilk render hızı sorununu sonlandırdım çünkü mevcut geliştirme ile ilgili veya önemli değil.

Bir sonraki güncelleme Pazar günü. Yazılım ve kullanıcı programı arasında kavramsal olarak eksiksiz bir etkileşim mekanizmasına sahip bir motor sunacağım.

Evet, öncelikle tamamen işlevsel bir yazılım çıkarmak çok önemlidir.

1...5051525354555657585960616263
Yeni yorum