GLUT (nie rozumiem teorii)

Jak to jest? Którego okna dotyczą kolejne komendy(funkcje)? Chciałbym się pobawić, ale mam wątpliwość, bo gdzieś napisano, że dotyczą aktywnego okna i nie bardzo rozumiem co to oznacza. Jeśli aktywnego w sensie takim, że jest aktywne dla użytkownika (czyli ten typowy sens, tak jak moja przeglądarka jest teraz aktywnym oknem) to nie rozumiem jednej sprawy. Co jeśli ja sprawdzę numer okna aktywnego. Okaże się, że aktywne okno to to na którym coś teraz będę robił. Ja to zaczne robić i przed zakończeniem prac użytkownik mi zmieni aktywne okno. Na którym oknie wykonają nie pozostałe operacje?

Może to trochę dziwne pytanie, ale nie napiszę nic z GLUTa jeśli się tego nie dowiem, bo nie wiem po prostu, które okno, w którym momencie będę modyfikował :)

Dobra już chyba wiem o co chodzi.

chyba nie wiem

Czy jakaś funkcja np. od timera może zmienić mi aktywne okno niespodziewanie, czyli w momencie kiedy coś na nim robiłem gdzieś indziej? Czy to nie możliwe? Ja w ogóle nie rozumiem tej maszyny stanów. Jest logiczna kiedy nie weźmiemy pod uwagę np. wątków, czy też jakiś funkcji, które mogą się "same" wywoływać np. glutDisplayFunc(). Czy jeśli coś typu wątek zmieni mi aktywne okno to będzie ono zmienione dla całej aplikacji?

Sorki za takie prymitywne pytanie, ale po prostu tego nie kumam, bo to jeśli jest jakaś "pamięć na stany przydzielona globalnie" to trzeba ją współdzielić i co jeśli jeden zmienia a drugi z tego korzystał? Jak to jest? Np. w bazach danych, czy też w WinAPI można zablokować dostęp na jakiś czas do danej pamięci (w direct też coś takiego było). W WinAPI to się robiło podczas odnoszenia się do rzeczy globalnych (szczegółów nie znam, bo tego nie miałem okazji robić, ale wiem że coś takeigo jest).

Pomóżcie :)!!

ty chesz rysowac na jakims oknie, ktore moze zostac zamkniete czy jak? a przypadkiem jak juz okno nie istnieje to nie wylacza sie rysowania i usuwa RenderingContext i deviceContext czy jakos tak co ty w ogole myslisz bo ja nic nie kumam co napsiales

Dobra. Pisałeś kiedyś program, który współdzielił jakiś obszar pamięci z innym programem, lub prościej że w jednym programie dwa wątki mogły korzystać z tego samego obszaru pamięci w tym samym czasie i mogły jednocześnie zapisywać i odczytywać? Jeśli nie to przedstawie ci przykładowy problem na bazie danych np. w mysql bo to najprostszy przypadek wg mnie.

Wyobraź sobie, że cała operacja (dowolna) składa się z kilku zapytań i wszystkie te zapytania są konieczne aby baza miała sens. Np. ktoś coś kupił to kilkoma zapytaniami zmniejszamy zawartość stanu magazynowego itp. Co jeśli podczas wykonywania tych kilku zapytań ktoś inny zapyta o tą samą tabelę lub niedajboże również zacznie ją modyfikować? Jest to możliwe. Jeden lub drugi (albo oba) zbiór zapytań może zostać źle wykonany, bo drugie zacząły się wykonywać w połowie pierwszego, a to oznacza że jeszcze nie wszystkie tabele są spójne i uaktualnione. Drugie zapytanie więc nie ma aktualnych tabel. W takim przypadku wystąpią błędy. Dlatego w mysql są mechanizmy które pozwalają by jakiś zbiór zapytań zablokował innym zapytaniom dostęp do tabel na jakiś czas i tamte zapytania będą czekać.

Rozumiesz w czym problem?

