Daybreakin Things on Tistory

뽀샵질과 프로그래밍

daybreaker — Sun, 17 Aug 2008 00:42:10 +0900

요즘 건축 관련 공모전을 준비하느라 바쁜 형에게 가끔씩 뽀샵질에 대해 도움을 주고 있다. 그런데 이것저것 설명하다보니 포토샵으로 무언가를 하는 과정은 프로그래밍할 때의 사고 과정과 매우 유사하다는 생각이 들었다. 예를 들어, 서울시 지도를 스크린샷으로 떠서 비트맵 이미지를 갖고왔다고 할 때, 서울시 행정구역의 윤곽을 따내고 거기에 목표하는 어떤 철도나 도로를 벡터로 표시한다고 생각해보자.

윤곽을 따내는 방법으로는 lasso 툴로 선택 영역 지정하는 방법, pen 툴로 shape layer로 그려내는 방법, magic wand로 배경을 지워 투명하게 만들어 원본을 그대로 이용하는 방법 등 여러 가지가 있다. 또한 서울시의 특정 위치를 그 그림에 표시하려면(그 위치는 줌인하여 스크린샷을 떴으므로 윤곽과는 다른 스케일이다) 화면 좌표 측정 도구로 노가다로 몇 번 찍어 픽셀값을 상대좌표로 계산하는 방법이 있고, 윤곽선 따내듯 따낸 다음 적당히 확대·축소하는 방법이 있고 또 여러 방법이 있을 것이다. 또한 CS2 이상이라면, 원본 비트맵을 가지고 확대·축소를 하더라도 원본 내용을 잃지 않기 위해 smart object 기능을 이용할 수도 있다. 또한 레이어 위치를 어떻게 놓는지, 어떤 필터나 어떤 blending option, merge를 어떤 순서로 적용하는지 등 작업 방법과 순서에 따라 굉장히 다양한 조합이 나올 수 있다.

이러한 수많은 방법의 조합들 중에서 주어진 시간 내에, 주어진 목표를 달성하기 위해 가장 최선의 조합을 선택해야 한다. 예를 들어 우리 형은 건축 공모전을 준비하고 있으므로, 큰 포스터를 만들기 위해서는 고해상도 인쇄가 필수적이기 때문에 가능한 한 벡터 방식을 이용하는 것이 좋다.

마치 알고리즘 문제를 풀기 위해 어떤 종류의 알고리즘 설계를 이용할 것인지 파악하고(dynamic, greedy, back-tracking, heuristic 등등) 구현 난이도와 제한 시간을 고려하여 적당한 것을 고르는 것과 거의 같다고 볼 수 있다. 그래픽 작업 또한 결국은 이러한 최적화로 아우를 수 있을지 모르겠다. (물론 머릿속으로 미리 완성물의 이미지를 그려내는 미적 요소는 알고리즘 문제와는 다른 접근이겠지만.)

아무래도 전산을 전공하다보니 어떤 현상과 행동의 패턴을 알고리즘적으로 대입하여 보는 시각이 강해졌는데, 분명히 이렇게만으로는 설명될 수 없는 것--대표적으로 연애--도 있지만, 적어도 '일'을 하는 데 있어선 이러한 사고방식이 밑바탕에 깔리는 게 어느 분야든지 필요한 것 같다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

PuTTY 한글/영문 글꼴 분리하기

daybreaker — Fri, 11 Jul 2008 01:22:20 +0900

오늘도 삽질 하나. 날씨도 너무 덥고 텍스트큐브 코딩도 안 되고(?) 해서 PuTTY를 뜯었다.;; 그동안 오랜 숙원사업(?)이었던 한글/영문 글꼴의 완전한 분리에 성공했다.

스크린샷. 전체 사이즈 보려면 여기 클릭.

PuTTY 소스코드가 생각보다 난잡(...)해서 찾는 데 좀 시간이 걸렸지만 더위는 이열치열(?)이라는 생각으로 삽질을 해주니 마침내 어디를 고쳐야 하는지 찾을 수 있었다.

