Font Glyph Data 압축 알고리즘
글쓴이: sanggi.choi / 작성시간: 목, 2009/02/19 - 6:26오후
안녕하세요.
현재 중국어에 대해서 Font Engine 최적화 작업 있습니다.
영어권과는 달리 중국어 Font Glyph Data의 Size는 엄청 큽니다. 보통 1500byte 이상입니다.
개발환경이 Embedded다 보니 File I/O 속도가 너무 늦습니다.
해서 Glyph Data Drawing 시간의 80%정도가 File I/O에 할애가 됩니다.
또한 가용 Cache Size가 적으면 Cache 효율성이 낮아 File I/O가 많이 발생을 하여, Font Drawing 성능에 문제가 발생 됩니다.
이런 상황을 해결 하고자 생각한 것이 우선 File I/O를 최소화하기 위해 Cache 공간을 늘리는 것이 있으나,
이것은 상황에 따른 제약 사항이 너무 많아 고려 대상에서 제외 했습니다.
다른 방법은 Glyph Data를 압축해서 Cache에 적용하는 것입니다.
제약 사항은 File I/O보다 압축에 드는 비용이 작아야 적용 가능합니다.
하지만, 전체 Drawing 시간의 80%를 file I/O에서 소비되고 있다면, 한번 적용해 볼만 하다 판단하였습니다.
결론은 Glyph Data를 압축하는 효율적인 알고리즘에 문의 합니다.
어떤 알고리즘을 적용하여야 효율적일까요?
위와 같은 내용에 대해서 아시는 분 있으면 이에 대한 사항을 알려 주시면 감사하겠습니다.
Forums:
사용될 환경에서
사용될 환경에서 중국어 문자의 사용 빈도를 조사해 보셨는지 궁금합니다.
한글의 경우, 제가 가진 자료에 의하면 상위 200자 정도가 차지하는 비중이 80%, 상위 400자정도가 차지하는 비중이 95%정도였습니다.
말씀만으로는 어느 정도까지 열악한 상황인지 모르겠습니다만, 최근의 일반적인 상황에서는 사용빈도 통계자료를 조사해 보면, 충분히 적당한 캐쉬알고리즘을 만들어 내실 수 있을 거라고 생각합니다.
답변 감사 합니다.
사용 환경은 Windows Mobile이며, 중국어 사용 빈도를 측정해 보지는 않았습니다.(사실 제가 중국어를 잘 몰라서...)
예를 들어 화면이 Text로 가득 하고, 이때 약 2000자 정도를 사용했습니다.
물론 2000자 중에는 반복 출력되는 글자도 있습니다.
이때 Cache를 256KB를 사용했을 경우에는 LRU 를 사용 했을 경우에 Drawing 속도의 80%정도가
File I/O를 하는데 소비 되었습니다.
아직 빈도수를 측정해 보지는 않았지만, 이와 같은 상황에서 빈도수를 측정이 효과가 있을까요?
빈도 측정이 어떤
빈도 측정이 어떤 효과가 있는게 아니라, 상황을 분석하고 해결책을 얻기 위한 적절한 정보를 줍니다. 빈도 분포의 형태를 살펴보고서 효율적인 구현방법을 연구해 보는 것이 좋다고 생각합니다.
지금 상황에서는 한자의 경우에도 한글과 비슷한 패턴의 분포 형태를 취할 것으로 예상되므로 굳이 빈도 분포를 측정하지 않고도, 현재 구현에서 캐쉬 크기를 점차 늘려가면서 File I/O 비율의 변화 추이를 살펴보면, 적당한 캐쉬 크기를 구할 수 있을 겁니다. 이렇게 구한 캐쉬 크기가 256KB에 비해서 넘사벽이 아닐 경우에 한해서 글립 압축이라던지 하는 등등의 최적화를 고려해 볼 수 있을 것입니다.
방향이 다를수도있지만..
그맆데이터를 처리하시기보다. 벡터데이터를 뽑아서 보관/처리하고
마지막 rasterize 할때만 그리면 어떨까요..
LISP 사용자모임
http://cafe.naver.com/lisper
방송기술 개발업체
http://playhouseinc.co.kr
답변 감사 드립니다.
제안해 주신 방법도 고려해 보았으나, 적용하기는 어렵다 판단하였습니다.
보통 중국어의 Glyph Data는 큰게 1500Byte 정도이며, 보통 300~400 byte 정도 되며
래스터 전의 Path Data는 Glyph Data의 약 2배정도 증가 합니다.
Path Data를 Cache하면 Rendering하는 비용이 향상되겠지만,
Cache 측면에서는 기본 Cache Data의 Size가 Glyph Data 보다 크므로, Cache할 수 있는 량이 작게 됩니다.
이로 인해 Glyph Data의 Cache보다 Cache Swap이 증가 되어 File I/O가 횟수가 증가 됩니다.
위와 같은 이유로 Rendering하는데 조금 손해보더라도, Cache Size를 적게 해서 File I/O를 적게 하는 방법을 선택하였습니다.
댓글 달기