Patryk Bajer == Bayger

Przez parę dni używałem NetBeansów do programowania projektu H-RT. Nie były to może sesje bardzo obfite w nowy kod czy długie, ale pozwoliły mi nieco bliżej przyjrzeć się funkcjonowaniu tego środowiska. Mam zatem kilka nowych przemyśleń – tym razem gorzkich.

Podpowiadacz
Pierwsza sprawa to wspominany już w poprzednim poście “intellisense”, czyli auto-podpowiedzi. Okazuje się, że jest on mniej użyteczny niż sądziłem. Owszem, tuż po przebudowaniu projektu i odczekaniu paru sekund działa, ale… no właśnie. Z dotąd nieznanych mi powodów mechanizm ten potrafi się w danym pliku po prostu zdezaktywować. Wyświetla wtedy w podpowiedzi smutny napis: “no suggestions”. Druga sprawa to wykorzystanie szablonów. Podpowiadacz najwyraźniej nie radzi sobie np. z szablonami dotyczącymi inteligentych wskaźników (ang. smart pointer). Owszem, potrafi podpowiedzieć to co jest w samym szablonie, ale już operator -> ukazuje nam jego bezradność (“no suggestions”). Trochę to smutne, gdyż w nowoczesnym programie w C++ dość często używa się jakiejś formy smart-pointerów. Kolejna sprawa to prędkość działania podpowiedzi. Zazwyczaj, niestety, trzeba chwilkę odczekać zanim cokolwiek się pojawi (powiedzmy koło 1 sek) po naciśnięciu Ctl+spacja. Nie doszedłem również do końca kiedy podpowiedź się pojawia automatycznie, a kiedy trzeba podpowiadacza przywołać ręcznie. Wszystkie te cechy wpływają na wydajność programowania oraz na stopień irytacji programującego. Oczywiście negatywnie.

Edytor kodu
Druga sprawa to dość dziwne czasem zachowanie samego edytora kodu. Ustawienia ilości spacji reprezentujących znak tabulacji po prostu nie działa. Co bym nie ustawił to IDE zawsze wetnie mi taby na 8 znaków. Próbowałem wszystkich możliwych dostępnych opcji w konfiguracji – bez skutku. Owszem, od czasu do czasu szanowny edytor dobrze sformatuje kod, ale takie momenty zdarzają się niezwykle rzadko. Jedynym wyjściem z tej sytuacji jest zamiana tabów na spacje.

Będąc jeszcze przy edytorze warto wspomnieć o jeszcze jednym błędzie. Jeśli cokolwiek zmienimy w konfiguracji kolorów podświetlania składni edytor po zamknięciu okna konfiguracyjnego powinien odświeżyć aktualny widok. No więc… czasem o tym zapomina. Mały błąd, a może wprowadzić zamęt (‘Przecież to przed momentem zmieniałem!’).

Prędkość działania
W pierwszym poście na temat NB6 pochwaliłem je za większą prędkość działania niż jego konkurent – Eclipse CDT. Prawdę mówiąc nie jestem teraz o tym tak do końca przekonany. Czasem środowisko ma chwile słabości i potrafi się zablokować na 2-3 sekundy. W ogóle czasem mam wrażenie, że wszystko działa ociężale. A nie mam słabego procesora, bo trudno słabym nazwać Core 2 Duo 2.4GHz.

Rozwój
Ostatnią sprawą, która mnie martwi jest fakt, że rozwój wsparcia dla C++ w projekcie NetBeans chyba zamarł. I to dobre 3 miesiące temu. Przynajmniej tak wygląda to z punktu widzenia CVS’a. Nie wiem co o tym wszystkim myśleć. Czy warto nadal pracować w tym środowisku, skoro może ono pozostać w aktualnym punkcie rozwoju (mówię oczywiście o C++). Czas pewnie pokaże. Mam jednak nadzieję, że rozwój części C++ NetBeansów pójdzie do przodu, bo środowisko jest całkiem sympatyczne.

Jako że wreszcie zeszła mi grypowa temperatura postanowiłem nieco czasu poświęcić na poszukiwanie darmowej, wieloplatformowej alternatywy dla Visual C++ 2005. Miałem już zabierać się za Eclipse CDT, gdy przypomniałem sobie o tym, że parę tygodni temu zainstalowałem nową wersję NetBeansów (czyli wersja 6) specjalnie przeznaczoną dla C++. Był to krótki epizod. Nie testowałem tego środowiska pod kątem czegoś więcej niż standardowe HelloWorld. Tak czy inaczej same NetBeansy wywarły na mnie pozytywne wrażenie. Dlatego też postanowiłem do nich wrócić.

