Przyspieszenie wyświetlania na ekranie

[polymorphism]

Przeprowadziłem dwa testy z pomiarem czasu:

Zbyt małe różnice. Żeby wyniki były miarodajne, musiałbyś przeprowadzić pomiar kilkuset operacji. A tak, 6ms mieści się w marginesie błędu systemowego timera. Nie wierzę w to, że drugi kod jest szybszy od pierwszego.

U mnie pięciusetkrotne wypełnienie bitmapy 1500x1500 trwa ~2625ms, czyli ~5.25ms na wywołanie.

[polymorphism]

Pomiarów ciąg dalszy...

Te same testy z wykorzystaniem GDI+, lekka półprzeźroczystość: 20328ms, co daje ~40,6ms na wywołanie.

[Cyfrowy Baron]

Przeprowadziłem testy na wszystkich trzech przykładach wywołując zmiany 10 krotnie:

1 przykład = 60 ms
2 przykład = 10 ms
3 przykład = 250 ms

Bitmapa w rozdzielczości 1280 x 1024.

[polymorphism]

Pytanie, jakim cudem 2 jest szybsza od 1, przecież robi dokładnie to samo co 1, dodatkowo tworzy nową i usuwa starą bitmapę? Wynik 3 to już w ogóle jakiś kosmos...


Gdzieś robisz błąd.

[Cyfrowy Baron]

Przecież napisałem, że mimo iż przykład 2 wykonuje więcej operacji to działa najszybciej, jak sądzę jest to spowodowane tym, że operacja wypełnienia FillRect jest wykonywana na pustej bitmapie. W pomocy do TCanvas nie mam szczegółowych opisów tych funkcji, a jedynie opis tego co robią, więc nie wiem jak to działa.
Testy były przeprowadzane w pętli, czyli:

przykład 1: 60 ms

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

 float Start = GetTickCount();

 for(int i = 0; i < 10; i++)
 {
  Image1->Picture->Bitmap->Canvas->Brush->Color = clBlue;
  Image1->Picture->Bitmap->Canvas->FillRect(Image1->ClientRect);
 }

 float End = GetTickCount();

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