방법은 간단히 다음과 같이 window.c를 패치해주고 컴파일하면 끝.;; 보다시피 급조한 거라 글꼴 설정은 소스코드에 하드코딩되어 있다; 기준 소스는 0.60 최신 버전. 아참, 생성만 하고 소멸시키지 않는 것처럼 보이나 다른 부분에 보면 FONT_MAXNO까지 배열을 순회하며 DeleteObject를 호출해주는 부분이 있으므로 걱정 안 해도 된다.

//...
#define FONT_OEMBOLDUND 0x23
#define FONT_NONLATIN 0x30
#define FONT_MAXNO 	0x30 //0x2F

//...

static void init_fonts(int pick_width, int pick_height)
{
//...
    f(FONT_NORMAL, cfg.font.charset, fw_dontcare, FALSE);
    fonts[FONT_NONLATIN] = CreateFont (font_height, font_width, 0, 0, fw_dontcare, FALSE, FALSE, FALSE, \
        cfg.font.charset, OUT_DEFAULT_PRECIS, \
        CLIP_DEFAULT_PRECIS, FONT_QUALITY(cfg.font_quality), \
        FIXED_PITCH | FF_DONTCARE, "Dotum");

    SelectObject(hdc, fonts[FONT_NORMAL]);
    GetTextMetrics(hdc, &tm);
//...
}

void do_text_internal(Context ctx, int x, int y, wchar_t *text, int len,
              unsigned long attr, int lattr)
{
//...
    } else {
    /* And 'normal' unicode characters */
    static WCHAR *wbuf = NULL;
    static int wlen = 0;
    int i;

    if (wlen < len) {
        sfree(wbuf);
        wlen = len;
        wbuf = snewn(wlen, WCHAR);
    }

    for (i = 0; i < len; i++)
        wbuf[i] = text[i];

    /* EXTRA PATCH for non-latin font replacing... */
    SelectObject(hdc, fonts[FONT_NONLATIN]);
    text_adjust = 1;

    /* print Glyphs as they are, without Windows' Shaping*/
    general_textout(hdc, x, y - font_height * (lattr == LATTR_BOT) + text_adjust,
                &line_box, wbuf, len, IpDx, !(attr & TATTR_COMBINING));
//...
}

유니코드 렌더링 부분을 바꾼 것이기 때문에 CP949나 윈도98과 같은 환경에서는 어떻게 나오는지 모르겠지만 일단 나는 유니코드 터미널만 쓰고 있으므로 패스; =3

내가 VS2005로 컴파일한 바이너리는 KLDP를 참조하기 바란다.

추가: 앞으로 원활한 개발을 위해 공개 subversion 저장소를 생성하였다. ViewVC를 통해 살펴보려면 이 링크를 참조하기 바란다. SVN 프로토콜로 접근하려면 경로에서 view를 빼면 된다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Supreme Commander 한글입력기 구현하기

daybreaker — Fri, 27 Jun 2008 04:31:40 +0900

드디어 슈프림 커맨더(Supreme Commander)의 한글입력기를 구현했다. 이 게임은 오리지날 버전(영어권에서는 Vanilla라고 부른다)은 한글화 번역이 이루어져 출시가 되었으나 번역의 질이 굉장히 낮았고 특히 한글 채팅이 전혀 지원되지 않아 많은 유저들의 불만을 샀다. 그나마 많이 팔리지도 않아 확장팩인 Forged Alliance의 경우 아예 국내 출시조차 이루어지지 않았고, 결국 나(...)를 비롯한 매니아들은 해외 직수입 게임 전문점이나 지인을 통한 구매대행 등을 이용할 수밖에 없는 상황이다.

아무튼 그동안 한국 유저들의 오랜 갈망이었던 한글 채팅을 User Interface mod 형식으로 구현하는 데 성공했다. 슈컴이 워낙에 modding 확장성이 좋다고 알려져 있기는 했지만, 실제로 이번 기회를 통해 만져보니 정말 잘 만들었음을 알 수 있었다. 게임의 핵심적인 구동 엔진을 제외하고 나머지 다른 부분들—유닛의 움직임, 게임 시나리오, UI, 인공지능 등등—상당히 많은 부분이 lua 스크립트 언어를 통해 만들어져 있다. 게임 데이터들은 *.scd라는 파일에 들어있는데 이것은 실상 그냥 zip 압축파일이라서 누구든지 풀어볼 수 있도록 하고 있다. (별도의 복잡한 암호화 이런 거 없다.)

