Wayland vs. X11 입력 지연 논의의 구체적 수치

 (mort.coffee)
2P by GN⁺ | ★ favorite | 댓글 1개
  • Fedora Workstation 41·GNOME 47 환경에서 커서 입력 지연을 240 FPS 슬로모션으로 촬영해 Wayland와 X11을 비교함
  • 마우스가 움직이기 시작한 프레임부터 커서가 새 위치에 보인 프레임까지 세는 방식으로, Wayland 16회와 X11 16회의 프레임 지연을 기록함
  • GNOME X11은 평균 4프레임·16.7ms·2.4 화면 리프레시, GNOME Wayland는 평균 5.5625프레임·23.2ms·3.3 화면 리프레시로 측정됨
  • 해당 시스템에서는 Wayland가 X11보다 평균 약 6.5ms 더 높은 커서 지연을 보였고, 차이는 거의 화면 리프레시 1회에 가까웠음
  • 결과는 GNOME/AMD 조합의 커서 지연 차이만 보여주며, 게임이나 일반 그래픽 애플리케이션에서 Wayland 입력 지연이 더 높다는 증거는 아님

왜 측정했나

  • 한 Linux 사용자가 Wayland 입력 지연 불만을 다룬 Wayland Cursor Lag: Just give me a break already...를 계기로, 주관적 체감 대신 구체적 수치를 얻기 위한 실험을 진행함
  • Wayland를 전반적으로 만족하며 쓰고 있지만, X11보다 커서 지연이 더 있는 것 같다는 인상이 실험의 출발점이었음
  • 기존 글의 90 FPS 휴대폰 카메라는 한 화면 리프레시 수준의 차이를 판단하기에 충분하지 않다고 보고, 240 FPS 촬영 모드를 사용함

측정 방식

  • 휴대폰 카메라로 화면, 책상, 마우스 커서, 마우스, 손을 함께 촬영하면서 손가락으로 마우스를 반복적으로 튕김
  • GNOME Wayland 세션에서 16회 촬영한 뒤, GNOME X11 세션으로 로그인해 같은 방식으로 16회 촬영함
  • 촬영한 비디오는 ffmpeg -i <input file> %04d.jpg 명령으로 JPEG 프레임으로 변환함
  • 프레임 지연은 다음 기준으로 셈
    • 마우스가 움직이는 것이 보이는 첫 프레임부터 계산 시작
    • 커서가 새 위치에서 명확히 움직인 것이 보이는 첫 프레임까지 계산
    • 시작 프레임과 종료 프레임을 모두 포함함
    • 예를 들어 1045프레임에서 마우스가 움직이고 1047프레임에서 커서가 움직이면 3프레임 지연으로 기록함

테스트 환경

  • 실험 하드웨어와 소프트웨어는 다음과 같음
    • 배포판: Fedora Workstation 41
    • GNOME 버전: 47
    • CPU: AMD Ryzen 9 5950X
    • GPU: AMD Radeon RX 7900XT
    • 모니터: Gigabyte M32U, 4K IPS, 144.99Hz, DPI 스케일링 없음
    • 마우스: Logitech G502 Lightspeed
    • 카메라: iPhone 15 Pro, 슬로모션 240 FPS

측정상 제약

  • 240 FPS도 144Hz 화면에서는 화면 리프레시당 카메라 프레임이 2개 미만이라 무작위 변동이 생김
  • 픽셀이 즉시 전환되지 않아, 커서가 새 위치에서 아주 희미하게 보이기 시작하는 애매한 프레임이 존재함
  • 커서가 완전히 밝아지지 않았더라도 새 위치에서 명확히 보이면 커서가 움직인 것으로 계산함
  • iPhone 영상에 일부 중복 프레임이 포함됐으며, 원인은 알 수 없음
    • 중복 프레임은 한 프레임만큼의 시간이 지난 것으로 보고 정상 프레임처럼 계산함
  • 이런 요인들은 결과에 불확실성을 만들지만, Wayland와 X11에 동일하게 작용할 것으로 보고 충분한 데이터가 있으면 평균화될 것으로 봄
  • GNOME 외의 Wayland 컴포지터와 AMD 외 GPU 드라이버는 테스트하지 않아, 다른 조합에서는 결과가 달라질 수 있음

