Dnia 28.11.2012 kenobi <p...@g...com> napisał/a:
[...]
> (np w danej konkretnej sytuacji mam tablice[][] z pixelami ale zeby
> to wyswietlic musze to opakowac w image pozniej wyswietlic, poniewaz
> robie to w kazdej ramce to po prostu tworze nowy image za kazdym razem
> nie przejmujac sie starym i nie zwalniajac go)

Można używać tego samego Image (albo dwóch wykorzystywanych na
przemian jeśli potrzebujesz doublebuffera) - będzie po prostu
szybciej, każde tworzenie obiektu jak i późniejsze jego zwalnianie
przez GC zajmuje czas, jeśli można tego uniknąć, to się po prostu
unika :D

> podobnie jest z przekazywaniem i robieniem najrozmaitrzej sieczki
> wrapperow, powiedzmy ze
> mam jeden oryginalny kawalek danych z pixelami, czy
> pakujac to w najrozmaitsze obiekty po drodze zeby
> cos zrobic wyswietlic, zapisac na dysk, itp
> mam gwarancje ze dane te nie beda topornie kopiowane
> tylko ze to wszystko beda lekkie operacje?
>
> tj czy jawie mozna zaufac ze nmie przejmujac sie
> problemem zwalniania i problemem przekazywania i wrappowania poradzi
> sobie on a tj nie wykona jakichs
> masywnych duplikatow (albo jakichs innych pokrewnych
> zarzynek). mam nadzieje ze moje pytanie jest
> zrozumiale, a jesli nie i jawa moze wykonac taką zarzynkę to
> prosilbym najlepiej o konkretny przyklad takiej zarzyny ze strony jawy. tnx

W niektórych przypadkach konieczne jest "ręczne" zwalnianie obiektów,
bo samo "wyjście poza zasięg" nie wystarcza, tak jest na przykład w
Swingowym JFrame, utworzenie obiektu może byc powiązane z wewnętrznym
utworzeniem nowego wątku i utworzeniem wielu wewnętrznych
"eventhandlerów" i pomimo wyjścia odpowiedniej zmiennej z zasięgu
obiekt jest zachowywany, bo jest po prostu na ekranie (niezależnie od
tego czy jest akurat "visible"). Generalnie można ufać wbudowanemu GC
ale trzeba mieć świadomość, że część API korzysta z wielowątkowości
Javy (i część nie jest "thread safe") - wszystko jest w dokumentacji.