http://cafe.naver.com/mssilverlight/3021에 니르워프님이 결정적인 정보와 함께 실험 설계의 문제점도 짚어주셨어요.

[이슈1] 상이한 측정 결과

제 컴에서 공도님의 소스를 받아서 실행을 해본바, 이슈1일때 공도님의 블로그에서 보여 지는 그런식의 결과는 없다라는 것입니다. MaxFramerate의 설정과 무관하게, 주어진 인터벌로 나옴.

16ms의 인터벌을 주면, MaxFramerate의 설정에 따라 MaxFramerate만큼으로 제한되는 프레임 레이트를 출력하는것이 공도님의 블로그에 올려져 있으나 저의 측정에서는 모두 16ms에 해당하는 프레임 레이트로 나옴.

소스 분석해본바, 공도님의 방법은 MaxFramerate과의 연관성이 파악하는 방법이 아니어보이네요.

[이슈2]

적절치 않는 계산 방법을 사용하고 있습니다.

하나의 인터벌이 지나면(완료되면) 한개의 카운팅을 하는 방법을 취하고 있고, 인터벌이 완료되었을때 할당된 시간이 초과되었는지를 점검하는데, 이 방법으로 하면, 할당 시간보다 조금더 지나칩니다. 인터벌이 클수록 지나치는 크기는 더 커질수 있습니다.

인터벌이 50이라면 49이상의 오차도 나올 수 있습니다.

일단 이슈2를 해결하기 위해 코드를 다음과 같이 약간 수정했고요,

private readonly int LoopCount = 100;

void onTime(object sender, EventArgs e)

{

    if (++_count == LoopCount)

    {

        TimeSpan elapsed = DateTime.Now - _beginTime;

        StopStoryboard();

        StopTimer();

        outputText.Text = string.Format("{0} FPS", ((LoopCount / elapsed.TotalMilliseconds) * 1000).ToString("0.00"));

    }

}

작동 완구와 소스는 아래... 또는 여기에서 테스트. http://shiverlight.net/Sample/GameLoopTest/




문제는 결과에 큰 차이가 없다는 점이에요.

이렇게 되면 짐작해 볼 수 있는 건 현재 운영체제의 버전이나 개별 상황에 따라 실버라이트 런타임이 제공하는 타이머의 안정도나 정확도가 떨어질 수 있느냐의 문제인데요, 각자 테스트 조건을 다르게 해서 특이할 만한 사항이 있으면 알려주시길 바래요.

제 조건은 아래와 같아요.

OS : Vista Enterprise SP1
CPU : Core2Duo 1.4GHz
GPU : Intel GMA950
Browser : IE7, FF3

OS와 브라우저, CPU, GPU외에 영향을 줄 만한 요소는 없을 거라고 생각하고요. 램이야 남을 만큼 남아 있으니^^;;

어쨌거나, 좋은 조언을 해주신 니르워프님께 감사드려요 :)

Posted by gongdo

Submit comment.

꽤 유명한 말이죠. "We love to hate Microsoft."
마이크로소프트는 야심차게 Vista를 출시했지만 많은 유저들의 반응은 굉장히 싸늘했죠.
무겁다, 느리다, 충돌난다, 프로그램이 안돌아간다... 이게 초기 Vista에 대한 대부분의 의견이었고 지금에 와서는 Vista를 접해보지 않은 사람들의 뇌리에 박힐 정도가 되어버렸죠.

뭐 솔직히 Vista의 하드웨어 요구 사항이 높긴 높지만 지금에 와서는 출시되는 대부분의 PC가 Vista를 쾌적하게 돌리기에 무리가 없고 프로그램 호환성도 굉장히 개선이 많이 되었죠. 물론 그놈의 ActiveX와 관련된 수많은 UAC 컨펌 문제가 있긴 하지만요. 명확한 보안을 위해서 어쩔 수 없는 조치였다고 생각하는데 이 얘긴 길어질 것 같으니 패스.

각설하고, 마이크로소프트에서 The Mojave Experiment 프로그램을 통해 Vista를 사용하지 않는 유저(대부분 XP사용)를 대상으로 새 윈도 버전인 '모하비'가 나왔다고 하면서 사람들에게 시연하고 설문조사를 했다고 하네요. 그런데 이 '모하비'는 실은 완전히 Vista이고 단지 패키지만 보여주면서 새 버전이라고 했다는 군요. 어쨌든 결과가 매우 흥미로워서 옮겨볼까 해요.

