나.시스템의 지원

운영체제의 다중 모니터 지원 정책은 아주 잘 작성되어 있다. 응용 프로그램이 특별히 다중 모니터 환경을 고려하지 않더라도 대부분의 경우에 있어 동작하는데 큰 무리가 없기 때문에 응용 프로그램 개발자는 다중 모니터 환경에 대해 크게 신경쓸 필요가 없다. 시스템의 다중 모니터 지원이 어떤 식인지 살펴 보도록 하자.

윈도우나 아이콘 등의 개체는 가상 화면의 어느 곳으로나 드래그할 수 있다. 이쪽 모니터에서 드래그하여 저쪽 모니터로 옮기기만 하면 된다. 윈도우의 경우 두 모니터의 경계에 걸쳐 있을 수도 있는데 이렇게 하더라도 DC가 각 모니터의 특성들을 고려하여 그리기를 하기 때문에 내용 출력에는 아무 문제가 없고 성능상의 불이익도 거의 없는 편이다. 응용 프로그램은 모니터에 직접 출력을 보내는 것이 아니라 DC라는 표면에 출력을 보내기 때문에 기존의 그리기 코드는 그대로 쓸 수 있다.

오브젝트가 두 모니터의 경계에 걸쳐 있을 때는 시스템이 미리 정한 규칙에 따라 오브젝트를 배치한다. 경계에 걸친 윈도우를 최대화할 때는 많이 걸쳐 있는 쪽 모니터로 최대화되며 메시지 박스나 대화상자는 부모 윈도우가 있는 쪽에 열린다. 메뉴도 윈도우와 마찬가지로 많이 걸친 쪽에 열리며 팝업 메뉴는 오른쪽 버튼을 누른 지점에 열린다. 바로 가기를 더블클릭하여 프로그램을 실행할 때는 바로가기 아이콘이 있는 모니터에서 실행된다.

보다시피 운영체제의 다중 모니터 지원 정책은 지극히 상식적이기 때문에 사용자 입장에서나 개발자 입장에서나 특별히 주의할만한 사항은 없는 셈이다. 다만 하드웨어적인 한계에 의해 VGA 호환 장비는 하나만 가능하다는 한계점이 있다. VGA는 물리적인 절대 주소 공간을 요구하기 때문에 두 개의 모니터가 동시에 VGA 호환 모드로 동작할 수는 없다.

시스템이 다중 모니터 환경을 단순한 데스크탑의 확장으로 다룰 수 있도록 해 주기 때문에 API 함수들도 거의 변경없이 그대로 사용할 수 있다. 다만 시스템의 정보를 조사하는 몇가지 함수의 플래그들에 약간씩의 변화가 있고 다중 모니터 지원을 위한 함수들이 추가되었다는 점 정도만 다르다.

시스템 메트릭스 정보를 조사하는 GetSystemMetrics 함수의 경우 모든 메트릭스값들은 호환성 유지를 위해 항상 주 모니터를 기준으로 한다. 커서의 크기, 아이콘의 크기, 인치당 픽셀 수 등은 어느 모니터를 기준으로 하나 동일할 수 밖에 없다. 화면 크기를 조사하는 SM_CXSCREEN, SM_CYSCREEN 메트릭스는 항상 주 모니터의 크기만 조사해 준다. 이 값들이 가상 화면의 크기를 조사하도록 변경되어 버린다면 다중 모니터를 인식하지 못하는 프로그램들과의 호환성이 사라지기 때문이다.

유일하게 달라지는 메트릭스는 SM_CXMAXTRACK, SM_CYMAXTRACK뿐인데 이 값들은 항상 가상 화면을 기준으로 한다. 따라서 다중 모니터 환경에서 윈도우의 경계를 드래그해서 조정할 수 있는 최대 크기는 가상 화면으로 자연스럽게 확장된다. 이 메트릭스가 가상 화면의 정보를 조사해 주기 때문에 다중 모니터를 지원하지 않는 응용 프로그램이라도 주 모니터보다 더 큰 크기로 만들 수 있는 것이다. 다음은 가상 모니터 지원을 위해 추가된 메트릭스들이다.

값	설명
SM_CMONITORS	시스템에 장착된 모니터 개수를 조사한다. 95/NT에서는 0으로 조사된다.
SM_SAMEDISPLAYFORMAT	모든 모니터들의 색상 포맷이 같은지 조사한다
SM_XVIRTUALSCREEN SM_XVIRTUALSCREEN	가상 화면의 좌상단 좌표이다. 주모니터의 왼쪽이나 위쪽에 추가 모니터가 있으면 음수값을 가질 수도 있다.
SM_CXVIRTUALSCREEN SM_CXVIRTUALSCREEN	가상 화면의 폭과 높이다.

윈도우와 작업영역 크기를 구하는 GetWindowRect, GetClientRect 함수도 호환성 유지를 위해 항상 주 모니터를 기준으로 동작한다. GetWindowRect(hWnd, &rc) 호출에 의해 조사되는 rc는 주 모니터의 원점에서 얼마만큼 떨어져 있는가를 나타내며 이 윈도우가 주 모니터의 왼쪽 모니터에 있다면 음수 좌표를 가질 수도 있다.

다중 모니터 환경에 따른 API 함수의 변화도 거의 없는 셈이기 때문에 응용 프로그램 개발자들은 과거에 하던 방식대로 큰 변화없이 코드를 작성할 수 있다. 하지만 다음과 같은 사항에 대해서는 고려를 해야 한다.

1.음수 좌표의 존재 가능성 인식 : 과거 특정 윈도우를 잠시 숨기고 싶다거나 또는 시작중에 윈도우 생성 모습을 보이지 않기 위해 음수 좌표나 아주 큰 좌표로 윈도우를 잠시 이동시키는 기법을 종종 사용하곤 했는데 이제 이런 기법들이 더 이상 통하지 않는다. 음수 좌표가 실제 존재하기 때문에 이런 기법을 섣불리 사용하다가는 왼쪽 모니터로 윈도우가 잠시 이동하는 꼴사나운 현상을 사용자가 목격할 수도 있다.

2.저장한 좌표의 유효성을 점검하는 방법 변화 : 모니터가 하나뿐일 때는 GetSystemMetrics 함수로 조사한 SM_CX(Y)SCREEN 좌표 밖은 모두 무효한 좌표였다. 최후 실행 위치를 레지스트리에 저장한 후 다시 실행할 때 이 위치를 복구하는 기법은 아주 일반적인데 해상도가 변화되면 저장된 좌표가 무효해질 수 있다. 이럴 경우 아예 윈도우가 보이지 않기 때문에 다시 화면 안쪽으로 넣어 주었는데 이제부터는 다중 모니터 환경을 고려하여 주 모니터의 좌표가 아니더라도 오른쪽 모니터의 좌표인지도 같이 점검해 보아야 한다.

3.다중 모니터를 구성하는 각 모니터는 해상도와 색상 포맷을 자유롭게 변경할 수 있다. 두 모니터의 색상 포맷이 다를 경우 그리기를 하는 방식이 모니터별로 달라지기 때문에 경계에 걸쳤을 때 그리기 성능이 다소 저하되는 경향이 있다. 이럴 때는 시스템의 지원을 받지 말고 직접 그리기 루틴을 최적화해야 한다.