Canvas üzerinde bir kitle kaynaklı proje yapma - sayfa 18
Alım-satım fırsatlarını kaçırıyorsunuz:
- Ücretsiz alım-satım 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
Ne yazık ki, günümüzün bir diziyi "dijital maske" ile kaydederek görüntü güncelleme gecikmesi sorunuyla başa çıkma girişimleri başarıya yol açmadı. Ancak buna başarısızlık da denilemez. Frenlemenin nedeni hakkında nihai bir sonuca varmak ve bu soruna küresel bir çözüm bulmak mümkün değildi.
Bitmiş görüntüyü bellekte saklamanın ve bölgeleriyle çalışmanın genel yöntemlerini düşünerek farklı seçeneklerden geçtim. Derin düşüncelerle iyi bir çözüm olarak gördüklerimin pratik olmadığı ortaya çıktı.
İşte benim sonuçlarım:
1. Görüntüleri diziler halinde kaydederseniz, çok sayıda dizi olmalıdır. Ve, - sınırsızca... Yani, her kaynak kendi kalıcı bellek dizisini gerektirir. Arayüz uygulamamda, tuval sayısı (kaynaklar, tuvaller) pencere sayısından birkaç kat daha fazla olabilir. Pratik gerektirir.
Nedenini açıklayayım:
Bazı durumlarda, bu yaklaşım, tüm pencere nesnelerini aynı tuval üzerine çizmekten çok daha uygundur. Örneğin - "görüş alanı (VEIW BOX)" öğesindeki bir tabloyu kaydırırken, tablo öğelerini bu öğenin içinde ayrı bir tuval üzerine yerleştirmek ve bu tuvali bütün bir nesne olarak kaydırmak uygundur. Kaydırma hızı daha yüksektir. Bu, bu tür her bir öğenin ayrı bir tuval taşıdığı anlamına gelir. Aksi takdirde, bellekte depolanan tüm pencere görüntüsünün üzerine yazmanız gerekir. Kesinlikle daha uzun sürecek.
Ayrıca, tüm pencereleri tek bir tuval üzerine çizmek tamamen elverişsizdir - o zaman nasıl hareket ettirilir? Grafiğin tüm alanı için bir "mega" tuval oluşturduğumuzu hayal edin. Bütün pencerelerimiz üzerine çizilecek. Pencereleri tuval üzerine çizdikten sonra, onları hareket ettirmeye çalışacağız, ancak bu, bu ortak "mega" tuvalin tüm resmini yeniden yazmak zorunda kalacak. Resim çok büyük ve üzerine yazılan değerlerin sayısı çok büyük olacak. Resim kaydedilse bile, her imleç ofsetinde bellekte büyük bir alanı yeniden yazmanız gerekecektir. Açıkçası bu verimsiz.
2. Görüntüleri kaydetme ve onlarla çalışma yöntemini düşünürken "ResourceReadImage ()" işlevini hatırladım. Bu işlev bir kaynağı okur ve dijital maskesini bir diziye koyar. Bu, görüntüyü kaydetmeye gerek olmadığı anlamına gelir, çünkü zaten terminal düzeyinde kaydedilmiştir ve bu fonksiyon kullanılarak talep edilebilir. Bu, görevi büyük ölçüde basitleştirir. Ve böylece: "ResourceReadImage()" kullanarak bir görüntü talep edebilir, onu bir diziye alabilir ve ardından arayüzün "olay altında" olan belirli bir öğeyle ilgili dizi değerlerini değiştirebilirsiniz. Bu yaklaşım bence daha çekici görünüyor. Ancak soru şu: "ResourceReadImage()" işlevini kullanarak diziyi bir görüntüyle doldurmak ne kadar sürer? Açıkçası, bu aynı zamanda tuvalin alanına da bağlıdır. Görsel olarak hiç fark edilmeyebilir, ancak her durumda, imleç belirli bir tuvalin alanı üzerindeyken yalnızca bir kez yüklemeniz gerekir. Başka bir tuvale geçerken diziyi temizleyebilir ve başka bir tuvalin görüntüsünü yükleyebilirsiniz.
Sonuç olarak, nihai bir kararım yok. "ResourceReadImage()" işlevini denememiz, görüntü yükleme süresini ölçmemiz ve bir dizideki görüntü bölgeleriyle çalışmak için bir sistem geliştirmemiz gerekiyor.
Hepsi bugün için.Реter Konow :
Arayüz uygulamamda, tuval sayısı (kaynaklar, tuvaller) pencere sayısından birkaç kat daha fazla olabilir. Pratik gerektirir.
pratiğiniz bunu gerektiriyor.
ancak kendi uygulamanızın gösterdiği gibi - böyle bir uygulama hız ve rahatlık açısından kusurludur.
Ve uygulamanın gösterdiği gibi, ama zaten benim, işin rahatlığı tam olarak bir tuval üzerinde elde edilir ve ana tuvali oluştururken kendi tuvalinize geçici olarak bir tablo penceresi çizmek ve ardından ana tuval üzerinde BitBlt yapmak için hiçbir engel yoktur.
Neden “bir sürü dizi olmalı. Üstelik sonsuz sayıda ...” planladığınızı bilmiyorum - ama bunun bir çıkmaz sokak olduğunu kendiniz görüyorsunuz.
pratiğiniz bunu gerektiriyor.
ancak kendi uygulamanızın gösterdiği gibi - böyle bir uygulama hız ve rahatlık açısından kusurludur.
Ve uygulamanın gösterdiği gibi, ama zaten benim, işin rahatlığı tam olarak bir tuval üzerinde elde edilir ve ana tuvali oluştururken kendi tuvalinize geçici olarak bir tablo penceresi çizmek ve ardından ana tuval üzerinde BitBlt yapmak için hiçbir engel yoktur.
Neden “bir sürü dizi olmalı. Üstelik sonsuz sayıda ...” planladığınızı bilmiyorum - ama bunun bir çıkmaz sokak olduğunu kendiniz görüyorsunuz.
Belki de daha iyi bir çözüm buldunuz. seve seve bakarım Yapabiliyorsanız, öğelerin tıklamaya tepki hızını açıkça görebileceğiniz bir gif gönderin. GIF'imi daha sonra ekleyeceğim. Ne hakkında konuştuğumu göreceksin ve ne hakkında konuştuğunu göreceğim.
Video kaydetmedim ama bir örnek yüklüyorum. hızlı bir şekilde çizilir.
600 açılır liste var.
fareyi hareket ettirin - her olay ve renk değişikliği ile genel CCanvas yeniden çizilir. bu etkileşimi elde edin.
Son boyutu bitmap özelliklerinde görebilirsiniz - 1500x600 piksel (800x500 ve 250ms gecikmenizle karşılaştırma için). Bu 900.000 puana eşittir ve her şey anında yeniden çizilir. Herhangi bir saniyeden söz edilemez.
Her liste önce kendi tuvaline kendi boyutunda çizilir (sınırların dışına çıkmamak için) ve sonra sadece genel listeye geçer. Yani her fare olayı için 600 ResourceCreate çağrımız var.
Bu, tepki hızından da görebileceğiniz gibi, gösterilecek yeterli çerçeve ve çizgi film olduğu anlamına gelir.
MT geliştiricileri, frensiz tatmin edici bir araç verdi (ResourceCreate bitmap'lerinden bahsediyorum)
Video kaydetmedim ama bir örnek yüklüyorum. hızlı bir şekilde çizilir.
600 açılır liste var.
fareyi hareket ettirin - her olay ve renk değişikliği ile genel CCanvas yeniden çizilir. bu etkileşimi elde edin.
Son boyutu bitmap özelliklerinde görebilirsiniz - 1500x600 piksel (800x500 ve 250ms gecikmenizle karşılaştırma için). Bu 900.000 puana eşittir ve her şey anında yeniden çizilir. Herhangi bir saniyeden söz edilemez.
Her liste önce kendi tuvaline kendi boyutunda çizilir (sınırların dışına çıkmamak için) ve sonra sadece genel listeye geçer. Yani her fare olayı için 600 ResourceCreate çağrımız var.
Bu, tepki hızından da görebileceğiniz gibi, gösterilecek yeterli çerçeve ve çizgi film olduğu anlamına gelir.
MT geliştiricileri, frensiz tatmin edici bir araç verdi (ResourceCreate bitmap'lerinden bahsediyorum)
Pekala, bu söylediklerinizi doğrulamak için oldukça yeterli... Ancak dünkü sorumu tekrar edeceğim: görüntü kaydedildi mi?
Dün söyledim - bir görüntüyü oluşturduktan sonra saklarsanız, içindeki yalnızca belirli bir alanı değiştirin ve hemen ResourceCreate'e () gönderin, o zaman gecikme olmaz. Tuvalle çalışma yönteminiz bana henüz tanıdık gelmedi. Bu sonuca tam olarak nasıl ulaştığınızı hala bilmiyorum.
Başka bir sorum var: Yukarıdaki örneği oluşturmak için CCanvas sınıfını kullanarak bu çözümü uygulama ilkesini açıklayabilir misiniz?
Belki orada görüntü işleme için bitsel işlemler kullanılıyor. Henüz onlarla uğraşmadım.
Not Ancak sırları kendim çözmeyi severim...) Yine de bu sorunu çözeceğim.
Yukarıdaki örneği oluşturmak için CCanvas sınıfını kullanarak, bu çözümün nasıl uygulandığını açıklayabilir misiniz?
doğrusal ilke - kontroller listesini gözden geçirir ve her birini tuval üzerinde doğru yere çizeriz.
kontrolleri çizmek için yalnızca CCanvas işlevleri kullanılır. Kendi başıma hiçbir şey yapmadım.
örneğin, daraltılmış formdaki bu listeler iki öğe olarak çizilir - bu örnekte düğmeler (diğer stillerde farklı şekilde)
tuval işlevleri denir
FillRectangle // arka planı doldur
Dikdörtgen // çerçeve
FontSet // yazı tipini ayarla
TextOut // metin çıktısı
Belki orada görüntü işleme için bitsel işlemler kullanılıyor.
hayır.
görüntü kaydedildi mi?
evet, CCanvas'taki bir dizide
bir görüntüyü oluşturduktan sonra saklarsanız, içindeki yalnızca belirli bir alanı değiştirin ve hemen ResourceCreate () öğesine gönderin, o zaman gecikme olmaz.
Kesinlikle bu şekilde değil.
benim örneğimde, tüm dizi yeniden çizilir. Dizi temizlenir ve tüm tuval her işlemede yeniden doldurulur. Ardından ResourceCreate çağrılır .
benim örneğimde, tüm dizi yeniden çizilir. Dizi temizlenir ve tüm tuval her işlemede yeniden doldurulur. Ardından ResourceCreate çağrılır .
Detaylı cevap için teşekkürler.
Garip ama bende de aynı şey var. Tüm pencerenin görüntüsü, her arabirim olayında tamamen yeniden oluşturulur. Bu yordam tamamlandığında ResourceCreate'e gönderilen yerel tek boyutlu bir dizide yerleşiktir.
Benim için neden yavaşladığını anlamıyorum... Yarın pencere boyutu ve öğelerin tepki hızı arasındaki ilişkiyi göstereceğim bir gif yayınlayacağım.
Bütün bunlar çok garip...
Detaylı cevap için teşekkürler.
Garip ama bende de aynı şey var. Tüm pencerenin görüntüsü, her arabirim olayında tamamen yeniden oluşturulur. Bu yordam tamamlandığında ResourceCreate'e gönderilen yerel tek boyutlu bir dizide yerleşiktir.
Benim için neden yavaşladığını anlamıyorum... Yarın pencere boyutu ve öğelerin tepki hızı arasındaki ilişkiyi göstereceğim bir gif yayınlayacağım.
Bütün bunlar çok garip...
Zor değilse, görev yöneticisinde CPU kullanımı ile bir gif animasyonu yapın. Veya derlenmiş dosyayı sergeev'in yaptığı gibi göndermek daha kolaydır. Böylece kendiniz test edebilirsiniz.
Tamam, CPU yüklemeli bir video yapacağım. Ancak derlenmiş dosya hakkında - henüz yüklemeyeceğim.
Böcekler için çok utanç verici...)))
Onları düzelttiğimde, onları yayınlayacağıma söz veriyorum.
Tamam, CPU yüklemeli bir video yapacağım. Ancak derlenmiş dosya hakkında - henüz yüklemeyeceğim.
Böcekler için çok utanç verici...)))
Onları düzelttiğimde, onları yayınlayacağıma söz veriyorum.