실제 사용 모습.

실제로 이번에 한글입력기 mod를 제작해보니 게임 내부가 어떤 로직으로 돌아가는지 거의 다 들여볼 수 있을 정도로 개방적이었다. 그만큼 게임 품질에 자신감이 있다는 뜻일 수도 있겠다.

요즘 게임 내부 스크립트 엔진용으로 많이 쓰이는 lua는 그러나 약간 실망이었다. 함수형 언어의 특징을 강하게 가지고 있는 lua는 어찌보면 ruby와도 상당히 비슷하다. 하지만 실제로는 매우 단순화된 언어로, 자료 구조라고는 오직 dictionary와 비슷한 table밖에 지원하지 않고, 비트연산자 등 다른 언어에는 당연히 있을 만한 기능들이 없는 경우가 꽤 있다. 유니코드 인코딩도 지원하지 않아 결국 utf-8 인코딩 루틴까지 직접 다 짜야했다. 대신 그 table 자료구조가 굉장히 강력하여(metatable이라는 개념을 제공한다) 함수형 언어의 특징과 결합해 이것만으로 class라는 개념을 언어에 도입하는 것이 가능할 정도이다.

오토마타 루틴은 예전에 CS322 과목 프로젝트로 Python으로 구현한 한글입력기(정확히는, 영타로 입력된 문자열을 한타로 변환하여 한글 문자열로 만들어주는..)를 lua로 그대로 포팅하였다. 둘의 문법이 비슷하여 큰 어려움은 없었고, 다만 lua에서는 table의 index가 0이 아니라 1부터 시작한다는 점 때문에 조금 헷갈리는 정도였다.

걸림돌이 되었던 부분은 오토마타의 결과물로 나온 unicode 숫자 배열을 실제의 utf-8 문자열로 변환하는 것이었는데, 이 과정에서 나머지 연산과 shift 연산이 필요하여 결국 수동으로 구현해야 했다. 특히 lua의 숫자는 무조건 double이고 라이브러리에서 필요시 unsigned long으로 바꾸는 식이기 때문에 나눗셈을 수행할 때 항상 math.floor를 해줘야 한다.

local function modulo(a, b)
    return a - math.floor(a/b) * b
end

와 같이 구현할 수 있고, right shift 연산의 경우 간단하게 2의 제곱승으로 나눠주면 된다.

혹시 필요한 분들을 위해, unicode 숫자가 순서대로 담긴 table을 입력으로 받아 utf-8로 인코딩된 문자열로 내놓는 함수를 소개한다. (테스트는 엄밀하게 해보지 않았지만 적어도 한글은 잘 나온다. =3=3)

function conv2utf8(unicode_list)
    local result = ''
    local w,x,y,z = 0,0,0,0
    local function modulo(a, b)
        return a - math.floor(a/b) * b
    end
    for i,v in ipairs(unicode_list) do
        if v ~= 0 and v ~= nil then
            if v <= 0x7F then -- same as ASCII
                result = result .. string.char(v)
            elseif v >= 0x80 and v <= 0x7FF then -- 2 bytes
                --[[
                y = (v & 0x0007C0) >> 6
                z = v & 0x00003F
                ]]--
                y = math.floor(modulo(v, 0x000800) / 64)
                z = modulo(v, 0x000040)
                result = result .. string.char(0xC0 + y, 0x80 + z)
            elseif (v >= 0x800 and v <= 0xD7FF) or (v >= 0xE000 and v <= 0xFFFF) then -- 3 bytes
                --[[
                x = (v & 0x00F000) >> 12
                y = (v & 0x000FC0) >> 6
                z = v & 0x00003F
                ]]--
                x = math.floor(modulo(v, 0x010000) / 4096)
                y = math.floor(modulo(v, 0x001000) / 64)
                z = modulo(v, 0x000040)
                result = result .. string.char(0xE0 + x, 0x80 + y, 0x80 + z)
            elseif (v >= 0x10000 and v <= 0x10FFFF) then -- 4 bytes
                --[[
                w = (v & 0x1C0000) >> 18
                x = (v & 0x03F000) >> 12
                y = (v & 0x000FC0) >> 6
                z = v & 0x00003F
                ]]--
                w = math.floor(modulo(v, 0x200000) / 262144)
                x = math.floor(modulo(v, 0x040000) / 4096)
                y = math.floor(modulo(v, 0x001000) / 64)
                z = modulo(v, 0x000040)
                result = result .. string.char(0xF0 + w, 0x80 + x, 0x80 + y, 0x80 + z)
            end
        end
    end
    return result
