Przyspieszenie wyświetlania na ekranie

[GrassHoppeR]

niestety przez GDI+ nie mogę tego nijak skompilować. wystarczyłby zwykły Rectangle z GDI...

[GrassHoppeR]

niestety przez GDI+ nie mogę tego nijak skompilować. wystarczyłby zwykły Rectangle z GDI...

poradziłem sobie wywalając GDI+ jakby co. nie wiem co powoduje różnicę w wydajności, przecież to się prawie nie różni od tego, co ja testowałem. czyżby umieszczenie Draw w PaintBox1Paint? dlaczego komunikaty o zmianie rozmiaru okna są przechwytywane a nie obsługiwane w Form1Resize?

[Cyfrowy Baron]

czyżby umieszczenie Draw w PaintBox1Paint?

TPaintBox jest szybszy, dokładnie dlaczego to nie wiem, ale jest to chyba związane w faktem, że ten obiekt udostępnia tylko powierzchnię do rysowania i narzędzia TCanvas, podczas gdy Image sam zarządza tym co się w tym obiekcie narysuje i odświeża go zbyt często. Obiekt PaintBox w moim przykładzie jest odświeżany tylko raz po uruchomieniu programu, potem jeżeli nie przysłonisz okna programu żadnym innym oknem i nie zmienisz rozmiaru, to PainBox nie jest odświeżany, czyli nie jest przerysowywany. W celu osiągnięcia dużej wydajności nie stosowałem odrysowywania tła, lecz tylko fragmentu tła zmienionego przez prostokąt i linie. Steruje tym ta funkcja:

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

void __fastcall TForm1::DrawCopyRect(TRect rCopy)
{
 TRect lineRect = Rect(rCopy.Left, 0, rCopy.Left + 1, PaintBox1->Height);
 PaintBox1->Canvas->CopyRect(lineRect, bitmapa->Canvas, lineRect);

 lineRect = Rect(rCopy.Right, 0, rCopy.Right + 1, PaintBox1->Height);
 PaintBox1->Canvas->CopyRect(lineRect, bitmapa->Canvas, lineRect);

 PaintBox1->Canvas->CopyRect(rCopy, bitmapa->Canvas, rCopy);
}

Kopiowane są fragmenty tła z bufora bitmapa, który stanowi również tło dla PaintBox.

---

dlaczego komunikaty o zmianie rozmiaru okna są przechwytywane a nie obsługiwane w Form1Resize?

Dokładnie to sam nie wiem, ale przechwytywanie komunikatu o zmianie rozmiaru okna daje inny efekt niż użycie zdarzenia OnResize.

---

niestety przez GDI+ nie mogę tego nijak skompilować. wystarczyłby zwykły Rectangle z GDI...

Trochę mało informacji. Dlaczego nie dał się skompilować? Nie wiem czy wersja C++Builder 6 wogóle ma obsługę GDI+, jeżeli ma a nie działa, to trzeba w sekcji include pliku źródłowego Unit1.cpp dodać:

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

#define STRICT // < -- dodano

#include <vcl.h>
#pragma hdrstop

#include "Unit1.h"

#include <windows.h> // <-- dodano
#include <algorithm> // <-- dodano
//---------------------------------------------------------------------------
#pragma package(smart_init)
#pragma resource "*.dfm"

#pragma link "gdiplus.lib" // <-- dodano

using std::min; // <-- dodano
using std::max; // <-- dodano

Jest o tym napisane w serwisie Cyfrowy Baron w dziale: porady grafika Wyświetlanie grafiki z wykorzystaniem biblioteki gdiplus.dll GDI+. Jest tam również napisane, że GDI+ jest dostępne w C++BUilder 6.
w pliku nagłówkowym Unit1.h również w sekcji include:

Kod: Zaznacz cały

#include <gdiplus.h>

Możliwe jest również, że w C++Builder 6 biblioteka gdiplus.lib jest niekompatybilna z biblioteką gdiplus.dll. W tej sytuacji trzeba wejść katalogu ..\Windows\System32\ uruchomić konsolę CMD w tym katalogu i użyć polecenia:

implib -c -f gdiplus.lib gdiplus.dll

Jeżeli wszystko zrobiłeś prawidłowo, to w tym katalogu zostanie utworzony plik gdiplus.lib, który należy skopiować do katalogu środowiska C++Builder 6, nie pamiętam dokładnie ścieżki dostępu, ale to coś w rodzaju: c:\Program Files\Borland\CBuilder\6\lib\psdk\ zastępując nim znajdujący się tam już taki plik. Jeżeli w tym katalogu środowiska C++Builder nie ma takiego pliku, to najpewniej C++Builder 6 nie ma obsługi GDI+. Bibliotekę LIB należy podmienić tylko w sytuacji, gdy kod działa, ale sama obsługa grafiki kuleje, przedtem dobrze jest sobie zrobić kopię tej biblioteki. Jeżeli we wspomnianym katalogu masz bibliotekę gdiplus.lib to nie ma takiej możliwości by to nie działało.

[polymorphism]

Hmm, nie wiem jak u Was, ale ostatni przykład Barona ma tę samą "wadę", która dla autora wątku była duży problemem. U mnie w porywach osiąga 30%.

[Cyfrowy Baron]

Raczej trudno oczekiwać, by program graficzny nie korzystał wogóle z procesora i karty graficznej. W tej chwili przeprowadzam konwersję filmu programem, który całą dostępną moc procesora. By przeprowadzić test, który reprezentuje niżej przedstawiony graf ustawiłem konwerterowi priorytet poniżej normalnego a swojemu programowi priorytet powyżej normalnego. Przesuwanie klocka odbywało się płynnie, szybko, bez skoków, a procesor był wykorzystywany jak widać.