Przykład 2: 10 ms

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

 float Start = GetTickCount();
 
 for(int i = 0; i < 10; i++)
 {
  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");

Przykład 3: 250 ms

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

 float Start = GetTickCount();

 for(int i = 0; i < 10; i++)
 {
  Buffer->Canvas->Brush->Color = clBlue;
  Buffer->Canvas->FillRect(Image1->ClientRect);
  Image1->Picture->Bitmap->Assign(Buffer);
 }

 float End = GetTickCount();

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

Testy powtórzone kilkakrotnie zawsze z tym samym wynikiem, na bitmapie wczytanej do Image1 i Buffor w rozdzielczości 1280x1024 i w 24 bitowej głębi kolorów. Obiekt Buffor zawiera tą samą bitmapę co Image1. W programie zmieniał się tylko kod w pętli, nic ponad to. Test przeprowadzałem przy uruchomionym tylko środowisku C++Builder, ale poza środowiskiem. Program był skompilowany pod kontem wydajności, nie rozmiaru.

Mam wątpliwości, czy tego typu testy są wogóle miarodajne. Poza tym nie chce mi się już kontynuować tego tematu. Zaproponowałem rozwiązanie ze sterowaniem stylem pędzla i odświeżaniem tylko przesłoniętego fragmentu tła, więc jest to w miarę wydajne. Nic więcej nie wymyślę z GDI, bo nie wiem co w zasadzie można by zmienić. Co do funkcji FillRect to przypuszczam, że nie jest wywoływana każdorazowo, gdy zachodzą zmiany w tle, bo niby po co, więc problem wydajności na tym polu jest raczej drugorzędny. Jeżeli jednak autor wątku tak właśnie robi, to powinien przemyśleć koncepcję całego programu, gdyż nawet najwydajniejsze funkcje niewiele zdziałają, jeżeli zostaną użyte w niewłaściwy sposób. Z GDI można zrobić dużo, ale nie wydajną grę, a odnoszę wrażenie, że autor wątku chce stworzyć jakiś program z wydajnością gry, a to wymaga użycia DirectX.

Na co dzień często korzystam z programu Photoshop, który jest bardzo wydajnym programem graficznym, ale wykonywanie niektórych operacji jak np. przesuwanie jednej warstwy po drugiej, przy dużych bitmapach nie odbywa się jakoś specjalnie płynnie. Nie sposób uzyskać w GDI szybkości rzędu 60 klatek na sekundę, bez bardzo mocnego procesora i bardzo dobrej karty graficznej. Podkreślam - program przetwarzający grafikę to nie gra, a chcesz zrobić grę, zrób ją w DirectX lub OpenGL.

[polymorphism]

(...) jak sądzę jest to spowodowane tym, że operacja wypełnienia FillRect jest wykonywana na pustej bitmapie.

To akurat nie ma żadnego związku. Pusta, niepusta, i tak musi ustawić każdy piksel.

W drugim przykładzie masz wyciek...

Mam wątpliwości, czy tego typu testy są wogóle miarodajne.

Są miarodajne, bo możesz określić wąskie gardła. Tu nie chodzi o konkretną wartość, bo ta, wiadomo, może różnić się w zależności od sprzętu czy systemu, chodzi tu o stosunki między różnymi wartościami pomiarów.

Co do funkcji FillRect to przypuszczam, że nie jest wywoływana każdorazowo, gdy zachodzą zmiany w tle, bo niby po co

FillRect jest tylko przykładem, ponieważ to ona tworzy tło. Jeśli tłem byłaby bitmapa, wtedy rozważana byłaby CopyRect.

[GrassHoppeR]

moje testy wprawiły mnie w konfuzję.
np. wg TickCount na zintegrowanej GMA X4500 jak i na Radeonie 2600 XT 1000 razy wywołane FillRect na zmaksymalizowanym oknie 1920x1080 zajmuje około 2500 ms... w tym czasie cały system się zamraża a Radek kręci wentylatorkiem jak szalony.
przecież przy tego rzędu wielkościach taki czas pojedynczego wykonywania FillRect'a (2,5 ms) nie powinien mieć wcale znaczenia dla płynności aplikacji. nie mam pojęcia o co tu chodzi...

[polymorphism]

w tym czasie cały system się zamraża

To na czym Ty to testujesz, Win9x?!

[GrassHoppeR]

na XP. FillRect w pętli i w tym czasie wszystko stoi, z Menedżerem Zadań włącznie.

[polymorphism]

Hmm, dziwne. U mnie poza aplikacją wszystko chodzi bez problemu.

[Cyfrowy Baron]

W drugim przykładzie masz wyciek...

Nie mam. Wzorzec klasy auto_ptr sam po sobie sprząta.

---

np. wg TickCount na zintegrowanej GMA X4500 jak i na Radeonie 2600 XT 1000 razy wywołane FillRect na zmaksymalizowanym oknie 1920x1080 zajmuje około 2500 ms... w tym czasie cały system się zamraża a Radek kręci wentylatorkiem jak szalony.

Podobny test, czas podobny, ale brak opisanych przez Ciebie objawów. Nie bardzo rozumiem, co u ciebie tak obciąża kartę graficzną. Musisz mieć jakieś błędy w systemie.
Przeprowadziłem test z obiektem PaintBox i osiągnąłem czas siedmiokrotnie krótszy dla tej samej operacji. Dla tego obiektu funkcja FillRect jest tak szybka jak powinna. W przypadku PaintBox trzeba jednak w odróżnieniu od Image kod rysujący umieszczać w zdarzeniu OnRepaint obiektu PaintBox lub formularza, w przeciwnym razie przesłonięcie okna innym wymarza zawartość PaintBox, czyli grafika musi być cały czas odświeżana, gdyż w odróżnieniu od Image, PaintBox nie zarządza samodzielnie odświeżaniem.

[polymorphism]

Nie mam. Wzorzec klasy auto_ptr sam po sobie sprząta.

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

...

Image1->Picture->Bitmap->Assign(tmpBmp.release());

Przeczytaj w dokumentacji, co robi metoda release.

[Cyfrowy Baron]

The member replaces the stored pointer myptr with a null pointer and returns the previously stored pointer.

Jak rozumiem zrzeka się kontroli na obiektem i go zeruje.

[polymorphism]

Nie 'go zeruje', tylko sam siebie zeruje.

[Cyfrowy Baron]

No tak, traci nad nim kontrolę. Powinienem więc użyć get() zamiast release().