Przyspieszenie wyświetlania na ekranie

[polymorphism]

działa tylko przy ruchu klocka

No, tak. Ponieważ od początku rozważany był problem z wydajnością operacji drag&drop. Jeśli chodzi o przewijanie widoku, czy też zmianę jego rozmiaru, metody tej nie możesz tu zastosować.

[Cyfrowy Baron]

No, ale ok, w załączniku masz program bez migotania.

Klocek nie przesuwa się jednak płynnie.

---

Czytając kolejne posty przestałem rozumieć o co chodzi w tym programie. Pytanie odnośnie częstotliwości odświeżania nie ma tutaj sensu. Odświeżanie powinno zachodzić tylko wtedy gdy jest konieczne. Po co odświeżać cały TImage skoro można odświeżać tylko zmieniające się fragmenty grafiki tak jak podałem. Do odświeżania nie potrzebna są żadne pętle, zegary itp. trzeba posłużyć się zdarzeniem OnRepaint, które zawsze jest wywoływane, gdy okno wymaga odświeżenia. To właśnie to zdarzenie jest mechanizmem sprawdzającym, czy należy odświeżyć okno. Okno programu to również element graficzny, jak wszystko co na tym oknie się znajduje.

GrassHoppeR pisze, że chce stworzyć wydajny program, a ja wykazałem, że TImage jest około 7 razy wolniejsze od TPaintBox. O co chodzi z tą wydajnością.
Powiedz mi GrassHoppeR , czy Ty jeszcze wiesz o co Tobie chodzi? Jakie są założenia tego programu?

Przestań kombinować z tą wydajnością, gdyż w przypadku bardziej rozbudowanej aplikacji to się posypie. Stwórz wydajny program.

Bez jasno zdefiniowanych założeń dla programu nie będę się już wypowiadał w tym wątku, gdyż stworzyłem wydajny kod spełniający wszystkie założenia jakie postawiono na wstępie. Program obciąża system w niewielkim stopniu, wszak klocek nie wędruje po oknie nieustannie. Dodałem przeźroczystość klocka. Usunąłem problem z migotaniem okna. Klocek przesuwa się płynnie. Wielkość bitmapy ustawionej jako tło nie ma wpływu na wydajność. Nie ma innych założeń.

[polymorphism]

Klocek nie przesuwa się jednak płynnie.

Wystarczająco płynnie, żeby można było zaimplementować wygodny drag&drop. Szukasz dziury w całym. Zresztą klocek w Twoim programie migocze (wersja z GDI+).

[Cyfrowy Baron]

Zresztą klocek w Twoim programie migocze (wersja z GDI+).

Koszt przeźroczystości. Można by to zoptymalizować poprzez dodatkowe buforowanie i kopiowanie, ale spadnie wydajność. Klocek będzie przesuwał się płynnie bez skoków i migotania, ale będzie zajmował więcej czasu procesora.

Szukasz dziury w całym.

Wzorem miał być skrypt na którym klocek przesuwał się płynnie.

[polymorphism]

Koszt przeźroczystości. (...) Klocek będzie przesuwał się płynnie bez skoków i migotania, ale będzie zajmował więcej czasu procesora.

No przecież mój program to robi, zużywając mniej % CPU, więc jaki koszt przeźroczystości?!

Wzorem miał być skrypt na którym klocek przesuwał się płynnie.

...i zużywa jak najmniej % CPU. U mnie się przesuwa (wystarczająco) płynnie, a zużycie jest poniżej 2%. Patrz na usability, a nie na jeden element (w tym przypadku płynność, która w tym przypadku nie jest aż tak ważna).

[Cyfrowy Baron]

No przecież mój program to robi, zużywając mniej % CPU, więc jaki koszt przeźroczystości?!

Sprawdziłem użycie CPU przez Twój program dokładnie tak samo jak mojego i u ciebie dochodzi do 82%, przy szybkim przesuwaniu klocka, czyli znacznie wyżej niż u mnie, że nie wspomnę iż na pełnym ekranie klocek skacze.

graph.png

Stosując buforowanie połączone z kopiowaniem eliminuję u siebie migotanie, a zużycie CPU mam niższe niż u Ciebie. Te same warunki testów.

U mnie się przesuwa (wystarczająco) płynnie,

Ruch płynny jest ale tylko na małym oknie, po rozciągnięciu na cały ekran w rozdzielczości 1280x1024 klocek skacze o dwie swoje długości, więc trudno uznać to za ruch płynny.

[GrassHoppeR]

Po co odświeżać cały TImage skoro można odświeżać tylko zmieniające się fragmenty grafiki tak jak podałem.

nic takiego nie ma miejsca. chodzi o odświeżanie tylko wtedy, kiedy to jest konieczne i nie częściej niż ileś razy na sekundę, bo to jest właśnie odpowiedź na tytułowe pytanie. bez tego ostatniego warunku cała moc procesora idzie w gwizdek. od początku pisałem, że oczywiście docelowo odświeżam tylko obszar na którym był narysowany klocek, ale to nie rozwiązywało problemu, bo leżał on gdzie indziej.

Powiedz mi GrassHoppeR , czy Ty jeszcze wiesz o co Tobie chodzi? Jakie są założenia tego programu?

