Mam wieloplatformową bazę kodową (iOS i Android), która używa standardowej konfiguracji renderowania do tekstury. Każda ramka (po zainicjowaniu), następująca sekwencja zdarzeń:Renderowanie do tekstury i synchronizacja
- glBindFramebuffer z bufora ramki z przystawką struktura barw
- renderowania kilka rzeczy
- *
- glBindFramebuffer domyślnego bufora ramki (0 w Androidzie zazwyczaj 2 iOS)
- glBindTexture tekstury, które było przyłączenie kolor pierwszego bufora ramki
- przy użyciu tego związany tekstury
Na iOS i niektórych urządzeniach z systemem Android (w tym na emulatorze) działa to poprawnie i zgodnie z oczekiwaniami. Na innych urządzeniach (obecnie siedzących przed wersją Samsung Galaxy Note 4.0.4), renderowanie drugiej fazy, które wykorzystuje teksturę, wygląda "skocznie". Inne animacje nadal działają z szybkością 60 fps na tym samym ekranie, co "bity"; mój wniosek jest taki, że zmiany w strukturze docelowej nie zawsze są widoczne w drugim przebiegu renderowania.
Aby przetestować tę teorię, wstawię glFinish() w kroku oznaczonym * powyżej. Na wszystkich urządzeniach ma to teraz prawidłowe działanie. Co ciekawe, glFlush() NIE naprawia problemu. Ale glFinish() jest drogi i nie widziałem żadnej dokumentacji sugerującej, że powinno to być konieczne.
Oto moje pytanie: co należy zrobić po zakończeniu renderowania do tekstury, aby upewnić się, że ostatnio rysowana tekstura jest dostępna w późniejszych wersjach renderowania?
Nie brzmi to jak rozsądne zachowanie OpenGL. Nie jestem ekspertem od ES, ale jestem pewien, że ES (przynajmniej według specyfikacji) nie zmienia tego podstawowego zachowania synchronizacji. Nie można polegać na niczym, jeśli to nie wytrzyma, na przykład polegając na zakończeniu zapisywania buforów przed renderowaniem. Nie ma innych jawnych mechanizmów synchronizacji dla tych operacji, więc kolejka poleceń musi być poprawnie synchronizowana sekwencyjnie. –
I przyjmuję, że nikt inny tego nie zauważył? Oczywiście, może być oczywiście urządzenie/build, ale nie jest to zabawne. – addaon