Mojave 실험 결과
주요 결과
- 응답자의 94%가 데모를 하기 전에 매긴 Vista의 점수보다 Mojave에게 더 많은 점수를 주었다.
- 응답자의 0%가 데모를 하기 전에 매긴 Vista의 점수보다 Mojave에게 더 낮은 점수를 주었다.

140* 응답자에 대한 설문에 의하면
- 데모를 하기 전에 Vista가 받은 평균 점수는 10점 만점의 4.4점.
- 데모를 한 후에 Mojave가 받은 평균 점수는 10점 만점의 8.5점.
(* 비디오에 녹화된 120명과 녹화하지 않은 20명을 포함)

많은 사람들이 높은 점수를 주었을 뿐만 아니라 더 가지고 놀고 싶어 했다.

사용자의 유형*:
- 84% XP 사용자
- 22% Apple OS 사용자
- 14% 다른 윈도 사용자
- 1% 리눅스 사용자
(*복수 응답 가능)

사용된 하드웨어 스펙:
HP Pavilion DV2000 with 2GB RAM
- Intel Core Duo Processor T2300(1.66GHz, FSB 667MHz)
- Intel Graphics Media Accelerator 950

언뜻보면 이 실험은 약간 공정하지 않은 걸로 보여요. 왜냐면 사용자들이 충분히 오랜시간 동안 직접 사용한 것 같지는 않고 각자의 용도에 맞게 직접 사용한 것 같지도 않거든요. 아마 실제로 써본다면 이런저런 불만이 또 생길 수도 있겠죠.

그러나 사람들이 전반적으로 Vista에 대해 갖는 '부당한' 선입견을 입증하는 데에는 확실한 증거가 될 수 있는 것 같아요. 특히 Vista가 느리다, 잘 충돌한다, 보안에 문제가 있다 라는 의견에 대해서 말이죠.

저도 1년 전 쯤 Vista를 처음 써본 이래로 쭈욱 Vista만 쓰고 있는 사용자로서 Vista가 XP에 비해서 훌륭한 OS이고 보다 사용자 친화적인 OS라는 건 절대적으로 찬성해요. 제 생각에도 Vista는 XP에 대해 부당한 평가를 받아왔다고 보거든요.

여튼, 많은 사람들이 단지 소문이나 선입견 내지는 고정관념만으로 판단하는 경우가 많은 것 같아요. 또한 각종 하드웨어 커뮤니티를 다녀보면 제목에서도 얘기했듯이, 단순히 MS라는 글자가 들어가기만 하면 까는 사람도 꽤 많고요.

이 실험의 핵심은 단지 선입견 때문에 Vista를(내지는 마이크로소프트를) 싫어하는 사람들에 대한 이미지 개선이라고 할 수 있겠죠. 발상이 꽤 신선했고 나름 효과도 있을 것 같네요. 다만 국내에는 여전히 별 효과가 없지 않을까 하는 생각이...^^;

모하비 프로젝트는 계속해서 진행된다고 하는데 또 재밌는 결과를 볼 수 있을지 기대돼요.

Posted by gongdo