Środowisko wydaje mi się nieco bardziej spójne od Eclipsa. Działa również nieco od swojego konkurenta szybciej. Zaskakujące jest to, że IDE pierwotnie przeznaczone dla języka Java okazało się dobrze przystosowane do C++. Podświetlanie składni działa poprawnie, choć jest nieco uboższe od tego z tandemu VC++2005/VisualAssist. Idzie się jednak do niego przyzwyczaić. Dość pozytywnie zaskoczył mnie mechanizm podpowiedzi, czyli odpowiednik microsoftowego Intellisensa. Działa on dość sprawnie. Znowu, nie jest to aż tak zaawansowane narzędzie jak podpowiedzi VisualAssista, ale jest wystarczające do większości zastosowań. Szkoda tylko, że podpowiedzi nie działają jeszcze zbyt dobrze dla szablonów. Kolejną rzeczą jest integracja w pakiecie obsługi CVS oraz, co dla mnie ważniejsze, Subversion. Tutaj należy się wielki plus dla developerów NetBeansów. Wreszcie jakieś IDE ma w podstawowej wersji zainstalowaną wtyczkę do Subversion, która działa out-of-the-box. Jeśli chodzi o obsługę projektów C++ to programiści NetBeans postawili na kompatybilność z narzędziem make. Innymi słowy, nasz projekt możemy zbudować poza środowiskiem używając po prostu starego dobrego make’a.
Do testów NetBeansów posłużył mi projekt H-RayTracer. H-RT jest raytracerem napisanym w C++, który w chwili obecnej służy mi do badań przy mojej pracy magisterskiej. Do tej pory rozwijałem go w Visual Studio 2005 z wtyczką VisualAssist. Ponieważ chciałem, aby sam projekt był wieloplatformowy postanowiłem go przeportować na Linuksa. I udało się, właśnie dzięki NetBeansom. Po paru godzinach zmagań i nauki nowego środowiska udało mi się zbudować w pełni działający raytracer pod Debianem.
Tak więc nie pozostaje mi nic innego jak zachęcić wszystkich programistów C++ do spróbowania NetBeansów 6 dla C++. Wydaje mi się, że warto.

NetBeans 6.0 for C/C++

Pisanie aplikacji, które są i wydajne i przyjazne użytkownikowi wymaga użycia wielowątkowości. Wiadomo, jeśli będziemy coś liczyć na wątku odpowiedzialnym za rysowanie interfejsu to tego rysowania w tym czasie nie będzie i otrzymamy aplikację, która nie odpowiada. Tak jest np. w przypadku paska menu Start. Wystarczy kliknąć na na “Moje bieżące dokumenty” czy spróbować wyświetlić menu “Połącz z”. Musimy wtedy swoje odczekać. Gdy do tego jeszcze któryś z plików (z bieżących dokumentów) jest poza naszym komputerem to gwarantowane czekanie kilkadziesiąt sekund. W tym czasie pasek startu jest zawieszony w obowiązkach. Tak czy inaczej podczas jednej z takich sytuacji zacząłem się zastanawiać jaki to wielki koszt czasowy jest związany z blokowaniem za pomocą CRITICAL_SECTION. Oto malutki program, który mi posłużył do testów:

	CRITICAL_SECTION cs;
	InitializeCriticalSection(&cs);
	int testValue = 0;
	LARGE_INTEGER lintStart, lintEnd;
	LARGE_INTEGER lintFreq;
	QueryPerformanceFrequency(&lintFreq);
	QueryPerformanceCounter(&lintStart);
	int i;
	for(i=0; i<1000000; i++)
	{
		EnterCriticalSection(&cs);
		testValue = i;
		LeaveCriticalSection(&cs);
	}
	QueryPerformanceCounter(&lintEnd);
	std::cout << boost::format("CPU Freq: %1% Hz")
		% lintFreq.QuadPart << std::endl;
	std::cout << boost::format("Cycles per enter/leave: %1%")
		% (double(lintEnd.QuadPart-lintStart.QuadPart)
		/ double(i)) << std::endl;