end

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

MacOSX Leopard에서 MacVim 사용시 언어 자동전환 문제

daybreaker — Wed, 2 Apr 2008 21:07:27 +0900

맥에서 기본으로 제공하는 콘솔용 vim이 있긴 하지만 윈도우에서도 gvim을 쓰고 있었고 Finder와 연동하기도 불편하다는 문제가 있어 대안을 찾던 중 MacVim이라는 훌륭한 포팅이 있음을 발견했다. git를 이용해 소스를 내려받아 직접 컴파일해야 되지만 그냥 써있는대로 따라하면 되기에 큰 어려움은 없었다. (단, macports와 xcode가 설치되어 있는 것이 편하다.)

문제는 MacVim을 실행 후 입력모드에 들어갈 때마다 IM 언어가 한글로 자동으로 바뀌는데 그 상태에서 키보드를 치면 영문이 입력되고 실제 한글을 입력하려면 Cmd+Space를 수 차례 눌러주어야 했다는 점이다. 뭐 소스코드도 있겠다 한 번 문제를 들여다보았더니 원인은 GetScriptManagerVariable이라는 MacOSX의 Carbon API에 문제가 있는 것으로 판명되었다.

즉, 원래 제작자의 구현이 제대로 동작한다면, 명령 모드에서는 영문 입력 상태가 유지되고 입력 모드에 들어가고 나올 때 입력모드에서 사용하던 입력 상태를 기억하여 자동으로 전환되어야 한다. (윈도우용 gvim 7.1에서는 잘 됨을 확인했다.) 나름대로 이것을 그대로 구현하기 위해 IM 상태를 저장하는 함수를 별도로 만들어보는 등 삽질을 해봤지만 OSX의 호환성 문제인지 잘 되지 않았다. 무엇보다 IM 상태를 얻거나 변경하는 방법만 3가지(Script manager로 바꾸는 방법, Class/Layout component로 바꾸는 방법, 최신 API인 TIS*+CoreFoundation 계열)나 존재해서 어떤 것을 써야 제대로 동작하는지 알 수도 없었고 각 API가 크게 다른 모습을 가지고 있어 어떤 시맨틱을 써야 좋을지도 헷갈렸다. (윈도API는 그러고보면 버전에 따라 심하게 바뀌는 일이 별로 없으니 좋은 거다.)

그래서 결론은, MacVim 소스에서 src/MacVim/gui_macvim.m 파일의 im_set_active 함수에서 호출되는 KeyScript API에 smKeyRoman을 항상 넘겨주게 하면 입력모드 들어갈 때 무조건 영문 상태로 들어가게 된다. (보통 명령 모드는 항상 영문으로 쓰니 겉으로 보기에 바뀌는 것으로 보이진 않을 것이다) 대신 한글 상태에서 입력모드를 쓰다가 Esc를 눌렀을 때 다시 입력모드로 들어가면 영문으로 되어 있으므로 한영전환을 매번 해줘야 한다는 불편이 생기지만, 한글 입력 상태로 표시되면서 영문으로 입력되는 등의 모호한 상태는 없어진다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

PNG Color Profile Removal Tool

daybreaker — Sat, 9 Feb 2008 11:00:39 +0900

