Przyspieszenie wyświetlania na ekranie

[Cyfrowy Baron]

a Twój program nie korzysta z GDI+ przypadkiem?

Mój program korzysta z GDI+ tylko do odrysowania klocka, cała reszta oparta jest na GDI.

---

w tej wersji http://grasshopper.no-ip.info/Project1.zip zmieniłem częstość odświeżania co 40 ms. mógłbyś sprawdzić jak wygląda obciążenie w jego przypadku?

Tak wygląda:

graph.png

---

i wytłumacz mi, proszę, na czym polega optymalizacja w przypadku Twojego programu.

Tło odrysowywane jest tylko w zdarzeniu OnPaint, a więc tylko gdy zachodzi taka potrzeba. W praktyce tylko raz po uruchomieniu programu o ile okno zawsze pozostaje na wierzchu. Przywrócenie fragmentu tła pod przesuwanym klockiem polega na kopiowaniu tła z bufora przechowującego oryginalne nie zmienione tło. Zresztą kod już widziałeś.

---

Może coś ustalmy - kwestię sprzętu i oprogramowania. Ja już w zasadzie swój podałem, dodam tylko, że używam WinXP wersji 32 bitowej i mam 2 GB RAM. Co wy macie - CPU, karta graficzna, system?

[polymorphism]

A u mnie pokazuje co innego, co zresztą widać na wykresach. I co Ty na to?

No właśnie staram się zrozumieć, skąd aż takie rozbieżności. Czy nie masz przypadkiem włączonego trybu oszczędności energii lub coś w tym stylu (SpeedStep) ?

Co do sprzętu: 2x2.5GHz (E5200), 2GB RAM, GF9400GT, WinXP SP2 32bit.

[Cyfrowy Baron]

Nie mam włączonego trybu oszczędzania energii. Przypuszczam, że to kwestia procesora, a konkretnie jego instrukcji. Wasze procesory są nowsze i maja nowsze instrukcje, być może jakieś oferujące wsparcie dla grafiki.

[GrassHoppeR]

no to garść screenów ode mnie teraz:

dual-core t4300 2.1GHz 4GB radeon HD4570 1366x768 vista

sosa1.PNG

amd athlon64 X2 dual 5000+ 2,6 GHz 2 GB geforce 8800GT 1680x1050 xp sp3

sosa2.PNG

i najlepsze:
amd sempron 2800+ 1,61GHz 512MB radeon X550 1280x1024 xp sp1

rosa1.PNG

1/4 dwóch pierwszych wykresów to "normalna praca",
1/4 znęcanie się nad długim klockiem
1/4 szybki resize okienka
1/4 szybkie przesuwanie suwakiem
w trzecim tylko znęcanie się
wszystkie na zmaksymalizowanym oknie przy dużej ilości klocków

"I choćbym nie wiem jak zaklinał rzeczywistość, te wykresy nie zmienią się."

[Cyfrowy Baron]

"I choćbym nie wiem jak zaklinał rzeczywistość, te wykresy nie zmienią się."

Jeżeli tworzysz program tylko na własne potrzeby, to nie masz powodu do zmartwień, ale jeżeli tworzysz dla szerszego ogółu to nie masz się z czego cieszyć, gdyż jak pokazały moje testy, na niektórych komputerach program działa tragicznie.

[GrassHoppeR]

jeżeli tworzysz dla szerszego ogółu to nie masz się z czego cieszyć, gdyż jak pokazały moje testy, na niektórych komputerach program działa tragicznie.

moje testy wśród ogółu przeczą twojej tezie. w tym przypadku tylko na jednym komputerze program działa tragicznie - Twoim. sprawdzałem na 7 maszynach, polymorphism potwierdza.

Tło odrysowywane jest tylko w zdarzeniu OnPaint, a więc tylko gdy zachodzi taka potrzeba. W praktyce tylko raz po uruchomieniu programu o ile okno zawsze pozostaje na wierzchu. Przywrócenie fragmentu tła pod przesuwanym klockiem polega na kopiowaniu tła z bufora przechowującego oryginalne nie zmienione tło. Zresztą kod już widziałeś.

no więc właśnie, robisz prawie identycznie jak ja. ja też w zdarzeniu onPaint robie Draw, ale w onMouseMove ustawiam tylko need_udp na true, zamiast jak Ty wykonywać CopyRect na PaintBox. dopiero po wywołaniu onTimer if (need_udp) wykonywany jest CopyRect bitmapy na PaintBox. uprzednio jednak następuje przywrócenie tła pod klockiem, tylko nie poprzez kopiowanie z bufora jak u Ciebie, tylko przez skasowanie tła i narysowanie klocków tylko w miejscu zamazywanego klocka na bitmapie i narysowanie na niej nowego. ustawienie need_upd następuje też przy wpisywaniu wartości położenia czy przesuwaniu scrollem.

mam nadzieję, że najnowsza wersja Cię zadowoli chociaż ma jeszcze małą niedoróbkę przy onResize.
http://grasshopper.no-ip.info/Project1.zip
(jakby link nie działał to będzie działał jutro)

[polymorphism]

Jeżeli tworzysz program tylko na własne potrzeby, to nie masz powodu do zmartwień, ale jeżeli tworzysz dla szerszego ogółu to nie masz się z czego cieszyć, gdyż jak pokazały moje testy, na niektórych komputerach program działa tragicznie.

Pytanie, na ile to wina programu, a na ile komputera? Wszystko wskazuje, że coś z Twoją maszyną jest nie tak. Wprawdzie kartę masz dość słabą, no ale procesor wystarczający, jeśli założyć, że GDI+ intensywnie z niego korzysta. Pytanie, co jest wąskim gardłem, GDI+ czy blittery GDI?