측정 결과

  • GNOME X11의 16회 측정값은 5, 4, 3, 4, 5, 4, 6, 5, 1, 4, 4, 4, 3, 4, 4, 4 프레임임
    • 평균: 4프레임
    • 지연 시간: 16.7ms
    • 화면 리프레시: 2.4회
  • GNOME Wayland의 16회 측정값은 6, 5, 6, 5, 5, 6, 6, 4, 8, 6, 5, 5, 5, 6, 5, 6 프레임임
    • 평균: 5.5625프레임
    • 지연 시간: 23.2ms
    • 화면 리프레시: 3.3회
  • 이 시스템에서는 Wayland가 X11보다 평균 약 6.5ms 더 높은 커서 지연을 보임
  • 통계적으로 유의한지 제대로 분석할 전문성은 없지만, 측정값상으로는 명확하고 일관된 차이가 있는 것처럼 보임
  • 차이는 거의 화면 리프레시 1회에 가까우며, 이것이 우연인지는 알 수 없음

결론과 해석 범위

  • 이 실험은 특정 하드웨어에서 X11과 Wayland 사이에 입력 지연 차이가 있고, 일부 사용자가 알아챌 수 있을 만큼 클 수 있음을 보여줌
  • 문제의 범위와 크기를 명확히 파악하려면 더 다양한 하드웨어와 화면 주사율에서 추가 테스트가 필요함
  • 차이의 크기는 사용 중인 컴포지터와 화면 주사율 같은 요인에 따라 달라질 수 있음
  • 추가 실험은 시간이 많이 들어 직접 진행하지 않을 가능성이 큼
  • 이 테스트는 Wayland가 X11보다 전반적으로 입력 지연이 높다는 것을 보여주지 않음
    • 특히 게임에서 Wayland 입력 지연이 더 높다는 증거가 아님
    • 추가 지연이 커서 전용일 가능성이 있음
    • 커서는 일반 그래픽 애플리케이션과 매우 다르게 처리되는 것으로 이해하고 있음
    • Wayland가 게임에서 X11보다 더 높은 입력 지연을 보이는지는 별도 테스트가 필요함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 훌륭한 접근임. 사람들이 더 실험적으로 확인할 수 있는 일을 너무 자주 추측으로 때우는 듯함. 과학적 방법을 배운 뒤로는 “실험을 설계해보자” 쪽에 늘 끌렸음
    Wayland에 왜 추가 지연이 생기는지는 모르겠지만, X11이 처음 나왔던 시절 컴퓨터 커뮤니티에 있었던 입장에서는 초창기부터 화면 지연에 대한 불평이 끊이지 않았다고 말할 수 있음. 커서 반응이든 xterm 스크롤이든 마찬가지였음
    “워크스테이션”이 등장했을 때는 마우스만 위한 별도 표시 하드웨어가 있는 경우도 있었고, 프레임 안에 마우스를 렌더링하는 지연을 줄이기 위한 장치였음. 악명 높은 XOR 특허도 있었고: https://patents.google.com/patent/US4197590
    이런 불평 덕분에 키보드/마우스 입력에서 화면 반영까지 이어지는 코드 경로는 계속 “더 빠르게, 더 낮은 지연으로” 만들 방법을 검토받았음. Wayland는 X11에 비해 상대적으로 “새로운” 것이어서 그만큼 오래 검증받지는 못했지만, 사람들이 고쳐나가길 기대함

    • 디스플레이 장치, 보통 GPU 일부에는 여전히 마우스만을 위한 명시적 표시 하드웨어가 있고, 지금은 커서 평면(cursor plane) 형태로 존재함. 이후에는 이를 더 일반화한 오버레이 평면도 생겼음
      평면은 나머지 화면을 다시 그리지 않고도 갱신하거나 위치를 바꿀 수 있음. 일반 화면 이미지는 기본 평면에 있고, 커서 이동은 새 평면 위치를 커밋하는 일에 가까움
      여기서 쓰인 Wayland 서버인 GNOME Mutter가 추가하는 입력 지연은 아마 입력 샘플링과 커밋 타이밍 전략 문제일 가능성이 큼. 서버마다 전략과 우선순위가 달라 장단점이 생김
      Wayland는 프로토콜이라 일반 커서 위치 지정 과정에는 관여하지 않음. 따라서 이 문제는 전적으로 디스플레이 서버 내부 구현과 최적화 영역임. 프로토콜 수준에서는 클라이언트가 커서 이미지를 설정하게 하고, 클라이언트에게 커서 위치를 알려주는 정도만 일어남
    • 예전에는 XFree86와 Xorg가 SIGIO 핸들러 안에서 포인터를 직접 갱신했음. 하지만 지금은 아주 오래된 이야기이고, 요즘은 이 영역에서 Wayland와 Xorg가 크게 다를 거라고 기대하진 않음
      기억상으로 Xorg에서 glamour가 등장하면서 상황이 나빠지기 시작했음. 커서 렌더링 경로가 시그널 핸들러에서 실행해도 안전하지 않게 되자, OpenGL 기반이면 당연히 그럴 수밖에 없고, 지연이 더 나빠졌음
      예전에는 Linux 머신이 스래싱 중이어도 마우스 포인터는 계속 반응했고, 커널이 멈췄는지 아닌지 가늠하는 믿을 만한 지표였음. 포인터가 너무 일찍 반응하지 않으면 IDE/PATA 호스트에서 hdparm으로 unmask irq를 켜야 하는 경우였음. XFree86에서 반응 없는 포인터는 뭔가 잘못됐거나 설정이 틀렸다는 매우 유용한 신호였는데, 그 시절이 그립다
    • Wayland가 몇 살인가? 이 속도면 무덤에서 “봄의 꿈”을 읽고 있을 듯함
      공짜 소프트웨어에 불평하는 건 알지만, 이건 너무 오랫동안 더 나쁜 쪽으로 강제 전환되고 있음. Wayland 도입은 모든 입력과 디스플레이 요구사항에서 거의 보편적으로 우월하다는 전제 위에 이뤄졌어야 함
      Intel, AMD, Nvidia, Arm 제조사들은 쓸 만한 데스크톱 Linux를 위해 컨소시엄으로 전력투구해야 함. 정부도 마찬가지임. 안전한 Linux 데스크톱은 실제로 가능하고, CPU와 3D 기능, 고급 벡터/컴퓨터 하드웨어를 보여주는 가장 빠른 길이기 때문임
      Wayland는 Windows가 끔찍한 타일 UI로 스스로를 망치려던 시기, Apple이 일반 x86용 macOS를 내놓으면 얻을 수 있었을 추가 시가총액을 완강히 거부하던 시기에 등장해 Linux 데스크톱 지연을 더 키운 셈임
    • “마우스만을 위한 명시적 표시 하드웨어가 있어 지연을 줄였다”는 건 지금도 마찬가지임. 마우스 커서는 창 합성기의 스왑체인과 독립된 스프라이트/오버레이로 렌더링됨. 그렇지 않으면 특히 60Hz에서는 지연이 매우 눈에 띔
      요령이 필요한 건 창이나 아이콘을 끌 때인데, 이때 스왑체인 지연이 보이기 시작함. 일부 창 합성기는 높은 주사율 덕분에 지연이 덜 보인다고 보고 더 이상 신경 쓰지 않으며, 예를 들면 macOS가 그렇고, Windows는 드래그 중에 소프트웨어 마우스 커서로 전환하는 것 같음
    • GNOME에는 unredirection 지원이 있어서, 이 테스트가 실제 게임 성능에 적용된다고 보긴 어려움
      전체화면 앱은 합성기를 통과하거나 우회하는 빠른 경로를 타야 함

  • 이런 프레임 단위 분석에 ffmpeg를 쓰는 사람이라면 ffmpeg -skip_frame nokey -i file -vsync 0 -frame_pts true out%d.png로 영상의 각 프레임 표시 시각을 얻을 수 있음. 그냥 프레임을 덤프하고 타임스탬프를 계산하는 것보다 더 정확함
    웹브라우저에서도 영상을 재생하면서 requestVideoFrameCallback()을 쓰면 비슷하게 할 수 있음. 다만 컴퓨터가 모든 프레임을 충분히 빠르게 디코딩하지 못하면 .playbackRate를 낮춰야 할 수 있음
    144Hz 화면에서 Wayland가 X11보다 평균 약 6.5ms 더 느리고, 그 차이가 거의 한 번의 화면 갱신과 같다는 점은 우연이 아닐 수 있음. 지연이 거의 1/144초라면 일반 60Hz 모니터에서는 1/60초가 될 수도 있음. 훈련 없이는 의식적으로 알아차리기 어렵지만, 대부분은 설명하지 못해도 “느낄” 수 있음

    • 추측하자면 “진짜” 수치는 2.5프레임과 3.5프레임에 가까울 듯함. 마우스를 건드린 순간과 화면 갱신 사이의 무작위 위상 때문에 평균 반 프레임, 여기에 커서 이동까지 2프레임 또는 3프레임이 붙는 식임. 각 집합에서 낮은 이상치를 빼면 그 값에 꽤 가까워짐
      물론 많은 사용자에게는 125Hz 마우스 폴링률도 교란 요인이지만, 이 경우에는 1KHz 마우스를 사용했음
      7ms 차이는 나쁘지 않지만, 16.6ms 차이는 꽤 커지기 시작함. 개인적으로 컴퓨터는 1.6프레임 지연을 목표로 노력해야 한다고 봄. 무작위 위상 반 프레임, 한 프레임, 그리고 약간의 처리 시간 정도임
    • 저지연 터미널은 단순한 타이핑 같은 작업에서도 체감 개선이 큼
    • 마우스 이동과 화면 사이에 버퍼링 한 프레임이 추가된 것이 거의 확실해 보임. 수직 동기화가 이를 일으킬 수 있지만, 이중 버퍼링만으로도 수직 동기화는 가능해야 함

  • 결과는 합성기, GPU, 설정에 따라 달라질 것임. X11에서는 Linux 데스크톱 시스템이 쓰는 X 서버 구현이 사실상 하나뿐이라 이런 차이가 덜함
    아직도 많은 합성기/GPU 조합에서 하드웨어 커서 평면을 얻지 못하는 문제가 있을 수 있고, 그렇다면 이런 지연 차이가 충분히 생길 수 있음

  • 오늘 알았는데 Wayland가 벌써 16년이나 됐음. 몇 년 뒤면 Wayland가 나왔을 때의 X 나이와 같아질 텐데, 여전히 평범하거나 X만 못하다고 여겨지는 듯함

    • X의 최초 릴리스는 1984년 6월이고 Wayland는 2008년에 처음 나왔으니, Wayland가 같은 나이가 되려면 2032년은 되어야 함. 사람들이 Wayland가 평범하다거나 “X만큼 좋지 않다”고 불평할 때는 대개 “Wayland가 $very_specific_feature를 지원하지 않는다”거나 “내 그래픽카드 제조사의 독점 드라이버가 Wayland에서 충분히 테스트되지 않아 슬프다”는 뜻인 경우가 많음
      그런 불평의 약 99.999%는 1) 직접 작업하지 않고, 2) 작업할 관심이나 능력이 없으며, 3) Wayland와 X 개발자가 대부분 같은 사람들이고 그들이 더 이상 X11 작업을 하고 싶어 하지 않는다는 점을 이해하지 못하거나 인정하지 않는 사람들에게서 나옴
      이 논쟁에 특별한 이해관계는 없지만, 남이 공짜로 준 소프트웨어를 쓰면서 Wayland를 불평하는 걸 보는 데 지쳤음. Wayland 불평이 그렇게 많다면, 지금쯤 뭉쳐서 X를 유지보수·개선하고, 불평과 이론이 맞다면 Wayland를 뒤로 남겨둘 수도 있었을 것임
      이상하게도 X는 오픈소스이고 얼마든지 포크할 수 있는데, XFree86에서 X.org가 나온 사례가 있음에도, 지지자들은 먼지만 쌓이게 두고 유지보수에는 아무것도 하지 않음
      “Wayland는 X만큼 좋지 않으니 누구나 쓸 수 있는 현대화된 X 포크를 만들었다”는 결과물이 나오면 꽤 관심 있게 볼 것임
    • 아니, 그렇지 않음. X는 1984년산임: https://www.talisman.org/x-debut.shtml
      즉 Wayland는 Wayland가 나왔을 당시 X 나이의 66% 정도에 불과하고, 같은 나이가 되려면 지금 Wayland 수명에서 50%가 더 필요함
    • X가 40살이고 Wayland가 16살이면 차이는 24년임. 따라서 Wayland 합성기들은 문제를 다듬을 시간이 8년 남은 셈임
      지금 Plasma 6에서 Wayland를 쓰고 있고 충분히 잘 작동하지만, 특별한 요구사항은 없어서 예를 들어 화면 읽기 프로그램이 얼마나 잘 되는지는 모르겠음
    • 이 숫자를 다르게 보면, 몇 년 뒤에는 Wayland 후계자가 나올 때가 됐다는 뜻이기도 함. Wayland와 같은 동기, 즉 레거시 소프트웨어를 유지보수하려는 사람이 부족하다는 이유에서 나올 수 있음
      그 시점에는 브라우저 프론트엔드 스택이 데스크톱을 완전히 먹어치울 것이라고 예상함. 어차피 Linux에 새 데스크톱 앱이 많이 나오던 것도 아니었음
    • Wayland는 Windows Vista의 합성기와 같은 시기에 나왔음. 관대하게 봐서 다음 버전인 Windows 7에서 “좋고 안정적인” 합성기가 생겼다고 치면, Wayland는 Windows보다 13년 뒤처진 셈임

  • 작동하는 해법을 “더 현대적이고, 유지보수하기 쉽고, 미래 대비가 된다”는 이유로 다시 쓰려는 시도는 대부분 그렇게 되지 않아서 놀랍지 않음. 대개 더 느려지고, 지연이 늘고, 더 빠른 하드웨어가 떠받쳐줄 뿐 소프트웨어가 빨라진 건 아님
    20년마다 새 세대가 이전 세대가 힘든 일을 해서 만들어둔 추상화에 응석받이처럼 기대며 더 약해지는 느낌임. 소프트웨어 개발자가 3세대쯤 지나고 나니 남은 건 라이브러리/프레임워크 호출자뿐이고, 성능과 최적화를 제대로 아는 사람이 거의 없음

    • 내 경험은 다름. 여러 컴퓨터를 KDE 6로 업그레이드하면서 Wayland로 바꿨더니 시스템의 전반적인 반응성과 경쾌함이 눈에 띄게 좋아졌음
      Wayland가 X11에 비해 아직 부족한 기능은 있지만, 다른 장점 때문에 그 정도는 타협할 의향이 있음
    • 예전 컴퓨터는 지연이 더 낮았지만, 반대로 많은 운영체제에서는 앱 하나가 죽으면 OS 전체가 반응하지 않아 시스템 전체를 재부팅해야 했음

  • 여러 Wayland 합성기는 키보드, 마우스, 기타 입력 장치에서 큰 문제가 있음. Wayland 명세와 참조 구현이 그런 것들을 지원하지 않기로 했기 때문임. 그래서 각 Wayland 합성기가 서로 다른 해법을 고름
    흔한 선택지는 libei와 libinput이지만, “고급” 마우스/키보드 입력은 아예 지원하지 않는 경우도 많음. weston이 그런 예임. 특정 Linux 소프트웨어가 특정 Wayland 환경에서 동작할지 전혀 알 수 없고, 파편화가 심각함
    X에서는 실제로 모든 것을 구현하는 강한 X11 참조가 있어서 한 곳에서 동작하면 다른 곳에서도 동작한다고 확신할 수 있음
    심지어 12년이 지났는데도 시각장애인을 위한 화면 읽기 프로그램을 지원하는 Wayland 합성기가 하나도 없음. 장난감 수준임

    • 색 보정 지원도 빠졌다고 들었음. 읽어보니 보정 앱이 측정하려는 동안 어떤 보정이 적용되는지 제어하거나 알 방법조차 없는 듯함. 게다가 클라이언트 측 창 장식도 여전히 남아 있어 오래된 보안 구멍을 고칠 기회를 포기했음
      그래서 게임에도 좋지 않고, 전문 그래픽 작업에도 좋지 않고, 시력이 좋지 않은 사람에게도 좋지 않음. 결국 만든 사람들과 조금이라도 다른 사용자에게는 대체로 좋지 않다는 뜻임
      그래도 운이 좋으면 내가 한 번도 체감한 적 없는 화면 찢김은 줄였을지도 모름
    • macOS에서 Windows로 옮긴 뒤 결국 Windows에 정착했고, 여가 개발 시간은 Windows에서 타일링 창 관리자 생태계로 파워 유저/개발자 경험을 개선하는 데 쓰게 됨: https://github.com/LGUG2Z/awesome-komorebi
      여기서 나온 멋진 결과 중 하나는 사람들이 이 생태계 위에 접근성 워크플로를 추가하는 모습임. 어떤 사람은 음성 제어로 타일링 창 관리자를 통해 데스크톱 전체를 조작함: https://youtu.be/fiPJLmhnnXM
    • “고급 마우스/키보드 입력을 전혀 지원하지 않는다”는 건 아마 엉뚱한 쪽을 탓하는 것 같음. 그런 주변기기를 만들면서 Linux 드라이버를 제공하지 않는 회사들을 봐야 함
    • GNOME의 Wayland에서 Orca를 쓸 때 무엇이 부족한가?

  • GPU가 큰 부하를 받을 때, 예를 들어 Stable Diffusion 추론 같은 작업을 할 때 큰 지연 스파이크가 생김. X11과 A/B 테스트를 해본 건 아니지만, 예전에는 이런 기억이 없음
    프레임 하나만큼 추가 지연되는 것도 좋지는 않지만, 가끔 튀는 지연 스파이크가 정말 짜증남

    • 특히 VRAM과 시스템 메모리 사이에서 스래싱이 일어나는 상황이면 여전히 생길 수 있음. 그래도 Stable Diffusion 프로세스의 우선순위를 낮춰봤는지 궁금함

  • 커서 입력 지연은 애플리케이션이나 운영체제 만족도를 계속 갉아먹는 방해물임
    IDE 텍스트 커서 지연? 받아들일 수 없음
    셸 텍스트 커서 지연? 받아들일 수 없음
    GUI 마우스 커서 지연? 받아들일 수 없음
    전부 즉시 탈락 조건임

    • macOS가 늘 뛰어났던 영역 중 하나이고, 고전 Mac OS 시절까지 거슬러 올라감
      40년 넘게 전 거의 무한히 약한 하드웨어에서 돌던 System 1조차 커서 반응성을 최우선으로 두어 모든 경쟁자를 앞섰음. 지금의 OS와 UI 기반은 100% 달라졌지만, 그 우선순위는 여전히 유지됨
    • 이게 이렇게 나쁘다는 게 당황스러움. 특히 Linux라면 더 그럼. 마우스 이동은 당연히 다른 모든 것보다 우선해야 하지 않나? 마우스를 올린 대상이 강조 표시되는 것조차 마우스 커서 자체를 느리게 만들어서는 안 됨
      최근 KDE/Plasma 6의 X11과 NVidia 조합에서 극심한 마우스 느려짐을 겪었음. 특히 브라우저 탭 위에서 느려짐이 심하다는 걸 알아챘음
      같은 문제가 있는 사람을 위해 적어두면, 해결책은 OpenGL flipping을 끄는 것이었음. OpenGL flipping이 뭘 하는지는 전혀 모르지만, nvidia-settings와 /etc/X11/xorg.conf에서 끄니 문제가 해결됐음
      왜 그런지, 혹은 왜 이게 기본값이 아닌지 누가 설명해주면 좋겠음

  • 멋진 작업임. 모니터를 아주 낮은 주사율, 예를 들어 30Hz로 두고 실험을 반복해볼 가치가 있을 듯함
    Wayland가 항상 X11보다 한 프레임 느리다면 훨씬 관찰하기 쉬울 것임

  • 약간 다른 개인적 불만이 있음. 처음 Linux를 쓰기 시작했을 때 데스크톱은 소프트웨어 합성이었음. 아마 CPU가 RAM에 UI를 그린 뒤 GPU 프레임버퍼로 블릿하는 식이었고, 오래전부터 그렇게 해왔던 방식이라고 봄
    합성기, X11 composite까지 포함해, 그리고 GPU 렌더러가 유행하면서 지연이 끔찍해졌고 말 그대로 수백 ms 수준이 됐음. DOS 게임을 하며 자랐을 때는 이런 문제가 없었으니 이상했음
    시간이 지나며 개선되긴 했지만, 우리가 CPU 렌더링의 황금기로 돌아왔는지는 잘 모르겠음

답변달기