graph.png

[polymorphism]

Raczej trudno oczekiwać, by program graficzny nie korzystał wogóle z procesora i karty graficznej.

No, to wiadomo. Chodzi mi o to, że wcześniej GrassHoppeRowi przeszkadzało zużycie na poziomie 20-30%, a teraz nagle nie, mimo że dostał ode mnie rozwiązanie, które redukuje zużycie do ~2%.

[Cyfrowy Baron]

Program należy tak pisać, by optymalnie wykorzystywał zasoby, ale nie można go pisać w taki sposób, że ma np. wykorzystywać 10 % procesora, bo to akurat zależy od wielu czynników. Nie wszystkie operacje wykonuje procesor główny, bo część operacji graficzny jest wykonywana przez procesor graficzny. Poza tym wszystko zależy od możliwości procesora. Przeprowadziłem test tego programu jednocześnie z programem konwertującym film i program działał płynnie, bez zacinani, migotania, skoków itp. Czas procesora był przydzielany dynamicznie do potrzeb wszystkich działających programów.

Twój program rzeczywiście wykorzystuje procesor w niewielkim stopniu, ale odbywa się to kosztem programu. Animacja migocze i skacze. Trzeba więc ustalić jakieś priorytety, albo program ma działać sprawnie, albo ma w niewielkim stopniu absorbować komputer.

Ja np. u siebie w systemie wyłączyłem plik wymiany, dzięki czemu zyskałem na szybkości operacji wykonywanych w pamięci. Ma to jednak swoja wadę. Gdy uruchomię zbyt dużo programów pamięciożernych to w pewnym momencie wyskakuje niebieski ekran, a wszystko przez to, że w pewnym momencie brakuje pamięci RAM. Coś za coś.

[GrassHoppeR]

Raczej trudno oczekiwać, by program graficzny nie korzystał wogóle z procesora i karty graficznej.

No, to wiadomo. Chodzi mi o to, że wcześniej GrassHoppeRowi przeszkadzało zużycie na poziomie 20-30%, a teraz nagle nie, mimo że dostał ode mnie rozwiązanie, które redukuje zużycie do ~2%.

spoko, wnioski wyciągnąłem. klucz do wydajności to tak jak napisałeś już wcześniej obsługa co jakiś minimalny interwał a nie za każdym ruchem myszki, bo wtedy procesor nic nie robi tylko odświeża widok. zastosowałem DoubleBurrefing i rysowanie na bitmapie (bez GDI+) oraz interwał czasowy więc myślę, że nie będzie ani migotać ani zwalniać i dzięki temu program będzie działać sprawnie i w niewielkim stopniu absorbować procesor.
w związku z tym jeszcze pytanie - jak elegancko rozwiązać wywoływanie danej funkcji co dany interwał czasowy, np. 50 ms?

[polymorphism]

Twój program rzeczywiście wykorzystuje procesor w niewielkim stopniu, ale odbywa się to kosztem programu. Animacja migocze i skacze.

Ech, Baron, przecież pisałem, żeby nie zwracać na to uwagi, bo nie nie o to mi chodziło. I nic nie odbywało się kosztem programu, po prostu nie chało mi się pisać kodu, który poza estetyką nic nie wnosił. No, ale ok, w załączniku masz program bez migotania.

[polymorphism]

jak elegancko rozwiązać wywoływanie danej funkcji co dany interwał czasowy, np. 50 ms?

No przecież Ci pokazałem jak!

50ms to za dużo. Przy 40ms jest już widoczny brak płynności. Najlepiej dać między 10 a 20ms, więcej nie ma sensu.

[GrassHoppeR]

No przecież Ci pokazałem jak!

ale to nie jest elegancko

chciałbym wywoływać funkcję, która co jakiś czas sprawdza, czy trzeba odświeżyć widok. szukam czegoś jak wywoływanie zdarzenia timerem.

[polymorphism]

ale to nie jest elegancko

Bo? Biorąc pod uwagę kod z pierwszego posta, na temat elegancji powinieneś się wypowiadać dość ostrożnie

Można jeszcze zrobić tak, że m_last_repaint_time byłaby lokalną zmienną statyczną, ale to nie jest eleganckie rozwiązanie.

szukam czegoś jak wywoływanie zdarzenia timerem.

Hmm, timer?

[GrassHoppeR]

Bo?

...chciałbym wywoływać funkcję, która co jakiś czas sprawdza, czy trzeba odświeżyć widok.

Biorąc pod uwagę kod z pierwszego posta, na temat elegancji powinieneś się wypowiadać dość ostrożnie

kod z pierwszego posta to okrojona na maxa wersja testowa i niezoptymalizowana, poglądowa, żeby było widać gdzie tkwi błąd. ale nawet w nim stosując interwał byłoby w miarę dobrze.

Hmm, timer?

a co? bo nie w temacie jestem.

[polymorphism]

...chciałbym wywoływać funkcję, która co jakiś czas sprawdza, czy trzeba odświeżyć widok.

Tylko jak to się ma do elegancji mojego kodu/rozwiązania/whatever?

a co?

Chodzi mi o to, że to 'coś', czego szukasz, to timer.

[GrassHoppeR]

Chodzi mi o to, że to 'coś', czego szukasz, to timer.

tak, ale szukam jak to coś wykorzystać.

p.s. nie odpowiedziałeś mi na pytanie, co w mojej propozycji jest nieeleganckiego?

działa tylko przy ruchu klocka, a przydałoby aby działało też przy resize okna i przesuwaniu widoku. chcę to zrobić w jednym miejscu po prostu.