Dobrze by było, jakby ktoś zrobił testy na naprawdę słabej konfiguracji.

Jeśli chodzi o pisanie dla szerszego ogółu, to nie da się napisać oprogramowania tak, żeby był równie wydajny na wszystkich maszynach. Jest zbyt dużo czynników zewnętrznych, które na wydajność wpływają. Metoda, którą zaproponowałem, czyli frame limiting (często wykorzystywany w grach), broni się o tyle, że ma proste uzasadnienie, niezależne od maszyny, na której testujemy - mniej rysowania na jednostkę czasu, mniejsze zużycie procesora.

[Cyfrowy Baron]

Z komputerem raczej wszystko w porządku. Gry 3D działają bez zarzutu na wysokich ustawieniach, ale to DirectX. Korzystam jednak z Photoshop CS3 i nie mam absolutnie żadnych problemów, aplikacja działa szybko i sprawnie. Używam programów do konwersji filmów z AVI na MPEG2 i z DVD na AVI, konwersja przebiega niemal w stosunku 1:1. Ostatni wyłączyłem w BIOS'ie funkcję Spread Spectrum, ale nie wiem czy to coś zmieniło, teoretycznie procesor powinien nieznacznie poprawić swoje osiągi.

---

czyli frame limiting (często wykorzystywany w grach), broni się o tyle, że ma proste uzasadnienie, niezależne od maszyny, na której testujemy - mniej rysowania na jednostkę czasu, mniejsze zużycie procesora.

To nie zawsze daje dobre efekty. Przykładem może być gra GTA San Andreas, która uruchomiona w rozdzielczości 1280x1024 w 32 bitach kolorów płynnie, ale gdy włączyłem limitowanie klatek, to gra zaczęła się zacinać.

[GrassHoppeR]

sprawdziłeś ostatnią wersję z 14 stycznia?

Twój komputer może mieć problem z Draw, który na wszystkich maszynach działa błyskawicznie a u Ciebie obciąża procesor. w tamtej wersji był on używany zbyt często, stąd to przypuszczenie. wersja z 14 stycznia wykorzystuje tylko CopyRect.

[Cyfrowy Baron]

sprawdziłeś ostatnią wersję z 14 stycznia?

Sprawdziłem - działa gorzej.

---

Nie wiem o co Tobie chodzi z tym Draw, ale jeżeli o narzędzie Draw klasy TCanvas, to zauważ, że jest ono wywoływane tylko raz (mój program) po uruchomieniu programu, potem tylko gdy zachodzi konieczność odrysowania całego okna, ale to się zdarza tylko w określonych przypadkach, więc w praktyce niezmiernie rzadko.

[polymorphism]

To nie zawsze daje dobre efekty. Przykładem może być gra GTA San Andreas, która uruchomiona w rozdzielczości 1280x1024 w 32 bitach kolorów płynnie, ale gdy włączyłem limitowanie klatek, to gra zaczęła się zacinać.

Oczywiście, że nie zawsze, ale w tym przypadku wygląda na to, że zdaje egzamin (na 9 maszynach metoda daje podobne wyniki, tylko u Ciebie jest inaczej, co jest dość podejrzane).

[Cyfrowy Baron]

No nie tylko u mnie. Instalowałem tą grę wielokrotnie na słabych komputerach i włączenie limitowania klatek dla tej gry zawsze dawało gorsze efekty. Inaczej sprawa ma się na lepszych komputerach, ale tam po prostu tego spadku wydajności w animacji nie widać, gdyż sprzęt lepiej sobie radzi.

Tak czy siak, jeżeli nie masz innego pomysłu, z czego mogłoby to wynikać, to nie będę kontynuował już tego tematu.

[polymorphism]

No nie tylko u mnie. Instalowałem tą grę wielokrotnie na słabych komputerach i włączenie limitowania klatek dla tej gry zawsze dawało gorsze efekty.

Ej, ale ja pisałem o programie z klockami a nie grze.

[GrassHoppeR]

sprawdziłeś ostatnią wersję z 14 stycznia?

Sprawdziłem - działa gorzej.

wszystkie inne komputery są obciążane w zaledwie paru procentach w tamtej poprzedniej wersji, a w tej z 14.I mój pokazuje zwykle poniżej 1%. dlatego wcale nie musi to być wina programu, choć nie chcę rżnąć tutaj specjalisty, bo nie znam się na niuansach obsługi grafiki. jednak nawet wirtualna maszyna radzi z nią sobie doskonale.

Baronie, w wersji z 14.I odpowiednik Draw (kopiowanie bitmapy na cały obszar) też jest wykonywane tylko gdy zachodzi konieczność odrysowania całego okna (czyli np. onResize). reszta to kopiowanie z bitmapy na PaintBox zmienionych fragmentów, jak już wyjaśniałem wyżej. czyli praktycznych różnic między naszymi programami NIE MA. tyle różnic, że u mnie zmieniane fragmenty bitmapy są wypełnianie kolorem (GDI) i rysowane są tam klocki (za pomocą GDI+). przy Resize, MouseWheel i Scrollbar zużycie procesora skacze, jednak nawet to nie jest problemem, bo jest to kilka procent przy "znęcaniu się" nad tymi zdarzeniami w przypadku tych 2 ostatnich, a OnResize to inna sprawa i na to nic chyba nie poradzę.

[Cyfrowy Baron]

Sprawdziłem podobną sytuację w programie Photoshop czyli bitmapa i przeciąganie klocka po warstwie i tutaj wszystko działa poprawnie.

Nie mam pomysłu czym to jest spowodowane, nie będę więc kombinował.