Przyspieszenie wyświetlania na ekranie

[Cyfrowy Baron]

operuję BEZPOŚREDNIO na bitmapie w pamięci a nie na TBitmap.

Wypisujesz głupoty. Nie możesz operować na bitmapie inaczej niż poprzez klasę TBitmap. Operujesz w pamięci, gdyż inaczej się nie da, ale to niczego nie zmienia. W C++ wszystkie standardowe operacje są wykonywane w oparciu o GDI, nawet okno formularza jest tworzone przez GDI, podobnie jak wszystkie obiekty na formularzu. Image1->Picture->Bitmap - jak sądzisz czym jest to Bitmap w Picture? To obiekt klasy TBitmap.

Z tego co się orientuję to Direct2D dostępne jest chyba dopiero od DirectX w wersji 10.

[GrassHoppeR]

w takim razie wracamy do początku - jak najlepiej zrobić, aby obciążenie procesora przy pracy na pełnym ekranie było jak najmniejsze?
przy włączonym DoubleBuffered wydajność leci na pysk z samego tylko faktu buforowania. skoro zatem GDI wyrabia w znacznie bardziej złożonych sprawach to dlaczego nie wyrabia w tak prostym? (pomińmy czyszczenie bitmapy, bo rozwiążę to w inny sposób).

Wypisujesz głupoty.

może i wypisuję głupoty. robię to analogicznie jak w Twoim Invert z porady->grafika.

[Cyfrowy Baron]

jak najlepiej zrobić, aby obciążenie procesora przy pracy na pełnym ekranie było jak najmniejsze?

To może coś sobie wyjaśnijmy. Ty chcesz zrobić program, który nie korzysta z procesora, czy program, który wykonuje jakieś operacje?!

[polymorphism]

Wyniki w porywach dla 8 klocków (E5200, choć tu karta gr. ma większe znaczenie):

• DB_noFillRect - 24%
• noDB_FillRect - ~60%
• noDB_noFillRect - ~26%

[GrassHoppeR]

Wyniki w porywach dla 8 klocków (E5200, choć tu karta gr. ma większe znaczenie):

• DB_noFillRect - 24%
• noDB_FillRect - ~60%
• noDB_noFillRect - ~26%

a to mnie zaskoczyło... czyli chodzi prawdopodobnie o kartę. to też niestety tylko połowicznie dobra wiadomość.

To może coś sobie wyjaśnijmy. Ty chcesz zrobić program, który nie korzysta z procesora, czy program, który wykonuje jakieś operacje?!

chcę zrobić program, który nie obciąża procesora pierdołami.

chociaż w sumie można powiedzieć, że tak. chcę zrobić program, który nie korzysta (prawie) z procesora. procesor ma w tym momencie np. renderować video w tle.
dlatego z chęcią pokazywanie klocków przekazałbym karcie graficznej. to jedna opcja. a druga - żeby jak najmniej obciążał procesor w przypadku słabej grafiki (np. w VirtualBox).

[Cyfrowy Baron]

a to mnie zaskoczyło... czyli chodzi prawdopodobnie o kartę. to też niestety tylko połowicznie dobra wiadomość.

Już kilka postów wcześniej zostało wyjaśnione, że GDI korzysta ze wsparcia sprzętowego.

Przejrzałem te twoje programy i mogę stwierdzić jedno. Wystarczy tutaj zastosować styl pędzla pmNotXor i nie ma potrzeby odświeżania tła, przy założeniu że przesuwany prostokąt jest nieprzeźroczysty. Wtedy kod będzie działał szybko nawet gdy tłem będzie bitmapa. Co więcej nie trzeba wogóle tej bitmapy odświeżać ani przerysowywać. Jest to prostsza wersja kodu, który zaproponowałem we wcześniejszym poście. Coś podobnego zrobiłem z punktami w wątku: http://programowanie.cal.pl/forum/viewtopic.php?f=4&t=1170


Nie wiem o co chodzi z tym czyszczeniem bitmapy, ale u mnie z zastosowaniem funkcji FillRect odbywa się to błyskawicznie:

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

 Image1->Picture->Bitmap->Canvas->Brush->Color = clWhite;
 Image1->Picture->Bitmap->Canvas->FillRect(Image1->ClientRect);

a tak jest nawet szybciej.

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

#include <memory>
 std::auto_ptr<Graphics::TBitmap> tmpBmp(new Graphics::TBitmap);
 Image1->Picture->Bitmap->Assign(tmpBmp.release());

[polymorphism]