No i cóż się okazało? Na moim Core 2 Duo koszt zablokowania sekcji krytycznej i jej zwolnienia to całe 90-100 cykli zegara CPU. Jeśli metodyka pomiaru była prawidłowa to jest to bardzo mały narzut. Wydaje się zatem, że zysk dla użytkownika programu, który nie musi czekać aż łaskawie program skończy jakąś operację, jest o wiele większy niż koszt. Czy zatem programiści od Windows Explorera nie mogliby tego zastosować, aby żyło się nieco łatwiej z ich systemem?

Obiecałem sobie już dawno, że napiszę o pewnej książce, którą mam przyjemność posiadać. Mowa jest o anglojęzycznej pozycji pt. “Physically Based Rendering: From Theory to Implementation”. Autorami są Matt Pharr oraz Greg Humphreys. Jest to najlepsza książka o renderingu, jaką miałem okazję trzymać w rękach. Piszę w rękach (a nie ręce), gdyż książka ma ponad 1000 stron (kredowy papier), a całość jest umieszczona w twardej oprawie. Nie jest to zatem zbyt “poręczna” pozycja. Na tym jednak jej wady się kończą.

O czym dokładnie jest książka?

Autorzy opisują wszelkie aspekty teoretyczne oraz praktyczne renderingu opartego na zasadach fizycznych. Książkę można uznać za nowoczesny podręcznik grafiki komputerowej. Jest napisana w bardzo przemyślany sposób, gdyż nawet osoba nie orientująca się w temacie, aczkolwiek posiadająca pewną wiedzę matematyczną, będzie mogła zrozumieć większość materiału. Materiału jest tak dużo, że ciężko jest go przedstawić ciągłym tekstem, więc posłużę się bardzo skrótową listą zagadnień. Oto ona:

• przekształcenia geometryczne (wektory, macierze, układy współrzędnych)
• reprezentacja brył w przestrzeni wraz z metodami ich obróbki (np. jak wyliczyć przecięcie kuli z linią)
• metody przyspieszania obliczeń, reprezentacja przestrzenna geometrii
• podstawowe zagadnienia związane z kolorem oraz radiometrią
• model kamery
• teoria próbkowania i rekonstrukcji obrazu z próbek (np. filtry)
• reprezentacja obrazu (dane o pikselach, zakres tonalny, HDR)
• lokalne modele odbicia światła (B*DF) oraz definicja materiałów
• tekstury oraz sposoby ich przetwarzania (mapowanie, filtrowanie, generacja)
• interakcja światła z otoczeniem (emisja, pochłanianie)
• źródła światła (światła punktowe, powierzchniowe i wiele innych)
• całkowanie numeryczne wielkości radiometrycznych metodą Monte-Carlo w grafice (2 dość rozbudowane rozdziały)
• metody renderingu opartego na LTE (light transport equation) czyli ray tracing, path tracing, dwukierunkowy path tracing

Książkę zatem można traktować jako kompendium wiedzy z zakresu ogólnie rozumianego raytracingu. Podejście fizyczne zapewnia ogromny realizm tworzonych obrazów za pomocą algorytmów opisanych w książce. Lektura tego wydawnictwa skłoniła mnie do próby napisania własnego silnika renderującego opartego na raytracingu (o czym niebawem). Mogę tylko napisać, że książka zawiera wszystko co jest potrzebne do tego niełatwego zadania. Warto wspomnieć, że autorzy obrali świetną formę książki, gdyż w czasie opisywania zagadnień równolegle tworzą w języku C++ pełnowartościowy raytracer. Do tego wszystkiego otrzymujemy płytę CD, która zawiera pełny kod renderera PBRT (tworzonego w książce) wraz z materiałami dodatkowymi (np. grafiki). Możemy zatem sami “pomajstrować na żywo” z kodem raytracera, np. rozszerzając go o dodatkowe możliwości. Warto wspomnieć także, że kod jest wieloplatformowy.

Na koniec

Chciałbym wszystkim, którym tematyka grafiki komputerowej nie jest obca, gorąco polecić opisywaną książkę. Gdyby nie to, że jest dostępna jedynie w języku angielskim byłaby doskonałym podręcznikiem akademickim na przedmiot “Grafika komputerowa” na naszych uczelniach. Żywię nadzieję, że kiedyś jedno z polskich wydawnictw pokusi się o tłumaczenie tej pozycji, aby zastąpić już wysłużonego Foleya (choć być może lepszym zamiennikiem byłaby książką Petera Shirleya o podstawach grafiki). Mam również nadzieję, że będzie troszkę tańsza niż oryginał (około 250 PLN) albo chociaż wydana w ten sam rewelacyjny sposób.