Submit comment.

  1. Favicon of http://steelleg.tistory.com BlogIcon 무쇠다리 2008.08.27 19:05  comment URL  Edit/Remove  Submit comment.

    ms 저 실험을 통해 무엇을 알았는지 궁금하네요.
    그저 비스타의 나쁜 평판은 선입관일 뿐이다라고 한다면, MS 그 해결책을 찾을 수 없을 것 같네요.
    그런 선입관을 만들어낸 장본인이 MS 이고, 한번 만들어진 선입관은 잘 고쳐지지않지요.
    MS가 충격을 받아야 마땅할 결과라고 봅니다.
    열심히 해도 기존의 선입관이 장벽이 된다면, 선입관을 없애는 노력을 보다 더 많이 해야겠지요.
    제가 보기엔 그러기엔 MS 가 너무 배가 부른게 아닌가 싶습니다.
    선입관으로 피해를 본다고 칭얼대지 말고, 기술은 더 허접한데 더 좋은 인상을 주는 기업을 배울 필요가 있지 않을까요.
    저도 MS 개발자인데, 그런 점은 좀 아쉽습니다.ㅎㅎ

    • Favicon of http://gongdosoft.com BlogIcon 공도 2008.08.28 16:41  comment URL  Modify/Remove

      그런데... 맨날 농담같이 하는 얘기지만 비스타가 미적지근한 최대의 원인은 XP가 그다지 나쁘지 않은 OS라는데에 있다고 생각해요. 요컨대 아무리 비스타가 이미지가 나쁘고 욕을 드립다 먹어도 XP에 비해 압도적으로 편하고 빠르고 안전하다면 사람들은 궁시렁 거리면서도 옮겨가겠지만, 현실적으로 XP도 충분히 괜찮은 OS라고 사람들은 생각하고 있는 것 같아요.

      예를 들어 98에서 XP로의 이전은(2000은 논외) 그 때에도 XP가 느리다 무겁다 사양 높다 지금과 별반 다를 바 없는 소릴 많이 들었지만 98과 XP와의 차이점은 유사한 인터페이스임에도 불구하고 소위 말하는 '넘사벽'이었으니까요.

      사용자들의 현실적인 욕구를 XP가 충족시키지 못하는 시점이 바로 XP의 수명이 다하는 날이 되겠죠.
      빨리 그날이 오길 바라지만 SP3까지 나온 마당에 98에 비해서는 장수할 것 같다는 생각도 들어요. ^^;

  2. Favicon of http://lifiwork.tistory.com BlogIcon Lifiwork 2008.11.18 04:14 신고  comment URL  Edit/Remove  Submit comment.

    98과 XP 로 비교를 한다면. 중간에 끼어있던 win-me 도 넣어야할꺼에요.
    아마 98 과 me 와 xp 의 관계처럼
    xp 와 vista 와 win7 의 관계가 되지 않을까 싶습니다.
    사실 지금 vista를 써보면 당시 윈미를 쓰던 기억과 비슷하니까요.
    터치스크린에 완전히 새로운개념을 도입하는 윈7은 다시 xp와 같은 지위를 차지할꺼라고 봅니다.
    비스타는 솔직히 좀 아니에요 ^^;

    • Favicon of http://gongdosoft.com BlogIcon 공도 2008.11.18 06:57  comment URL  Modify/Remove

      제 생각에 비스타는 절대로 me랑 비교될 만큼 허접한 OS는 아니라고 봐요. 물론 높은 하드웨어 요구사항이나 최적화에 실패한 건 사실이지만요. 제 경험으로는 me의 경우엔 98에 비교하여 네트웍을 제외한 장점이 전혀 없었던 반면 비스타는 게임을 하지 않는 이상 XP보다 훨씬 좋다고 생각하거든요.

      그러나 마케팅적인 문제로 비스타가 me랑 비슷해진 건 사실인 것 같아요. 아직 제대로 쓰이기도 전에 윈도우즈7이 나온다고 하니...

      터치 인터페이스는 초기에는 단순히 재미거리 정도로 시작하겠고 대중들에게 OS를 선택하는 기준으로 인식되기 까지는 시간이 꽤 필요할거라고 생각해요. 아직은 터치 인터페이스의 장점이 극대화된 애플리케이션이 거의 없으니까요.

  3. Favicon of http://lifiwork.tistory.com BlogIcon Lifiwork 2008.11.18 12:05 신고  comment URL  Edit/Remove  Submit comment.

    인터페이스가 나오지도 않았는데 어플리케이션을 먼저 만들수는 없겠죠.
    다만, 이번에 터치리스 기술이 오픈소스로 공개되니까, 관련된 파급효과들이 많이 나올꺼라고 생각합니다.
    윈미가 사실 허접했다기 보다는 안정화 시키기가 무섭게 XP가 출시된것도 있다고 생각하구요.
    비스타 자체도 사실 MS에서는 윈7으로 가는 과도기 형태로 출시한게 아닌가요?
    뭐 논쟁을 하자는건 아니고 그냥 들렀다가 댓글남겼어요.
    구글 RSS 에서 추천 블로그길래 ㅎㅎ; 구독할려고 ㅋ

    • Favicon of http://gongdosoft.com BlogIcon 공도 2008.11.18 14:03  comment URL  Modify/Remove

      그렇죠^^
      터치 인터페이스는 정말 기대하고 있긴 하지만 과연 지금의 애플리케이션들이 터치에 맞도록 전환되는데 얼마나 걸릴지도 약간 걸리기도 하고요.
      시기나 마케팅으로 봐서는 비스타가 윈me취급 당하는 건 어쩔 수 없을 것 같아요. 그러고보니 비스타도 SP2가 개발중이죠...(머엉...) 이건 뭐 SP2 나오자마자 7나오는게 아닐지;;

  4. Favicon of http://lifiwork.tistory.com BlogIcon Lifiwork 2008.11.18 23:50 신고  comment URL  Edit/Remove  Submit comment.

    개인적인 생각으로는 아마도.. 생각보다 기존의 애플리케이션이 터치로 포팅되는데 들어가는 시간은 생각보다 매우 짧을껍니다. 왜냐하면,
    이미 현존하는 많은 모바일 기기들이 터치 혹은 멀티 터치 디바이스가 많아져서 지금 이미 기술이 축적되고 있거든요.
    그래서 제 생각에는 아마 윈7 출시와 동시에 상상보다 많은 어플리케이션이 쏟아져 나올꺼 같아요.
    기다렸다는 듯이..

    마치 애플 아이팟터치의 기술을 이젠 모니터에서 할 수 있다고 생각하면 되니까요.
    제약도 줄어들고 ㅎㅎ;