이거 상당히 오래된 주제이긴 한데, 막상 필요할 때 대충 찾아서 쓰려고 해보니 윈도 전용으로 나온 것이 많아 cross platform으로 간단히 쓸 수 있도록 python 스크립트로 짰다.

주요 기능은 PNG 파일 포맷에서 색상 calibration 정보를 나타내는 필드들을 삭제해버림으로써 IE 및 Safari에서 gamma 값을 해석하지 않아 발생하는 색상 불일치 문제를 해결하는 것이다. 사용법은 python pngtool.py --help해보면 알 수 있다.

PNG Tool 스크립트 보기 (저장하려면 오른클릭)

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

학생으로서 오픈소스 활동에 참여하기

daybreaker — Mon, 12 Nov 2007 04:40:45 +0900

SPARCS Workshop 주제로 발표했던 프레젠테이션 파일입니다.
본 자료는 Creative Commons: 비영리/동일조건 변경허락 라이센스로 배포됩니다.

학생으로서 오픈소스 활동에 참여하기.pdf

스팍스 워크샵 발표자료

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

XHTML+CSS로 Drop shadow 표현하기

daybreaker — Sun, 28 Oct 2007 15:33:46 +0900

내가 알기로 이건 굉장히 오래된 고전 떡밥(?)이다. 내가 MS Office 2007에서 가장 반겼던 기능이 바로 파워포인트에서 글자에 그림자 효과를 주면 포토샵에서 한 것과 같이 부드러운 drop shadow 효과가 나타난다는 점이었고, 웹페이지를 만드는 수많은 웹디자이너와 개발자들 또한 웹에서 이것이 쉽게 된다면 얼마나 좋을까 많은 고민을 해봤을 것이다.

결론부터 말하자면 아직까지 완벽한 방법은 없다. CSS 2.1에 text-shadow라는 속성이 있어서 Safari와 Omniweb과 같은 일부 브라우저에서 지원을 하고 있기는 하지만 웹브라우저 벤더 측에서 보면 구현 자체가 난감한 면이 좀 있어서 그런지 사실상 유명무실한 속성이다. 그리고 이건 text에만 적용되는 것인지라 일반적인 block element 등에 적용할 수 없다는 단점이 있다.

리소스 업로드 화면에 적용된 drop shadow (in Firefox 2.0)

요즘 textcube.org 디자인 개선 작업을 하면서 몇몇 사람들로부터 리소스(스킨/플러그인) 업로드 화면이 너무 복잡하게 느껴진다는 보고를 받고 너저분하게 널린 도움말 주석들을 툴팁 형태로 싹 묶어버리기로 했다. 내가 Mootools를 쓰고 있었기 때문에 툴팁을 만드는 일 자체는 javascript 1줄이면 되었지만 그냥 밍숭맹숭한 박스 모양으로 만들자니 아무래도 아쉬워서-_- fade 효과도 좀 넣고 무엇보다 툴팁의 특성상 웹페이지 내용으로부터 튀어나온 모양을 주는 것이 좋을 것 같아 drop shadow를 넣기로 했다.

애초부터 IE는 포기하고 있었고(나중에 IE 전용 스타일시트에 DXImage 어쩌구 하는 필터를 걸어볼까 생각 중이기는 하다), Firefox/Safari/Opera 정도에서 테스트할 요량이었기 때문에 반투명 png를 쓴 솔루션들을 찾아보았다. 그러나 대부분은 일정한 색상의 background에만 적용할 수 있는, 불투명한 배경의 그림자 이미지를 사용하는 방법이었고, 내가 따로 반투명 png로 적용해본 결과 그림자들이 서로 겹쳐서 실패했다. 그러던 중 나를 구원(?)해준 것이 있었으니 바로 yDSF - Robust CSS Drop Shadows이다. (주소를 보고 역시 'sixapart'군..이라는 생각이..-_-)

내가 원했던 requirement를 완벽하게 갖춘 솔루션이었다. 가로/세로 크기의 자유로운 크기 조절, 반투명 png를 이용할 것, CSS hack이나 javascript를 사용하지 않고 구조적 마크업으로 표현 가능할 것. 해답은 :before, :after에 있었다. (물론 IE는 지원하지 않는다. orz) 게다가 아주 약간의 코딩 만으로 IE에 대한 fallback도 부드럽게 처리되었다.

