Wayland 컴포지터와 윈도 관리자 분리

• 기존 Wayland 환경은 컴포지터와 윈도 관리자가 하나의 프로그램으로 결합된 구조였으나, river 0.4.0은 이를 별도 프로세스로 분리함
• 새로운 river-window-management-v1 프로토콜은 윈도 관리자에게 창 배치, 키 바인딩 등 정책 전권을 부여하면서도 프레임 완전성(frame perfection) 과 성능을 유지함
• 이 구조는 입력 지연(latency) 없이 동작하며, 복잡한 타일 레이아웃에서도 원자적 상태 업데이트를 통해 깔끔한 렌더링을 보장함
• 분리된 구조 덕분에 윈도 관리자는 독립적으로 개발·재시작 가능, 고수준 언어로도 구현이 용이함
• 이 접근은 Wayland 생태계의 윈도 관리자 다양성 확대를 촉진하며, river는 이미 15개 이상의 호환 관리자를 지원함

Wayland 전통 구조와 river의 분리 접근

• 기존 Wayland 컴포지터는 디스플레이 서버, 컴포지터, 윈도 관리자 세 역할을 하나의 프로세스에 통합
  • 디스플레이 서버는 입력 이벤트를 라우팅하고, 커널에 표시 버퍼를 전달
  • 컴포지터는 여러 창의 버퍼를 결합해 최종 화면을 생성
  • 윈도 관리자는 창 배치와 키 바인딩 등 사용자 정책을 담당
• X11 구조에서는 디스플레이 서버가 별도 프로세스로 존재해 불필요한 왕복 통신과 지연이 발생
• Wayland는 이를 해결하기 위해 서버와 컴포지터를 통합했으나, 윈도 관리자까지 결합한 것은 필수적이지 않음
• river는 이 결합을 해체해 윈도 관리자를 별도 프로그램으로 분리함

river-window-management-v1 프로토콜의 설계 원칙

• 윈도 관리자가 최대 제어권을 가지면서도 Wayland의 장점을 유지하도록 설계
• 매 프레임이나 입력 이벤트마다 왕복 통신이 필요하지 않음, 입력 지연이 없음
• 프레임 완전성(frame perfection) 유지: 창이 새로 열리거나 크기가 바뀔 때 틈이나 겹침 없는 화면 갱신 보장
  • 모든 창이 새 버퍼를 제출할 때까지 렌더링을 지연하되, 일정 시간 초과 시 타임아웃으로 처리
• 잘 구현된 애플리케이션일수록 완전한 프레임 동기화가 가능

상태 머신 기반 윈도 관리 구조

• 프로토콜은 상태를 윈도 관리 상태와 렌더링 상태로 구분
  • 윈도 관리 상태: 창 크기, 전체화면 여부, 키보드 포커스, 키 바인딩 등
  • 렌더링 상태: 창 위치, 순서, 장식, 크롭 등
• 변경 사항은 원자적 업데이트(manage/render sequence) 로 묶여 처리
• 컴포지터가 시퀀스를 시작하며, 상태 변화가 없을 때는 윈도 관리자가 대기 상태로 유지
• 이 구조는 기존 river-classic, sway 등에도 내재된 개념을 명시적으로 정형화한 형태

분리 구조의 이점

• 윈도 관리자 개발자는 컴포지터 전체를 구현할 필요 없이 정책에만 집중 가능
• 디버깅과 재시작이 용이, 윈도 관리자 충돌이 세션 종료로 이어지지 않음
• 가비지 컬렉션 언어로 작성해도 성능 저하 없음, 프레임 지연 없이 동작
• 이미 15개 이상의 river 호환 윈도 관리자가 존재하며, X11 수준의 다양성 확장을 기대

한계와 향후 계획

• 현재 프로토콜은 2D 데스크톱 환경만 지원, VR 등은 미지원
• 복잡한 시각 효과(예: 흔들리는 창)는 범위 밖이지만, 단순 애니메이션은 가능
• 향후 커스텀 셰이더 지원을 검토 중이나 단기 계획은 아님
• river 0.4.0은 일상 사용에 충분하며, 1.0.0 버전 전환 전 UX 개선이 예정
• 개발 지속을 위해 liberapay, GitHub Sponsors, Ko-fi를 통한 후원 요청

예시 및 갤러리

• river에서 동작하는 다양한 윈도 관리자 예시 제공
  • Canoe: 클래식한 스태킹 윈도 관리자
  • reka: Emacs 기반 윈도 관리자
  • tarazed: 집중형 데스크톱 환경
  • rhine: 재귀적·모듈형 윈도 관리와 애니메이션 지원
• 이외에도 다수의 river 호환 윈도 관리자가 존재함