[💬] 갸아악 자바 이 쓰레...

[익명(182.226)]

렌더 엔진 만들때 각종 이펙트 추가 문제 때문에 갈아엎고 이미지 버퍼를 임시로 생성해서 이펙트에 대한 렌더 연산을 다 한 뒤에 버퍼를 그려내는 방식으로 설계를 바꿨는데...

버퍼 생성은 내 맘대로인데 해지를 gc에 맡겨야하네.

그리고 gc는 생각한것 보다 빠릿빠릿하지 않아서 짜증...

삽질 리스트

1) 드로잉 할때마다 이미 버퍼 생성
  - 초당 120번 스크린 드로우콜 하니까 이미지 버퍼도 오브젝트 수×120 개만큼 생성됨. 메모리 관리 ㅈ망

2) 버퍼 재사용, 이미지 사이즈가 다르면 새롭게 생성
  - 좀 나아지긴 했지만 한 프레임 그릴때 최소 2번이상 이미지 프리셋이 달라져서 역시나 메모리 관리 ㅈ망

3) 가장 큰 사이즈를 기준으로 이미지 버퍼 생성후 재사용
  - 지금 생각한 방법 중 가장 나은 방법. 메모리가 그나마 관리되긴 하지만 버퍼의 사이즈가 크기에 연산량이 고정적으로 많음...

이마저도 회전연산을 할때마다 시퓨 사용량이 급증함...
Gpgpu가속을 못 받는게 문제네...

레스터 이미지 기반 렌더 엔진이 원래 효율이 구린건지, 내가 잘 못 만드는 건지...

아마 후자겠지만 ㅠㅜ

[김애독(kaidoku)]

이건 자바의 문제가 아니라 오브젝트 클래스 초기화할 때 이미지같은 리소스를 초기화를 하는 것 같은데..

[김애독(kaidoku)]

오브젝트 클래스의 인스턴스 하나하나 렌더할 때마다 리소스를 매번 초기화한다거나..

[김애독(kaidoku)]

싱글턴이던 뭐던 따로 잘 관리하는 리소스 매니저 클래스 하나 둔 다음에 오브젝트 매니저 클래스가 오브젝트 클래스들 렌더할 때 리소스 매니저를 호출하는 식으로 구현하면 코스트 많이 줄어들거야.

[글쓴이(106.102)]

이미지 리소스는 이미 매니저 클래스에서 관리함... 당연히 이미지 리소스는 게임 로딩할 때 메모리에 적재해두고 호출하는데 그것과 별개의 문제인듯

[글쓴이(106.102)]

이미지 리소스와 인스턴스를 초기화 했다면 메모리 점유문제가 아니가 드라이브 io 점유문제가 먼저 터졌을듯...

[123(210.117)]

이펙티브 자바 추천 , 자바가 메모리 해제를 gc에 맡기는 것 같지만 코드상에서 Image img = new Image(path);// img 사용

[123(210.117)]

사용 한뒤 img = null; 과 같이 처리하면 더 빨리 해제할수있었나 아니면 gc가 빨리 회수하게되나 그렇게 되서 나름 튜닝 할 수 있는 여지가 있는 걸로 암,