Opera에서의 모습.

한가지 낭패스러운 점이었다면 Opera에서는 opacity가 recursively inherit되는 바람에 그림자가 툴팁의 배경으로 다 비쳐보인다는 것. 그래도 이만하면 봐줄 만 하다. -_-;

윈도우용 Safari의 경우 마우스를 왔다갔다 하면서 툴팁이 생겼다 없어졌다를 반복하게 하다보면 잔상이 남기도 하고 심한 경우는 뻑나서 죽는 경우도 있었는데, 다행히 Mac을 사용하는 다른 사람에게 부탁해서 테스트해보니 원래 Safari에서는 아무 이상 없다고 한다. (더불어 iPod touch의 Safari에서는 물음표 세번 왔다갔다하고 뻑났다고...-_-a)

아무튼 이렇게 해서 또 하나의 삽질이 끝났다.;; (뭔가 결론이 썰렁...ㅠㅠ)

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Vista의 새로운 API : 데스크톱 창 관리자

daybreaker — Sun, 26 Aug 2007 12:20:50 +0900

저번에 쓰겠다고 해놓구선 이런저런 바쁜 일이 많았던 관계로 이제서야 쓰게 되었다. Vista에서 일반 사용자들이 보기에 가장 달라진 것은 뭐니뭐니해도 화려한 Aero Glass 테마일 것이다. 이 테마를 적용하면 창 가장자리가 투명해지고 그 뒤에 있는 내용물이 부드럽게 blur되어 보이는 효과가 나타난다. 또한 창에 그림자도 생기며, 작업 표시줄 버튼에 마우스를 가져다 대거나 Alt+Tab을 누르면 각 창들의 썸네일(그것도 실시간으로 갱신되는)도 볼 수 있다. Window+Tab을 누르면 창들이 비스듬하게 늘어서는 Flip3D 효과도 있다.

이것들이 가능해진 이유는 이전의 Windows와 화면 렌더링 방식이 완전히 달라졌기 때문이다. Vista의 Aero Glass는 기본적으로 3D 모드로 동작한다. Flip3D를 써보면 알겠지만 동영상이 돌아가는 창이든 게임 화면이든 그대로 실시간으로 갱신되면서 3D로 비스듬하게 늘어서는 것을 볼 수 있다. 이것은 창 표시 자체가 3D로 이루어지고 있다는 것을 뜻하며, 그래픽카드에서 행렬 연산을 한 번 더 해주는 것이라고 볼 수 있다. (평상시의 2D 화면도 알고보면 3D 평면들을 모니터와 평행하게 둔 것이다.)

좀더 구체적으로 들어가보면, Windows XP까지는 창을 렌더링할 때 윈도우에서 WM_PAINT 메시지를 일일이 날려주었다. GDI라는 Win32 API를 통해 창에 그림을 그리면 윈도우가 이를 그래픽카드의 framebuffer에 바로 표시해주는 방식이었고, Windows 2000에서 반투명 창(Layered Window)이 소개된 후 Windows XP로 넘어오면서 테마 기능이 생겼지만 모두 CPU 연산에 의존하는 형태였다. 그러나 Vista에서는 각 프로그램이 GDI를 통해 각자의 창에 그림을 그리면 그것이 바로 화면에 뿌려지는 것이 아니라 off-screen buffer에 저장된다. Vista의 데스크톱 창 관리자(Vista의 작업관리자를 보면 dwm.exe라는 프로세스)는 이 off-screen buffer를 읽어서 3D 가속 기능을 활용해 Aero Glass 테마와 같은 비주얼 효과를 내는 것이다.

