인간이 반응이 빠르다고 느끼는데 필요한 시간은 프로세서의 시간에 비해서는 매우 길죠.. 그러므로 소프트웨어와 UI 그래픽을 설계하고 개발할 때 잘 최적화하여 만들면 대부분의 경우 즉각 반응하도록 할 수 있다고 생각합니다. 하지만 현실은.. 무거운 OS와 처리 메카니즘의 문제, 무자비한 그래픽 리소스 덕분에 늘어나는 처리 시간, 촉박한 개발 일정, UI 반응 속도가 느린 것은 버그가 아니므로 개발팀의 평가에는 빠진다는 점.. 등등 때문에 우리가 만나는 디바이스의 반응 속도는 항상 열받게 하는 것입니다..-_-;;
입력즉시 반응하므로...
즉, Interrupt gate를 거치고 대기하고 OS에서 해당 인터럽트에 대한 처리를 해서 입력기로
넘기고 하는 일련의 과정이 필요없으니까 그렇겠죠.
대부분의 OS는 범용으로 만들어지다보니 여러가지 상황에서 동작하도록 되어있겠지만 입력 자체가
한정되어있고 해당 입력이 어떠한 버튼인지가 확실하다면 무슨 게이트건 대기건 필요없이 일단
OS에서 바로 반응을 할 수 있도록 하면되고 즉각적인 반응을 할 수 있도록 하면 되지 않을까요?
그 다음에는 blkstorm과 비슷한 의견입니다. :-)
------------------------------
좋은 하루 되세요.
두가지 이유일 것같습니다.
첫번째는, 그래픽 하드웨어 성능입니다.
(CPU에서 부동소수점 연산이 하드웨어로 지원된다는 가정하에) 그래픽 하드웨어의 성능이
얼만큼 받혀주면 웬만한 특수효과들도 무난하게 보여줄 수 있습니다. GPU 구성에 따라 다르겠지만,
몇몇 그래픽 라이브러리들은 특수효과를 위해서 부동소수점 연산을 많이 요구하는데, 이게 소프트웨어
에뮬레이션으로 돌아가면 느려지는 것으로 알고 있습니다. (예: FlashLite. 휴대전화/PMP 등에서 사용중)
실제로 플레이스테이션 1의 경우에는 CPU자체의 성능은 그렇게 좋지 않았던 걸로 기억합니다. GPU가
특수효과를 가능하게 했던거죠.
두번째는, 연속키 입력처리를 이용한 착시효과입니다.
약간 기초적인 것부터 이야기한다면, TV리모컨의 경우에는, 음량 +/-, 채널 +/- 키가 연속적으로
들어오면, 즉 사용자가 "누르고 있는 상태"라면 키 코드를 몇개씩 무시합니다. 예를 들어, 5초동안 누를때,
리모컨에서 신호가 50번 나간다면 TV의 소프트웨어에서 50번중에 10번정도의 키 입력만 처리하고 나머지는
무시하는거죠. 이게 왜 필요하냐하면, 음량이나 채널의 경우에는 너무 빨리 넘어가면 사용자가 제어를 할 수
없게 됩니다. 특히 반응속도가 느린 어르신들이 갑자기 음량이 커진다, 또는 채널이 너무 빨리 넘어간다라는
클레임을 거는 경우가 있었습니다.
이런 "연속키" 입력의 패턴을 읽어서, 스크롤이나 이동할 때 이동간격을 동적으로 바꾸는거죠. 연속키가
들어올 경우에는 스크롤/이동 간격을 10에서 15내지 20으로 올리는 식으로 바꾸면, 누르고 있는 동안에는
빠르게 넘어가는 것처럼 보이다가, 버튼을 떼는 순간에 멈추게 하는거죠.
단순히 '스펙이
단순히 '스펙이 좋으니까' 아닌가요?
정답.
정답. -_-)=b
--->
데비안 & 우분투로 대동단결!
--->
데비안 & 우분투로 대동단결!
그렇게 단순하게
그렇게 단순하게 생각할 문제는 아닙니다.
삼성 제트가 아이폰보다 사양도 좋은데 케발리는 이유는 설명하지 못하지요..
http://www.ipodobserver.com/ipo/article/An_iPhone_Performance_Secret_LLVM/
http://garrys-brain.blogspot.com/2007/07/llvm-low-level-virtual-machine.html
요거 추천입니다.
소프웨어를 잘 만들었기때문입니다..
인간이 반응이 빠르다고 느끼는데 필요한 시간은 프로세서의 시간에 비해서는 매우 길죠.. 그러므로 소프트웨어와 UI 그래픽을 설계하고 개발할 때 잘 최적화하여 만들면 대부분의 경우 즉각 반응하도록 할 수 있다고 생각합니다. 하지만 현실은.. 무거운 OS와 처리 메카니즘의 문제, 무자비한 그래픽 리소스 덕분에 늘어나는 처리 시간, 촉박한 개발 일정, UI 반응 속도가 느린 것은 버그가 아니므로 개발팀의 평가에는 빠진다는 점.. 등등 때문에 우리가 만나는 디바이스의 반응 속도는 항상 열받게 하는 것입니다..-_-;;
http://blog.dreamwiz.com/shjii
UI가 느린 것은 보통
UI가 느린 것은 보통 그래픽 연산을 소프트웨어로 하기 때문입니다.
PSP는 GPU가 내장되어 있고 아이폰 역시 코어 그래픽스 프레임워크가 GPU를 활용하도록 설계되었죠.
반면 예를 들어서 국산 모바일 디바이스에서 UI용으로 많이 쓰는 플래시 라이트는 아무리 모바일에 최적화되었다고 해도 소프트웨어 기반이라 일정 수준 이상의 성능을 내기 어렵습니다.
(3.1부터는 OpenVG를 지원한다고 하는군요)
----
http://www.planetmono.org
----
http://www.planetmono.org
그렇군요.
그것 말고도 UI 자체가 일종의 VM기반에서 돌아가는 형태인 것도
한몫할 것 같은데요.
이를테면 전체 메시지를 삭제하는 명령을 내리면,
아무리 억세스속도가 느린 플레쉬 메모리라도..
가끔은 너무 느리지 않는가 한는 생각이 들때도 있더군요.
There is no spoon. Neo from the Matrix 1999.
There is no spoon. Neo from the Matrix 1999.
단순한
단순한 추측...
입력즉시 반응하므로...
즉, Interrupt gate를 거치고 대기하고 OS에서 해당 인터럽트에 대한 처리를 해서 입력기로
넘기고 하는 일련의 과정이 필요없으니까 그렇겠죠.
대부분의 OS는 범용으로 만들어지다보니 여러가지 상황에서 동작하도록 되어있겠지만 입력 자체가
한정되어있고 해당 입력이 어떠한 버튼인지가 확실하다면 무슨 게이트건 대기건 필요없이 일단
OS에서 바로 반응을 할 수 있도록 하면되고 즉각적인 반응을 할 수 있도록 하면 되지 않을까요?
그 다음에는 blkstorm과 비슷한 의견입니다. :-)
------------------------------
좋은 하루 되세요.
------------------------------
좋은 하루 되세요.
실제로는 느리지만
실제로는 느리지만 느리지 않게 사람에게 보이게 하는 기법들도 많지 않나요?
그런걸 알고 디자인을 하느냐 모르고 하느냐의 차이가 엄청나다고 생각합니다.