PS. Książkę można nabyć na amazon.com, ale taniej można ją kupić na amazon.co.uk – stan na 14 marca 2007.

Tak naprawdę ten wpis miał mieć całkiem inny tytuł, ale koniec końców zdecydowałem się na tę nieco tajemniczą sentencję. Zatem, o co chodzi? O kolory. A konkretnie o kolory edytora, w którym piszemy kod źródłowy. Okazuje się, że ustawienia kolorystyczne edytora mają niebagatelny wpływ na to, jak się nam pracuje (zmęczenie, efektywność, etc).

Monitor to prawie żarówka

Zapewne wielu z Was siedzi przed monitorem po kilka godzin dziennie. Gapimy się w tą szklaną taflę nieustannie, a nasze oczy muszą się do tego dostosować. Jak wiadomo, monitor to nic innego jak źródło światła. Można go spokojnie przyrównać do dobrze wszystkim znanej żarówki elektrycznej bądź świetlówki kompaktowej. Próbowaliście kiedyś patrzeć na świetlówkę przez kilka godzin? Nikomu tego nie polecam, niemniej wpatrywanie się w monitor komputerowy można porównać z gapieniem się w takie sztuczne źródło światła. Oczywiście energia emitowana przez monitor jest rozłożona na całej jego powierzchni, a nie jak w przypadku żarówki niemal punktowo. Fakt jednak pozostaje taki, że nasze oczy odbierają to niezbyt korzystnie.

Słabe światło otoczenia

Po pierwsze należy ustalić w jakich warunkach pracujemy. W znakomitej większości przypadków jest to za słabo oświetlone pomieszczenie biurowe. W takich warunkach nasz monitor wydaje się wyspą światła na tle bladego pomieszczenia. Jeśli zatem możemy to zapalmy porządne światło, aby nieco zmniejszyć kontrast między ekranem monitora a resztą pomieszczenia. Zapewniam, że nasze oczy będą mniej zmęczone. Jeśli jednak z jakiś powodów nie możemy lub nie chcemy doświetlić pomieszczenia gdzie pracujemy mam inne rozwiązanie.

Kolory edytora

Można pójść w odwrotnym kierunku – zmniejszyć światło wydobywające się z ekranu monitora. Ponieważ bardzo dużo czasu spędzam pracując w Visual Studio 2005 zmieniłem schemat kolorystyczny w tym narzędziu. Oto jak wygląda ekran edytora kodu w moim VS (w pomniejszeniu):

Jak widać tło jest prawie całkiem czarne, a litery są jasne i kolorowe. Z moich obserwacji wynika, że przy tak skonfigurowanym edytorze kodu można dłużej pracować. Moje oczy i mózg mniej się męczą. Można oczywiście pójść jeszcze dalej i zmienić całkowicie schemat kolorystyczny całego systemu operacyjnego. Należy jednak pamiętać, że zbyt ciemne i monotonne barwy mogą nas doprowadzić do senności.

Odpowiednia czcionka

Na koniec jeszcze tylko wspomnę o jednej rzeczy. O czcionce edytora. W moim przypadku jest to darmowy font o nazwie Inconsolata, którego używam z dwóch powodów. Po pierwsze system zawsze używa antialiasingu przy tej czcionce. Po drugie, według mnie świetnie wygląda. Polecam rozmiar 14 – wtedy czcionka wygląda fantastycznie. Pewnie wielu z Was myśli, że ustawiając rozmiar na “aż 14″ marnuję cenną przestrzeń edytora. Według mnie lepiej mieć większy rozmiar tekstu i mniej się męczyć podczas jego czytania, niż mieć czcionkę 10 punktową i 50 linijek kodu do ogarnięcia. Do takiego wniosku doszedłem dopiero niedawno. Znowu zauważyłem, że pracuje mi się z tak duża czcionką znacznie lepiej. Być może się starzeję…
Tak to wygląda w pełnym rozmiarze (wycinek):

Uwaga: na zrzutach ekranu widać kod C++ z rozszerzonym podświetlaniem składni. Korzystam z dodatku Visual Assist X, o którym pewnie niebawem napiszę.

Do pobrania:
moje ustawienia kolorów VS 2005
inna, bardziej kolorowa wersja ustawień (imho lepsiejsza).