이 방식을 이용함으로써 생기는 추가적인 장점은 창을 드래그할 때 극명하게 나타난다. 뒤에 다른 창이 있을 때 앞쪽에 놓인 창을 드래그해 옮기면, 뒤에 있는 창의 가려졌던 부분을 다시 표시하기 위해 윈도우에서 WM_PAINT 메시지를 매번 날려주게 되는데, 이것이 CPU에 꽤 많은 부하를 주었다. Windows 2000 이후 소개된 Layered Window 개념으로 인해 이를 좀더 부드럽게 처리하게 되기는 했지만 뒤에 있는 창이 응답하지 않을 경우 앞에 있는 창의 잔상이 그대로 남는 현상을 볼 수 있었다. 그러나 Vista에서는 그럴 필요가 아예 없다. 창을 드래그하는 것은 화면에 표시되는 창의 위치를 바꾸는 것이므로, off-screen buffer에서 읽어들인 해당 창의 내용을 다른 위치에 렌더링하기만 하면 되는 것이다. (그 뒤에 있는 창의 내용도 buffer에 들어있으므로 그 창에게 WM_PAINT를 날려줄 필요가 없다. 따라서 매우 부드러운 창 이동이 가능하다. 이 외에도, 수직동기와 같은 3D 가속 기능들을 활용할 수 있다는 장점이 있다.)

다만, off-screen buffer들을 합성하여 화면에 출력하는 과정이 그래픽카드의 성능에 영향을 받기 때문에 일반적으로 1초에 30~60회 이상 수많은 창들의 내용을 합성해서 화면을 만들어내야 하는 Vista가 높은 사양을 요구하게 되는 것이다. (기존의 렌더링 방식에서는 애초부터 3D가 아니기 때문에 각 프로그램이 창을 갱신하는 속도가 곧 렌더링 속도였지만 데스크톱 창 관리자(DWM; Desktop Window Manager) 방식에서는 거기에 화면을 합성·렌더링하는 시간이 추가되는 것이다.)

DWM에서 제공하는 API를 여기서 자세히 설명하지는 않겠지만, 대표적으로 Vista의 탐색기나 IE와 같이 non-client area 영역이 아닌 창 내부까지 일정 영역을 투명하게 만드는 것, 화면 전체의 DWM 적용 여부를 알아내거나 설정을 바꾸는 것, 창의 핸들값을 이용해 썸네일을 얻어오는 것 등이 있다. 보다 자세한 설명은 역시 MSDN을 참조하는 것이 빠를 것이다.

사실 이러한 off-screen buffer composition 방식의 창 렌더링은 이미 매킨토시에서 구현되어 있었다. MacOSX의 부드러운 그림자, 창 최소화 효과 등이 나올 수 있는 이유가 바로 이것이었던 것이다. Vista에서는 다소 늦게 도입이 되긴 했지만 3D 카드의 성능을 십분 활용할 수 있게 된 것이다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

제3회 태터캠프 후기

daybreaker — Tue, 24 Jul 2007 00:51:02 +0900

1회는 시험기간이라 못 가봐서 잘 모르겠으나, 내 주도로 준비했던, 그러나 썰렁했던 2회 태터캠프와 달리 아주 활기찬 분위기였고, 행사 진행도 거의 1분 오차 범위 내로 딱딱 맞아들어가는 등 아주 매끄러웠다. 한 마디로 성공리에 끝마친 것이다.

태터캠프를 준비하면서 항상 가장 어려운 점은, 정규님이나 재필님도 말씀하시듯 '어떤 사람들이 얼마나' 올지 전혀 알 수 없다는 것이다. 태터툴즈가 뭔지 잘 모르는 극초보자부터 시작해서, 태터툴즈를 어떻게 하면 잘 구워삶을 수 있을까 하는 전문가나 비즈니스맨에 이르기까지 다양한 사람들이 오고, 또한 참가 신청을 받은 인원수 대비 실제 참가한 인원수 사이의 관계도 매번 다르기 때문이다.

이번 행사가 만족스러웠던 것은, 사실 앞부분의 지루한(?) 발표 세션보다는, 주제별 이야기 모임인 BoF와 개발자들의 욕구를 채워줄 테크니컬 세션을 동시에 진행했던 것이 가장 주효했던 것 같다. 또한 꼬날님의 마당발로 얻어온 던킨도너츠 후원도 저녁 식사 문제를 해결하는 데 큰 도움이 되었다. (얼마만큼의 인원이 올지 미리 알 수 없어서 무턱대고 미리 주문해놓는다거나 이런 것이 불가능했기 때문에, 차라리 'arbitrary'한 양의 던킨도너츠가 더 적절했던 것 같다.)