jak najlepiej zrobić, aby obciążenie procesora przy pracy na pełnym ekranie było jak najmniejsze?

Jeśli chodzi o metodę, to już napisałem jak ja to robię. Wiesz, odnoszę wrażenie, że starasz się wyciągnąć jak najwięcej fps-ów, co w przypadku statycznej kontrolki jest nieporozumieniem. Zrób tak, żeby przy przeciąganiu klocków nie cięło się i żeby nie spadał komfort pracy. A to, czy CPU osiągnie w porywach 100% czy 10%, nie ma aż takiego znaczenia.

[polymorphism]

a tak jest nawet szybciej.

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

#include <memory>
 std::auto_ptr<Graphics::TBitmap> tmpBmp(new Graphics::TBitmap);
 Image1->Picture->Bitmap->Assign(tmpBmp.release());

Przecież to nie jest to samo co FillRect? Przypisujesz pustą bitmapę, zmieniając rozmiar docelowej bitmapy. Jeśli dobrze pamiętam, Assign służy do deserializacji obiektów, a nie kopiowania bitmap. A nawet jeśli jest inaczej, to tworzenie nowej bitmapy tylko po to, żeby wyczyścić inną, jest bez sensu...

[Cyfrowy Baron]

Dokładnie tak jest. Posłużyłem się nową pustą bitmapą, gdyż działa to szybciej niż funkcja FillRect. By jednak móc potem rysować po Image, trzeba wczytać nową bitmapę. Troszkę zresztą zaszalałem, bo do wyczyszczenia bitmapy w Image wystarczy:

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

Image1->Picture = NULL;

Co się tyczy Assign to w pomocy dla TImage możemy przeczytać: method Assign public - Copies the contents of another, similar object.

Poza tym funkcja FillRect też nie służy do czyszczenia bitmapy lecz do wypełnienia obszaru kolorem.

[polymorphism]

Czyszczenie to skrót myślowy, chodzi o zamalowanie rysunku tłem. Więc w tym kontekście FillRect czyści bitmapę.

[Cyfrowy Baron]

Nie czyści lecz zamalowuje. Wczytanie nowej bitmapy do starej czyści. Można by się oczywiście sprzeczać o znaczenie jednego i drugiego, a tutaj tylko chodzi o wybranie najodpowiedniejszej i najwydajniejszej metody przywrócenia bitmapy do pierwotnego stanu jak zakładam. Moim zdaniem najskuteczniejszą metodą jest przechowywanie oryginalnej bitmapy w buforze i przekopiowywanie całej bitmapy lub wybranego jej fragmentu co zaproponowałem we wcześniejszym poście. Funkcja FillRect jest niewydajna.

[Cyfrowy Baron]

Przeprowadziłem dwa testy z pomiarem czasu:

---

przykład 1:

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

 float Start = GetTickCount();

 Image1->Picture->Bitmap->Canvas->Brush->Color = clBlue;
 Image1->Picture->Bitmap->Canvas->FillRect(Image1->ClientRect);

 float End = GetTickCount();

 ShowMessage(FloatToStr(End - Start) + " ms");

6 ms.

---

przykład 2:

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

 float Start = GetTickCount();

 std::auto_ptr<Graphics::TBitmap> tmpBmp(new Graphics::TBitmap);
 tmpBmp->Width = Image1->Width;
 tmpBmp->Height = Image1->Height;
 tmpBmp->Canvas->Brush->Color = clBlue;
 tmpBmp->Canvas->FillRect(Image1->ClientRect);
 Image1->Picture->Bitmap->Assign(tmpBmp.release());

 float End = GetTickCount();

 ShowMessage(FloatToStr(End - Start) + " ms");

0 ms.

---

Druga metoda jest szybsza mimo iż wykonywanych jest więcej operacji. Przypuszczam iż wiąże się to z faktem, że wypełnianie obiektu typu TBitmap kolorem odbywa na bitmapie, która jest pusta. Przeprowadziłem również test z bitmapą tylko w pamięci, czyli w buforze i uzyskałem gorszy efekt niż w drugim przykładzie:

przykład 3:

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

 float Start = GetTickCount();

 Buffer->Canvas->Brush->Color = clBlue;
 Buffer->Canvas->FillRect(Image1->ClientRect);
 Image1->Picture->Bitmap->Assign(Buffer);


 float End = GetTickCount();

 ShowMessage(FloatToStr(End - Start) + " ms");

Po pierwszym wywołaniu uzyskałem czas 0 ms, ale kolejne wywołania były gorsze, gdyż dawały ponad 20 ms. W drugim przykładzie po każdym wywołaniu uzyskałem 0 ms.