od samego początku jasno i precyzyjnie opisuję o co mi chodzi w efekcie końcowym (podałem linka do filmu pokazującego do czego on służy i do jego wersji we flashu) i w tym konkretnym problemie (zamieściłem wersję okrojoną, aby jak najlepiej go zobrazować). założenia są jasno określone, jednak bardzo specyficzne, i nie ma sensu ich tłumaczyć. program jest przemyślany i zapewniam cię, że moje pytania są jak najbardziej uzasadnione, najwyżej w kontekście podanego przykładu niezbyt zrozumiałe i wynikają jedynie z niezbyt jeszcze dla mnie zrozumiałej filozofii okienek. nic chyba dziwnego, skoro to mój pierwszy program w tym środowisku, prawda?

w mojej wersji klocki rysowane są na bitmapie więc liczę zarówno na brak migotania jak i założoną płynność około 20-30 klatek na sekundę. na razie nie korzystam z GDI+, ale Image zmieniłem na PaintBox, i działam dalej.

[polymorphism]

(...) i u ciebie dochodzi do 82%

A jaki procesor?

skacze o dwie swoje długości, więc trudno uznać to za ruch płynny.

No jeśli zrobiłeś szybki ruch myszką o dwie długości, no to trudno, żeby nie było przeskoku o dwie długości.

[Cyfrowy Baron]

Wszystko zostało już wyjaśnione. Kod masz. Za odświeżanie grafiki odpowiada zdarzenie OnRepaint, już to wyjaśniłem i nie widzę powodu ponownie tłumaczyć.

[GrassHoppeR]

a czy ja napisałem, że czegoś nie rozumiem?

[Cyfrowy Baron]

A jaki procesor?

Co za różnica, skoro porównuję dwa programy w jednym systemie. W moim programie dochodziło w tych samych tekstach do 40% i klocki wciąż przemieszczały się płynnie. CPU 2,3 GHz.

No jeśli zrobiłeś szybki ruch myszką o dwie długości, no to trudno, żeby nie było przeskoku o dwie długości.

U mnie zawsze podąża za myszką niezależnie od szybkości ruchów.

Jedyne co mogę przyznać, to że nie potrafię obejść tego migotania klocka. Jest to jak sądzę spowodowane zwłoką między kopiowaniem i rysowaniem, zbyt wiele obliczeń między tymi operacjami. Gdy odejmę rysowanie linii migotanie się zmniejsza. Nie mam na razie pomysłu jak to zmienić.

[Cyfrowy Baron]

Wąskim gardłem jest 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);
}

ale nie mam jej czym zastąpić.

[polymorphism]

Co za różnica

Różnica żadna, raczej ciekawość. Jeśli dochodzi do 80%, to znaczy, że rysowanie zajmuje więcej czasu niż ustawione 10ms - wtedy ograniczenie częstotliwości odświeżań nie działa, rysowanie odbywa się w sposób typowy, co każdy ruch myszy, tak jak w Twoim programie. Mogłem jeszcze bardziej swój program zoptymalizować, ponieważ teraz za każdym razem odmalowywane jest całe tło, a nie tylko te fragmenty, które tego wymagają, ale... po co? Co chciałem, to pokazałem.

Pisałeś, że kompresujesz film, więc nie dziwi mnie taki wynik...

U mnie zawsze podąża za myszką niezależnie od szybkości ruchów.

Jak już pisałem, patrz na szerszy kontekst. W szybkim przeciąganiu nie interesuje mnie jego płynność, bo i tak jeśli będę chciał uzyskać precyzję, to będę przesuwał kursor myszy wolniej, a tym samym dam procesorowi więcej czasu na rysowanie.

[polymorphism]

Jedyne co mogę przyznać, to że nie potrafię obejść tego migotania klocka.

Sprawa jest prosta. Klocek rysujesz na bitmapie z tłem, tylko zanim to zrobisz, kopiujesz do pomocniczej bitmapy ten fragment tła, który zostanie zamalowany przez klocek. Tak namalowany klocek razem z tłem kopiujesz na okno. Przy następnym rysowaniu, zamalowujesz klocek oryginalnym tłem. I tak w kółko. W przypadku przeciągania bardziej złożonych rzeczy, trzeba zastosować triple-buffering.

[GrassHoppeR]

panowie, przecież problem został już rozwiązany! była to zbyt częsta obsługa czasochłonnych operacji. teraz wszystko działa tak, jak sobie założyłem, a nawet lepiej!

Wąskim gardłem jest ta funkcja:

nie w tym przypadku. wąskim gardłem byłoby to, gdyby chodziło o maksymalnie szybkie rysowanie klipów. tu jednak chodzi o maksymalnie rzadkie odświeżanie całego widoku.
w mojej wersji klipy są rysowane w stosunkowo powolny sposób, a jednak zużycie procesora rzadko kiedy sięga 2%, mimo że bitmapa jest nadal zakolorowywana cała i wszystkie klipy rysowane są od nowa (co oczywiście właśnie zmieniam). kod różni się od tego prezentowanego prędzej tylko umieszczeniem obsługi odmalowywania i odświeżania w OnTimer i to już wystarcza.

chętnie zaprezentuję rezultat, jak tylko uporam się z kilkoma małymi sprawami.


edit:
albo nie będę się teraz nimi zajmował, tylko wrzucam poprawioną wersję: http://grasshopper.no-ip.info/Project1.zip

PS. jak pozbyć się migotania w OnResize? zwróćcie uwagę, że bitmapa zaczepiona jest w lewym-dolnym rogu a nie górnym, jak standardowo. może to ma wpływ?