비용 면에서나 TNF 구성원들 시간 면에서나 당장은 힘들겠지만, 나중에는 DevDay/DevNight 혹은 CodeFest와 같이 1박 2일 단위의 프로그램을 진행하는 것도 재밌을 것 같다. 그러고보니 다음 번 KLDP CodeFest는 언제지?

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Vista의 새로운 API : TaskDialog

daybreaker — Tue, 17 Jul 2007 16:40:19 +0900

Windows Vista에서 대략 7000여개에 이르는 새로운 API 함수들이 추가되었다. 그 중에 Vista의 여러 영역에서 가장 다양하게 활용되고 있는 것이 바로 TaskDialog.

기존에는 MessageBox라는 것만 제공했었는데, 이 TaskDialog는 MessageBox의 기능을 모두 포함할 뿐만 아니라, 보다 큰 글꼴로 표현되는 Main instruction과 footer text, check box, progress bar 등 매우 다양한 형태의 UI를 제공한다. (대부분 callback 함수 형태로 대화상자가 떠 있는 동안 interaction이 가능하다.) 또한 사용자가 해야 할 작업을 선택하는 버튼들의 text를 자유로이 변경할 수 있고, 새로운 버튼들을 추가하는 것도 가능하며, Command Link라는 보다 큼직하고 눈에 잘 띄는 스타일의 버튼 모양도 제공한다.

Command Link를 사용한 Task Dialog 예제.

UAC의 작업 계속 여부를 묻는 대화상자나, 기본 내장 게임들에서 게임 종료시 할 동작을 물어보는 대화상자, 메모장 등에서 창을 닫을 때 저장하겠냐고 물어보는 대화상자 등 Vista의 거의 모든 대화상자가 TaskDialog를 사용하고 있다고 해도 과언이 아니다.

TaskDialog API는 두 가지 종류가 제공되는데, 하나는 기존의 MessageBox에 Main instruction과 Description을 구분해서 주고 Shield 아이콘 등을 추가로 사용할 수 있는 보다 간단한 TaskDialog 함수이고, 다른 하나는 위의 스크린샷과 같이 사용자 정의 Command Link, Footer 영역, Expanded 영역 등을 구조체로 미리 정의하여 넘길 수 있는 TaskDialogIndirect 함수이다.

위의 예제에서 사용된 코드는 C#으로 작성되었으며, 이곳에서 다운받을 수 있다. 이것을 통해 Win32 API를 C#과 같은 .NET Framework 환경에서 사용하려면 어떻게 해야 하는지도 알 수 있었다. (주의 : 위의 예제 코드는 x86 용으로 컴파일해야 제대로 동작한다. 내가 사용한 VS2005에서는 아직 x64용 .NET Framework가 제공되지 않아 컴파일은 되지만 API 호출시 오류가 발생한다.) VC++로 된 예제들은 구글링하면 보다 쉽게 찾을 수 있으니 생략한다.

Vista의 TaskDialog는 앞으로 기존의 MessageBox를 완전히 대체함은 물론 사용자들에게도 '확인', '취소', '예', '아니오'와 같은 단순한 메시지가 아닌, 정말로 자신이 하는 작업이 무엇인지 알 수 있는 추가 설명들을 통해 보다 확신에 찬 선택(?)을 할 수 있는 계기가 될 것이다. (이미 기능을 잘 아는 고급사용자는 main instruction만 보고, 그렇지 않은 사람은 세부 정보 보기를 선택해서 찬찬히 읽어볼 수도 있을 것이다) 내가 비록 PHP, Python 등의 스크립트 언어를 주로 다루고 있지만서도, 한때 Windows API에 심취했었던만큼, 상당히 반가운 기능이다.

다음 포스트에서는 Vista의 달라진 창 표현방식인 Desktop Window Manager에 대해 적어볼까 한다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.