Teraz wyobraź sobie dwa wątki. Jeden chce mi zmodyfikować rozmiar pierwszego okna a drugi drugiego. I uruchamiają się prawie w tym samym momencie (prawie). Pierwszy ustawia sobie okno aktywne na to co go interesuje, a drugi zrobi to samo zaraz za nim. Ponieważ wg mojego zrozumienia teorii jest to maszyna stanów mająca jedno okno aktywne w danym momencie to to oznacza że drugi wątek zmienił mi to okno na swoje. W takim przypadku pierwszy wątek wykona operacje na nieswoim oknie bo maszyna stanów ma inne dane niż on wpisał na początku. Czy tak jest? Czy trzeba się przed tym zabezpieczyć pisząc programy wielowątkowe? Czy muszę jakoś ręcznie opracować mechanizm zabezpieczania przed takimi sytuacjami?

Jeśli jeszcze nie rozumie mnie nikt to przedstawiam 'tabelkę'. Po lewej to jest stan wykonywania się pierwszego wątku, po drugiej drugiego.

glutSetWindow(1)
......jakieś instrukcje. Procesor
zaczyna wykonywać operacje
drugiego wątku
glutSetWindow(2)
.................
...procesor przerzuca
sie na wątek pierwszy
zmieniam rozmiar okna

itd itd.
Jaki będzie wynik tej operacji? Czy wątek pierwszy zmodyfikował mi pierwsze okno czy drugie? Chciał pierwsze, ale zanim to zrobił drugi wątek zmienił mu okno i wykonał swoje operacje.

A gdzie wyczytałeś, że te dane są WSPÓŁDZIELONE? :D

Okna rysuje się w callbacku ustawianym przez glutDisplayFunc() - callback jest wywoływany zawsze dla jednego konkretnego okna. Nie ma funkcji, która może zmienić okno przypisane do callbacka w czasie wykonywania callbacka. Wielowątkowe wykonywanie 2 callbacków dla 2 różnych okien nie powoduje problemów (GLUT wie, który wątek operuje na którym oknie). Można też zrobić jeden callback odrysowującyc więcej niż jedno okno, ale trzeba uważać, żeby nie korzystał z jakiś własnych współdzielonych danych (np. jakiejś zmiennej globalnej). Natomiast może korzystać z poleceń GL i GLUTa.

Ponadto ustawienia zmieniane przez glutSetWindow() są trzymane PER WĄTEK, a nie GLOBALNIE.
Każdy wątek ma osobne okno bieżące. O ile tylko polecenia glutXXX wywołujesz w tym samym wątku, który ustawił bieżące okno, to jest gwarancja, że będą one operowały cały czas na tym samym oknie, niezależnie od tego, co robią inne wątki.

Jeydny problem mógłbyś mieć, gdybyś po wywołaniu setCurrentWindow odpalił nowy wątek. Podobnie gdyby callback odpalił nowy wątek. Ten nowy wątek nie miałby ustawionego bieżącego okna. Musiałbyś więc ponowić wywołanie setCurrentWindow w tym nowym wątku.

No i dokładnie to chciałem wyjaśnić. Najważniejsze dla mnie było właśnie czy wątki posiadają własne aktywne okna itd itd. Bo teoretycznie nie musiałoby tak być i wtedy problem by był.

Poza tym rysowanie to zupełnie inna bajka. Przecież nie koniecznie muszę rysować prawda? Tworzę wątek który coś tam sobie robi z oknami, np. ustawia aktywne, sprawdza rozmiar okna, jeśli pasuje do jakiegoś wzorca to wypisuje coś na ekranie konsoli i taka w kółko pętla. Tymczasem pod klawiaturę mam podpiętą funkcję, która po wczytaniu literki Y musi mi ustawić jakieś inne okno, poprzez zmianę rozmiarów. W takim przypadku ja problem widzę, ale jeśli wątki mają niezależną maszynę stanu to problemu nie ma.

Wszystko przez to, że w WinAPI posługujesz się uchwytami okien, więc w sumie ten problem nie istnieje (chyba że skorzystałbym z SelectObject() ale to zupełnie inna sprawa).

ps. Tego nie musiałem wyczytać, bo tego nigdzie nie znalazłem, ale nie znalazłem również informacji że nie są współdzielone :). Znalazłem natomiast informacje o maszynie stanu i to ona mnie trochę zmieszała, bo nie napisano czy ta maszyna jest lokalna dla wątków, lokalna dla funkcji callback, czy może jest globalna.