길버트님의 "[엉뚱한실험4] Transform이 적용된 객체에서 MouseEventArgs GetPosition 결과값 비교"를 보다가 문득 더 궁금해진 것이 있어서 추가로 테스트 해봤어요.

테스트 결과는 RenderTransform이 적용된 개체의 GetPosition(자기자신)의 위치는 어떤 변형이 있더라도 원래 자신의 위치에 대한 상대적인 값이 나온다...였는데요, 그렇다면 GetPosition(부모) 또는 실버라이트 영역 전체에 대한 위치를 얻는 GetPosition(Null)을 하면 어떻게 될까요?

네, 결과는 당연하게도 자기 자신을 대상으로 한 GetPosition은 자신의 원래 영역에 관련된 값이 나오지만 GetPosition에 다른 개체를 넣으면 해당 개체로부터 이벤트가 발생된 지점까지의 절대적인 위치가 나오네요. 참고로 갈색 Rectangle이 테스트 대상이고 Cyan(밝은 하늘색) 테두리는 Rectangle을 포함하고 있는 부모 Canvas의 위치를 나타내고 있어요.

각 부모 Canvas의 좌표는 위에서부터,
None : (50, 50)
ScaleTransform : (50, 150)
RotateTransform : (50, 250)
TranslateTransform : (50, 350)
SkewTransform : (50, 450)
이고 위의 스크린샷에서 마우스의 위치는 각각 Rectangle의 오른쪽 아래 모서리를 기준으로 했어요.

그래서 이 테스트가 말하고 있는게 뭐냐고요? 별거 없어요. RenderTransform을 먹인 개체에 대한 MouseEventArgs.GetPosition을 사용할 때 주의하라는 거죠.

흔히 어떤 개체를 드래그&드랍할 때 MouseMove 이벤트에서 마우스가 이동된 좌표를 얻기 위해 e.GetPosition(sender as UIElement)라고 쓸 수 있는데요, 만약 이렇게 했을 때 개체에 RenderTransform가 적용되어 있다면 원치 않은 결과를 얻을 수 있겠죠. 드래그&드랍이나 클릭된 지점에 어떤 효과를 줄 때에는 가급적 e.GetPosition(null)을 사용하여 절대적인 경로를 기준으로 하는 것이 좋을거에요.

반대로, 어떤 Canvas에 RenderTransform이 적용되어 있고 그 Canvas 내부에서만 움직이거나 표현되는 개체에 대한 상대적인 좌표 계산은 e.GetPosition(해당 Canvas)로 하는 것이 적절하겠죠.

테스트는 다음 링크에서 해볼 수 있고 프로젝트 파일도 첨부했으니 관심 있으신 분은 받아서 해보시길.
테스트 : http://gongdo.oranc.co.kr/Silverlight/Samples/TransformTest2/TestPage.html
다운로드 :

Posted by gongdo

Submit comment.

  1. Favicon of http://www.uxkorea.net BlogIcon 준서아빠 2007.12.20 01:05  comment URL  Edit/Remove  Submit comment.

    오른쪽 위의 유령에 마우스를 올려보니... 크헉~

    • Favicon of http://gongdo.tistory.com BlogIcon 공도 2007.12.20 01:50  comment URL  Modify/Remove

      와~ 발견하셨군요!
      이스터 에그랍시고 넣어뒀는데 ㅋㅋㅋ
      준서아부지께는 나중에 소정의 상품을 드리겠습니다. :D

  2. Favicon of https://gilverlight.tistory.com BlogIcon 길버트 2007.12.20 14:21 신고  comment URL  Edit/Remove  Submit comment.

    앗, 아깝다!!