[GrassHoppeR]

Czyszczenie to skrót myślowy, chodzi o zamalowanie rysunku tłem. Więc w tym kontekście FillRect czyści bitmapę.

racja, przynajmniej jeśli chodzi o "czyszczenie" w tym sensie, że jest to zamalowanie powierzchni kolorem (255,255,255).

Przejrzałem te twoje programy i mogę stwierdzić jedno. Wystarczy tutaj zastosować styl pędzla pmNotXor

być może w tym konkretnym przykładzie klocków - tak. jednak to tylko przykład, gdyż docelowo elementy te miały wyglądać inaczej. prawdopodobnie wykorzystam sporą część kodu, który zaprezentowałeś, ale w tej chwili ważniejsze jest dla mnie obranie właściwej koncepcji całości. wygląda na to, że lepiej unikać rzeźbienia na własną rękę. ewentualnie zmienię koncepcję i faktycznie wykorzystam ten styl.

Wiesz, odnoszę wrażenie, że starasz się wyciągnąć jak najwięcej fps-ów, co w przypadku statycznej kontrolki jest nieporozumieniem.

w zasadzie masz rację. staram się wyciągnąć max fps'ów = jak najmniej obciążający sposób rysowania. w końcu nie po to siedziałem nad skryptami i pluginami do przetwarzania obrazu, żeby mi teraz jakieś kopiowanie bitmap zżerało większość mocy procesora, potrzebnej w tym czasie gdzie indziej.

Troszkę zresztą zaszalałem, bo do wyczyszczenia bitmapy w Image wystarczy:

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

Image1->Picture = NULL;

no z tym to zwolnił u mnie maksymalnie...

Moim zdaniem najskuteczniejszą metodą jest przechowywanie oryginalnej bitmapy w buforze i przekopiowywanie całej bitmapy lub wybranego jej fragmentu co zaproponowałem we wcześniejszym poście.

zgadza się, jednak te metody już wypróbowałem zanim rozpocząłem ten wątek, i przyrost wydajności był pomijalny w stosunku do wyłączenia buforowania. rozumiem teraz, że to przez kartę graficzną, prawda?

dzięki za testy, spróbuję u siebie z GetTickCount i zobaczę jak to wychodzi. potem skoczę po kartę i sprawdzę z nią, bo przyznam szczerze, że wyniki tego testu mnie zdziwiły. z drugiej strony samo "czyszczenie" nie jest tak istotne jeśli zastosuję inny algorytm przywracania tła tylko pod klockiem. jednak sposób z tworzeniem nowej bitmapy, o ile faktycznie będzie szybsze, przyda się w innym miejscu, np. przy zmianie wielkości albo przesuwaniu (tutaj sposób z drugą bitmapą zmniejszył wydajność).

korci mnie jednak ten DirectDraw. samo wyświetlanie bitmapy powinno mi wystarczyć. tylko jak to zrobić w okienku?!

[Cyfrowy Baron]

zgadza się, jednak te metody już wypróbowałem zanim rozpocząłem ten wątek, i przyrost wydajności był pomijalny w stosunku do wyłączenia buforowania. rozumiem teraz, że to przez kartę graficzną, prawda?

Nie miałem na myśli podwójnego buforowania - DoubleBuffered = true, lecz chodziło mi o przechowywanie w odrębnym obiekcie klasy TBitmap grafiki do szybszego pobierania. Tak jak to masz w moim przykładzie - obiekt Buffer.

[GrassHoppeR]

tak właśnie miałem. druga bitmapa zawierała wszystkie namalowane klocki oprócz aktywnego, następnie przekopiowywałem tylko fragment zmieniony. to było najprostsze i sprawdziłem jako pierwsze. jednak mimo tego i tak podczas przesuwania klocka program się przytykał. przy przesuwaniu całej powierzchni (scrollbarem albo kółkiem) albo przy powiększaniu okna i w wielu innych okolicznościach trzeba było nie tylko odświeżyć bitmapę tymczasową ale i przekopiować ją całą na bitmapę główną, choć próbuję znaleźć sposób na ograniczenie zasięgu odświeżania. trochę trudno mi tłumaczyć motywy tego mojego szukania wydajności, ale to naprawdę istotne. to tylko jeden z elementów całości, którą planuję napisać.

konkluzja jest taka - nie da się przeskoczyć DoubleBufferingu, w grę wchodzi jedynie przyspieszenie malowania. tak?