egui: Rust를 위한 빠르고 휴대성이 높은 즉시 모드 GUI 라이브러리

egui는 Rust를 위한 간단하고, 빠르며, 매우 휴대성이 높은 즉시 모드(immediate mode) GUI 라이브러리입니다. egui는 웹, 네이티브 환경, 그리고 사용자가 선호하는 게임 엔진에서 실행될 수 있습니다.

egui의 목표는 가장 사용하기 쉬운 Rust GUI 라이브러리가 되는 것이며, Rust로 웹 앱을 만드는 가장 간단한 방법이 되는 것입니다.

egui는 텍스처화된 삼각형(textured triangles)을 그릴 수 있는 모든 곳에서 사용될 수 있으므로, 선택한 게임 엔진에 쉽게 통합할 수 있습니다.

eframe은 공식 egui 프레임워크로, 웹(Web), Linux, Mac, Windows, 그리고 Android용 앱 작성 기능을 지원합니다.

ui.heading("My egui Application");
ui.horizontal(|ui| {
ui.label("Your name: ");
...

• 예제(Example)
• 빠른 시작(Quick start)
• 데모(Demo)
• 목표(Goals)
• 상태/기능(State / features)
• 의존성(Dependencies)
• egui 사용 대상(Who is egui for?)
• 통합(Integrations)
• 즉시 모드란 무엇인가(Why immediate mode)
• FAQ
• 기타(Other)
• 크레딧(Credits)

examples/ 폴더에 간단한 예제들이 있습니다. 웹 앱을 작성하려면 https://github.com/emilk/eframe_template/로 이동하여 지침을 따르십시오. 공식 문서는 https://docs.rs/egui를 참조하십시오. 영감과 더 많은 예제를 원한다면 egui 웹 데모를 확인하고, 그 안의 링크들을 따라 소스 코드를 살펴보십시오.

기존 엔진에 egui를 통합하려면 '통합(Integrations)' 섹션으로 이동하십시오.

질문이 있다면 GitHub Discussions를 사용하십시오. 또한 egui discord 서버도 있습니다. egui에 기여하고 싶다면, Contributing Guidelines를 읽어주시기 바랍니다.

egui 웹 데모 실행하기 (Wasm 및 WebGL 지원 브라우저에서 작동합니다). eframe을 사용합니다.

로컬에서 데모 앱을 테스트하려면 cargo run --release -p egui_demo_app를 실행하십시오.

네이티브 백엔드는 egui-wgpu (wgpu 사용)이며 Mac과 Windows에서는 별도의 설정 없이 작동해야 하지만, Linux에서는 먼저 다음 명령어를 실행해야 합니다:

sudo apt-get install -y libclang-dev libgtk-3-dev libxcb-render0-dev libxcb-shape0-dev libxcb-xfixes0-dev libxkbcommon-dev libssl-dev

Fedora Rawhide에서는 다음을 실행해야 합니다:

dnf install clang clang-devel clang-tools-extra libxkbcommon-devel pkg-config openssl-devel libxcb-devel gtk3-devel atk fontconfig-devel

참고: 이것은 데모 앱을 위한 것일 뿐이며, egui 자체는 완전히 플랫폼 독립적입니다!**

• 사용하기 가장 쉬운 GUI 라이브러리
• 반응성(Responsive): 디버그 빌드에서 60Hz 목표
• 친화적(Friendly): 실수를 하기가 어렵고, 패닉 상태에 빠지지 않음
• 이식성(Portable): 동일한 코드가 웹과 네이티브 앱에서 작동함
• 모든 환경에 통합하기 쉬움
• 사용자 정의 페인팅을 위한 간단한 2D 그래픽 API (epaint)
• 순수 즉시 모드(Pure immediate mode): 콜백 없음
• 확장성(Extensible): egui용 위젯을 쉽게 작성할 수 있음
• 모듈식(Modular): egui의 작은 부분들을 사용하여 새로운 방식으로 조합할 수 있어야 함
• 안전함(Safe): egui에는 unsafe 코드가 없음 - 최소한의 의존성

egui는 프레임워크가 아닙니다. egui는 여러분이 프로그래밍하는 환경이 아니라, 호출하여 사용하는 라이브러리입니다.

참고: egui가 아직 이 모든 목표를 달성했다고 주장하지 않습니다! egui는 여전히 작업 중인(work in progress) 상태입니다.

• 가장 강력한 GUI 라이브러리가 되는 것
• 네이티브처럼 보이는 인터페이스

egui는 활발하게 개발되고 있습니다. 자신이 하는 일에는 잘 작동하지만, 많은 기능이 부족하고 인터페이스가 아직 유동적(in flux)입니다. 새로운 릴리스에서는 호환성 파괴 변경 사항(breaking changes)이 있을 것입니다.

그럼에도 불구하고, egui를 사용하여 Rerun Viewer와 같은 전문적인 외관의 애플리케이션을 만들 수 있습니다.

• 위젯: 레이블(label), 텍스트 버튼(text button), 하이퍼링크(hyperlink), 체크박스(checkbox), 라디오 버튼(radio button), 슬라이더(slider), 드래그 가능한 값(draggable value), 텍스트 편집(text editing), 색상 선택기(color picker), 스피너(spinner)
• 이미지
• 레이아웃: 수평(horizontal), 수직(vertical), 열(columns), 자동 줄 바꿈(automatic wrapping)
• 텍스트 편집: 여러 줄(multiline), 복사/붙여넣기, 실행 취소(undo), 이모지 지원
• 창(Windows): 이동(move), 크기 조정(resize), 이름 지정(name), 최소화 및 닫기(minimize and close). 자동으로 크기가 조정되고 배치됩니다.
• 영역(Regions): 크기 조정, 수직 스크롤링, 접을 수 있는 헤더(sections), 패널
• 렌더링: 선, 원, 텍스트 및 볼록 다각형의 안티앨리어싱(Anti-aliased) 렌더링.
• 호버 시 툴팁(Tooltips on hover)
• AccessKit을 통한 접근성(Accessibility)
• 레이블 텍스트 선택
• 그리고 더 많은 것!

커뮤니티가 관리하는 3rd party egui 크레이트 위키에서 훨씬 더 많은 위젯과 기능을 확인해 보세요.

라이트 테마(Light Theme):

egui는 최소한의 기본 의존성 세트를 가집니다. 무거운 의존성은 egui에서 제외됩니다.

, 심지어 선택적(opt-in)으로도 그렇습니다.

egui의 모든 코드는 Wasm 친화적입니다 (브라우저 외부에서도).

egui에 이미지를 로드하려면 공식 egui_extras 크레이트를 사용할 수 있습니다.

반면에 eframe은 winit, image, 그래픽스 크레이트, 클립보드 크레이트 등을 포함하여 많은 의존성을 가지고 있습니다.

egui는 간단한 방식으로 GUI를 만들고 싶거나 게임 엔진에 GUI를 추가하고 싶을 때 최고의 선택이 되도록 목표합니다.

만약 Rust를 사용하지 않는다면, egui는 적합하지 않습니다. 네이티브처럼 보이는 GUI를 원한다면, egui는 적합하지 않습니다. 업그레이드할 때 깨지지 않는 무언가를 원한다면, (아직은) egui가 아닙니다.

하지만 Rust로 간단한 GUI가 필요한 인터랙티브한 것을 작성하고 있다면, egui가 적합할 수 있습니다.

egui는 작업하는 모든 기존 게임 엔진이나 플랫폼에 쉽게 통합되도록 구축되었습니다. egui 자체는 어떤 OS에서 실행되는지 또는 화면에 어떻게 렌더링해야 하는지는 알거나 신경 쓰지 않습니다. 그것은 egui 통합의 역할입니다.

통합은 매 프레임마다 다음을 수행해야 합니다:

입력(Input): 입력(마우스, 터치, 키보드, 화면 크기 등)을 수집하여 egui에 제공하고 - 애플리케이션 GUI 코드로 호출
출력(Output): egui 출력을 처리합니다 (커서 변경, 붙여넣기, 텍스처 할당 등)
그리기(Painting): egui가 생성한 삼각형 메시를 렌더링합니다 (OpenGL 예시 참조)

다음은 공식 egui 통합들입니다:

• eframe: 동일한 앱을 웹/wasm 및 데스크톱/네이티브로 컴파일하는 용도. egui-winit과 egui_glow 또는 egui-wgpu를 사용합니다.
• egui_glow: 네이티브와 웹에서 glow를 사용하여 egui를 렌더링하고, 네이티브 앱을 만드는 용도.
• egui-wgpu: wgpu (WebGPU API)용.
• egui-winit: winit과 통합하는 용도.

위키에서 서드파티 통합 및 egui 크레이트를 찾아보세요.

작업 중인 것에 대한 통합이 누락되었나요? 하나를 만드세요, 쉽습니다! https://docs.rs/egui/latest/egui/#integrating-with-egui 참고하세요.

egui

이는 유지 모드(retained mode) GUI 라이브러리와는 달리 즉시 모드(immediate mode) GUI 라이브러리입니다. 유지 모드와 즉시 모드의 차이점은 버튼의 예시로 가장 잘 설명될 수 있습니다. 유지 GUI에서는 버튼을 생성하고, 이를 UI에 추가하며, 클릭 시 실행되는 핸들러(콜백)를 설치합니다. 이 버튼은 UI에 유지되며, 텍스트를 변경하려면 이에 대한 일종의 참조를 저장해야 합니다. 반면, 즉시 모드에서는 버튼을 보여주고 즉시 상호 작용하며, 이를 매 프레임마다 수행합니다 (예: 초당 60회). 이는 클릭 시 핸들러가 필요하지 않으며, 이에 대한 참조를 저장할 필요도 없다는 것을 의미합니다. egui에서는

이것이 다음과 같이 보입니다: if ui.button("Save file").clicked() { save(file); }

즉시 모드에 대한 더 자세한 설명은 egui 문서를 참고할 수 있습니다.

두 시스템 모두 장점과 단점이 있습니다.

요약하자면, 즉시 모드 GUI 라이브러리는 사용하기는 쉽지만, 기능적으로는 덜 강력합니다.

즉시 모드의 주요 장점은 애플리케이션 코드가 훨씬 단순해진다는 것입니다:

• 코드 흐름을 방해하는 클릭 핸들러나 콜백이 필요 없습니다.
• 사라진 무언가를 호출하는 잔류(lingering) 콜백에 대해 걱정할 필요가 없습니다.
• GUI 코드를 간단한 함수 내에 쉽게 배치할 수 있습니다 (UI만을 위한 객체가 필요하지 않습니다).
• GUI가 상태를 저장하지 않고 최신 상태를 즉시 보여주기 때문에, 앱 상태와 GUI 상태가 동기화되지 않는 문제(즉, GUI가 오래된 정보를 표시하는 것)에 대해 걱정할 필요가 없습니다.

다시 말해, 많은 코드, 복잡성, 버그가 사라지므로, GUI 코드를 작성하는 것보다 더 흥미로운 것에 시간을 집중할 수 있습니다.

제목: 즉시 모드(Immediate Mode) GUI의 근본적인 한계점 분석

즉시 모드(immediate mode)의 주요 단점은 레이아웃을 더 어렵게 만든다는 것입니다. 화면 중앙에 작은 대화 상자 창을 표시하고 싶다고 가정해 봅시다. 이 창을 정확하게 배치하려면 GUI 라이브러리가 먼저 그 크기를 알아야 합니다. 창의 크기를 알기 위해서는 GUI 라이브러리가 먼저 창의 내용을 레이아웃해야 합니다. 반면, 유지 모드(retained mode)에서는 이것이 쉽습니다. GUI 라이브러리는 창 레이아웃을 수행하고, 창 위치를 지정한 다음, 상호 작용 여부("OK 버튼이 클릭되었는가?")를 확인합니다.

즉시 모드에서는 역설에 부딪힙니다. 창의 크기를 알기 위해 우리는 레이아웃을 해야 하지만, 이 레이아웃 코드는 또한 상호 작용 여부를 확인해야 하며("OK 버튼이 클릭되었는가?"), 따라서 창 내용을 표시하기 전에 창 위치를 알아야 합니다. 이는 우리가 창의 크기를 알기도 전에 어디에 창을 보여줄지 결정해야 함을 의미합니다!

이는 즉시 모드 GUI의 근본적인 단점이며, 이를 해결하려는 모든 시도는 그 자체로 단점을 안고 옵니다.

한 가지 우회 방법은 크기를 저장하고 다음 프레임에서 사용하는 것입니다. 이는 올바른 레이아웃을 위해 프레임 지연(frame-delay)을 발생시키며, 때때로 첫 프레임에 무언가가 나타날 때 깜빡거림(flickering)이 발생합니다. egui가 이를 처리합니다.

이는 창이나 그리드 레이아웃과 같은 일부 경우에 해당됩니다.

"첫 프레임 지터(first-frame jitter)"는 추가적인 *패스(pass)*를 통해 가려질 수 있으며, egui는 Context::request_discard를 통해 이를 지원합니다.
이것의 단점은 두 번째 패스를 처리하는 추가적인 CPU 비용입니다. 따라서 egui는 매우 드문 경우에만 이것을 수행하며 (대부분의 프레임은 싱글-패스입니다).

"원자적(atomic)" 위젯(예: 버튼)의 경우, egui는 표시하기 전에 크기를 알고 있으므로, 특별한 우회 방법 없이도 egui에서 버튼이나 레이블 등을 중앙에 배치하는 것이 가능합니다.
더 자세한 내용은 이 이슈를 참조하십시오.

즉시 모드 GUI가 매 프레임마다 전체 레이아웃을 수행하기 때문에, 레이아웃 코드는 빨라야 합니다. 매우 복잡한 GUI를 가지고 있다면 이것이 CPU에 부담을 줄 수 있습니다. 특히 스크롤 영역(매우 긴 스크롤백)에 매우 큰 UI가 있는 경우, 콘텐츠가 매 프레임마다 레이아웃되어야 하므로 느려질 수 있습니다.

GUI를 이러한 점을 염두에 두고 설계하고 거대한 스크롤 영역을 피하거나 (또는 보이는 부분만 배치한다면) 성능 저하는 일반적으로 상당히 작습니다. 대부분의 경우 egui가 프레임당 1~2ms 정도 소요될 것으로 예상할 수 있지만, egui에는 여전히 최적화할 여지가 많습니다 (제가 아직 집중하지 않은 부분입니다). egui는 상호작용(예: 마우스 움직임)이나 애니메이션이 있을 때만 다시 그려지므로, 앱이 유휴 상태일 때는 CPU가 낭비되지 않습니다.

GUI가 매우 상호작용적이라면, 즉시 모드(immediate mode)가 오히려 리테인 모드(retained mode)보다 더 성능이 좋을 수 있습니다. 웹 페이지로 이동하여 브라우저 창 크기를 조정해 보면, 레이아웃을 처리하는 데 브라우저가 매우 느리고 많은 CPU를 소모한다는 것을 알게 될 것입니다. 반면에 egui에서 창 크기를 조정하면 추가적인 CPU 비용 없이 부드러운 60 FPS를 얻을 수 있습니다.

GUI 라이브러리가 유지해야 하는 몇 가지 GUI 상태가 있습니다. 이는 즉시 모드와 같은 egui에서도 마찬가지입니다. 여기에는 창의 위치와 크기, 그리고 사용자가 일부 UI에서 얼마나 스크롤했는지 등이 포함됩니다. 이러한 경우, 고유 식별자(부모 UI 내에서 고유한)의 시드(seed)를 egui에 제공해야 합니다. 예를 들어: 기본적으로 egui는 창 제목을 사용하여 창 위치를 저장하는 고유 ID로 사용합니다. 동일한 이름을 가진 두 개의 창(또는 동적 이름의 하나의 창)을 원한다면, 다른 ID 소스(어떤 고유 정수 또는 문자열)를 egui에 제공해야 합니다.