Hello World!

취미가 본업보다 빡세게 굴러가는 시점에서 이미 여러가지를 포기한 상태나 다름없긴하지만 하튼 특정 기능들의 구현을 위해 ajax라는걸 손대보게 되었다.

일단 백과사전이든 강의에든 이것저것 쓰여있기는 하지만 웹개발에 익숙하지도 않고 관심도 없었기때문에 이해하는데 꽤나 많은 시간을 소요했다. 읽는것보단 예제를 직접 시연해보는게 빠르다는것도 오랜만에 다시 느꼈고...

처음에는 그냥 자바스크립트인가 했지만 약간은 떨어져있는...뭐라고 설명해야 되는지 딱히 감이 잡히질 않는데 그냥 이해한걸 간단하게 한줄로 설명해보면 

웹 페이지를 실시간으로 변경하는데 사용되는 것. 다만 서버를 사용한다

자바스크립트는 철저하게 Client기반. 즉 브라우저를 기초로 해서 굴러가는 언어라고 생각했었지만 이런식으로도 통신이 가능하구나 라는것을 알게 된 기회가 되었...지만 뭐 실제로 내가 이걸 이곳저곳에 막 쓰고 그러진 않겠지

1회성 긴급 땜빵용 습득이 되어서 체계적으로 배울 기회가 없어지는것 같기도 하고

내가 윈폼 기반 프로그램으로 돈을 벌어먹고사는가라면야 계속 이어가야겠지만

취미로 하는 프로젝트에서 에너지를 그렇게 막 쏟을 필요가 없을 것 같다는 생각도 들어서 어떻게든 프로젝트를 WPF쪽으로 전환시키려다가 방법을 찾음

무려 WinForm용 컨트롤을 불러와서 사용할수있는 기능이 있었던것이다...

https://msdn.microsoft.com/ko-kr/library/ms751761(v=vs.110).aspx

이제 CefSharp기반 프로젝트를 굳이 Winform에서 진행할 필요가 없어졌다

일단 윈폼은 MFC의 후계자같은 느낌이 강해서 UI구성에도 애를 먹었는데

역시 UI구성은 WPF쪽이 압도적으로 편하고 깔끔하게 구성할 수 있는것같다

이거 완전 MFC아닌가 할 생각이 들정도의 기시감, 그리고 UI구성의 불편함

일부 작업이 자동화 되었다 뿐이지 사실상 MFC구성할때랑 큰 차이가 없는 구성. 심지어 일부 컨트롤은 따로 MSDN을 볼 필요가 없을정도로 사용방법이 비슷하고

사실 WPF도 기본적으로는 View와 Viewmodel이라는 구조를 가지고있고 유사점도 있긴하지만 Winform은 그냥 새련된 MFC라는 인상이 픽팍...

디버깅하기엔 더 좋은거같긴하지만 만지면 만질수록 WPF로 회귀하고 싶은 마음만....

그랑블루 도우미 개선 작업을 모두 WPF로 작업하려고 하였으나...

사실 원래 버전도 생긴게 그렇게 생겼다 뿐이지 WPF로 작업한 물건이였고 개선버전에서 UI가 대폭 변경된 이유는 여러 이유때문에 제외시켰던 일부 UI들을 꺼내서 다시 적용시킨것에 지나지 않지만...

그랑블루 도우미라는것을 맨 처음에 프로토타입으로 구상했었을때는 예전에 작업했던 제독업무도 바빠!(칸코레 뷰어) 처럼 내장 브라우저에서만 프록시가 돌고 화면 우측에 정보를 띄워주는 그런 구조였지만 

IE에서는 그랑블루가 정상적으로 돌지 않는다+Chromium기반 브라우저를 WPF에서 돌릴수가 없다 

등의 이유들로 reject된 컨샙...

결국 시스템 프록시를 통해서 웹 브라우저의 동작을 캡처하고 분석하는 방향으로 프로젝트가 진행되었지만 이 방식은 프로그램이 필연적으로 시스템 옵션을 건드리는 부분이 있고, chrome자체에 통신을 캡처하는 어플리케이션이 깔려있는(ex: 미꾸라지 VPN, ZenMate VPN등) 경우에는 해당 어플리케이션이 활성화 상태가 아니더라도 웹 탐색을 캡처해낼 수 없다는 문제 때문에 불편사항이 많았고 그에 따른 기타 유언비어들까지...

하여튼 이번에는 우연찮게 CefSharp이라는 Cef를 wrapping한 라이브러리가 있다는 사실을 알게 되었고 예전에 봤던 크롬 브라우저 자체를 어플리케이션에 올리는 방식이 아니라 아예 크로미움을 내장할 수 있는 그런 라이브러리인데 여기서 발생한 첫번째 문제는 Cef는 기본적으로 ffmpeg를 지원하지 않고 무조건 빌드할때 옵션을 줘서 같이 빌드하도록 만들어야 한다는 점이고

두번째 문제는 같은 라이브러리를 사용하지만 Winform에서는 Chrome보다 좋은 퍼포먼스를 보여주지만 WPF에서는 Microsoft Edge보다 나쁜 퍼포먼스를 보여준다는 것이다.

사실 지금까지 작업했던 모듈들은 다 WPF로 작업을 했었고 소환석 이미지 만들어주는 프로그램에 기존 기능을 이식할때도 거의 코드 복붙만으로도 이식이 가능했지만 이 경우에는 사실상 Document부분(이라고 지칭하겠다. WinForm에선 좀 다르게 부를수도 있을것같지만)만 그대로 가져오는것이 가능하고 나머지 UI부분은 아예 처음부터 다시 짜야한다는 점

통신 캡처용 라이브러리와 메인 Winform사이의 커뮤니케이션이야 어짜피 같은 C#으로 짜는거니까 그대로 들고온다고 하지만 역시 가장 문제가 되는 부분은 UI다. 

Winform을 얼마 안 만져봐서 잘은 모르지만 벌써부터 UI구성에 엄청나게 애를 먹고있고 기존에 구현했던걸 그대로 구현하려니까 앞길이 막막하다. 가장 좋은 해결법은 WPF에서도 Winform만큼의 퍼포먼스가 나오면 되는건데 이건 뭐 아무리봐도...

다른 대안인 ChromiumFX나 CefGlue라는것도 있지만 이걸 다시 빌드할 생각을 하면 현기증이 날 뿐이고....일단 해결책이 안나오면 그쪽도 생각해봐야겠지만

뭐 언어마다 장단점이 있고 어떤게 더 우월하다 하고 싸움붙이는건 

엄마가 좋아 아빠가 좋아 수준의 질 낮은 행위라고는 생각하지만 일단 장단점을 알아야 나중에 사용할때 도움이 되지않겠는가? 

일단 속도면에서는 아직까지는 메모리나 포인터를 직접 관리하는 C++이 우월한 편이다. 하지만 개발 난이도는 넘사벽급으로 C# 이 쉽고 적응하기 좋다.

하지만 C++로는 가능한게 C# 단독으로는 불가능한 경우가 꽤 있는 편이다.

예전에 참가했던 Github 프로젝트에서 Flash Object위에 한글 자막을 띄워줄 수 없느냐 라는 문의가 들어왔을때 한창 MFC와 C++을 배우고 있던 시기라 그냥 DC를 얻어와서 화면상에 그려버리면 제아무리 Flash Object라고해도 그 위에 그릴 수 있지않을까 했지만 애초에 C#에서는 사용자가 DC를 직접 컨트롤 할 수 없게 되어있었다. 

뭐 C#에도 Image나 Bitmap같은 클래스가 존재해서 예전에 C++에서 하던 보편적인 작업들은 가능하지만(엄밀히 말하면 해당 클래스들 하부에는 DC를 컨트롤하는 부분들이 있을것이다) 좀 더 하드웨어를 직접적으로 컨트롤 하는 그런 작업들은 마이크로소프트에서 막아둔것이다. 

포인터도 사용은 가능하지만 Visual Studio한테 나 여기서 여기까지 이 영역 안에서만 포인터 직접 쓴다! 하고 고지를 날리면서 작업해야하고.

사실 개인적으로는 둘 중 하나만 파는게 아니고 둘 다 알아야 한다고 생각한다. 예를 들어서 C#에 있는 클래스중에 List<T>라는 클래스가 있는데 이 클래스는 간단히 말해서 동적배열이다. 하지만 C++에서 사용하는것과 달리 선언하는것과 정리하는 작업(애초에 정리가 필요없는 경우가 대부분이다)이 정말 쉽고 동적과 정적으로의 전환이 매우 간단하다. (ToList와 ToArray 한방이면....) 하지만 내부적으로는 C++에서의 동적배열과 거의 유사하기때문에 (아마 기본적인 구조는 linked list일것이다) 포인터나 Linked list를 아예 모른다면 특정 경우에서는 엄청 해맬 수 있다.

결국 C#도 기초를 보면 C++이고 OpenCV같은것들은 C#코드가 따로 있는게 아니고 C++의 라이브러리를 wrapping해서 사용하고 있는 상황이고 말이다.

여하튼 개인적으로 사용할때는 C#을 매우 엄청 많이 즐겨쓰는 편이다. 만약 프로그래밍을 배운다면 C++로 시작하는것보다는 C#으로 학습을 시작해서 기초적인 흐름을 잡고 그 이후에 C++을 배우는것도 나쁘지 않을것이라고 본다. 물론 경우에 따라 다르고 상황에 따라 다르긴 하겠지만...파이선도 쉽고 강력하다고 하지만 개인적으로는 C#쪽이 개발 결과물도 우리가 평소에 보던것과 가깝고 일단 개발환경을 구축하는 난이도가 다르다고 생각한다.

하지만 C#으로 입문해서 거기에 머물러 있는것은 좋지않다고 생각한다. 

필자는 C#으로 먼저 프로그래밍을 배우고 이후에 C++하고 MFC를 배웠는데 C++하고 MFC를 배우면서 불편함도 엄청나게 느꼈지만 아마 C++을 배우지 않았으면 지금보다 개발능력이 현저하게 떨어지는 수준이였을것이다. 지금도 개발능력이 높다고는 못하지만....일단 뭐든 배워서 남주는건 없는것같다. 특히 이 분야는 아는 만큼 보이는것도 많고 느끼는 점들도 많아지는것 같고

며칠동안 열심히 만지고 있지만 확실히 예전에 비해 메리트가 많이 줄었다. 자유도야 늘어나기야 했지만 아직도 답답한 부분이 많고

그 중 가장 답답한 부분은 Xcode가 맥 전용이라 iOS앱 개발을 시도해보려고 해도 일단 맥이 필요하다는점이...유니티 iOS개발도 결국 빌드는 Xcode에서 한다는거같고

Xamarin도 있다지만 안드로이드 스튜디오를 쓰고 느낀거지만 역시 범용보다는 전용이...

일단 모든 조건을 갖춘 완벽한 도구는 있을 수가 없다고 생각하기때문에 단점 위주로 서술...

개인적으로 가장 선호하는 Visual Studio만 해도 가벼운 개발이나 웹개발 쪽에선 확실한 장점이 없고 저사양 컴퓨터에서 돌리기엔 무리가 따른다.

Eclipse의 경우에는 별도로 손을 대서 작업해줘야 하는 부분이 꽤 있어서 썩 좋아하지는 않는다. 기본적인 부분만 사용한다면 문제가 없는 편이지만 가끔 코드를 받아서 보면 특정 플러그인이 필요하다던가 하는 부분도 있으니까 이런 부분은 확실히 번거롭다.

Android Studio는 안드로이드 개발을 위해 개조된 툴인만큼 전반적으로 만족하지만 역시 약간 무거운 편이고...그냥 안드로이드 개발환경 자체에 맘에 안드는 부분들이 있어서 싫은 부분들도 있지만 그런건 이 부분에선 논외고

Unity는 뭐 그냥 편하다...아직 고차원적인걸 만들어보질못해서 고질병이라는 최적화 수준이 낮다는 부분은 아직 체감을 해보지못했다. 하지만 툴 자체의 완성도가 낮다고 느껴질때가 가끔 있다.

Unreal Engine은 퀄리티 자체는 확실히 좋고 맨 처음에 접했던 이미지와는 달리 의외로 유니티보다 빠르게 느껴진다. 툴 자체의 완성도는 이쪽이 훨씬 높지않을까 하고 생각된다. 단점은 나중가면 거기서 거기일거같은 부분들이긴하지만 확실히 유니티에 비해 익숙해지기는 어렵다. 

코딩이야 유니티는 C#기반이고 언리얼은 C++이니까 언리얼쪽이 더 어려울거라고 생각되지만 이거도 좀 더 해봐야 알것이고...

EditPlus는 가볍고 편한 툴이긴하지만 기능추가나 커스터마이징같은 부분이 자유롭지 못한 편이고 확실히 요즘 새로 나오는 툴들에 비해 세련되지 못하다.

AcroEdit는 무료 라이선스에 메모리에 대해서도 훨씬 너그럽지만 뭔가 손에 맞질않는다. 아마 UI가 익숙해지지않는게 가장 큰 이유일거같기도 하다.

Visual Code는 일단 무겁다. 그리고 확장의 개수가 적다. 텍스트 에디터인 주제에 꽤 무겁기때문에 자주 쓰게되질않는다.

Atom은 Visual Code와 근간은 같지만 일단 좀 더 빠르다. 확장의 개수는 많지만 Visual Code도 그렇고 Atom도 그렇고 둘 다 알파벳 문화권 이외의 인코딩들에게 너그럽지 못하다

Sublime Text는 일단 에디트 플러스에 맞먹을 정도로 빠르지만 UI가 직관적이질 못한 느낌을 받는다. 언급한 텍스트 에디터들중 CLI환경에 가장 가까운 느낌을 준다. 사실 개발을 하기 시작하면 대부분의 작업은 단축키로 해결하지만 역시 맨 처음 접할때는 GUI쪽이 훨씬 이해하기도 좋고 간편하니까.

일단 이런 난잡한 환경을 싫어하는 사람들도 있겠지만 나같은 경우는 지금 위에 언급한 도구들에 한해선 다 사용하고있다. 물론 사용빈도가 같지는 않고 자주 사용하는 툴이 있고 자주 사용 안하는 툴이 있지만 저걸로는 안되던데 이걸로는 될까 하는 생각이 들때마다 비교해가면서 그때마다 꺼내쓰고있다.

위에 언급한 것들 말고도 세세한 장단점도 있긴하지만 다 적으려면 시간도 걸리고, 특히 이런 글은 개인적으로 느끼는 점이 강하게 어필되기때문에

어떤 툴이 사람들에게 자주 언급된다면 속는 샘 치더라도 한번쯤은 만져보고 직접 평가하는게 가장 좋다고 생각한다.

일단 현재 해보고 있는 작업에서는 스레드를 추가한 후 해당 스레드로 무한 반복문을 돌려 화면을 지속적으로 캡처하면서 캡처한 화면을 매번 OpenCV 이미지 분석 메소드로 넘긴 후에 결과를 받아오는 식으로 하고있지만 OpenCV의 작업 처리 시간이 생각보다 긴 탓에 현재 개발환경에서 화면 한장을 분석하는데 약 0.9초의 시간을 소모하고있다.

이 경우에는 마우스 커서가 실시간으로 움직이고있는 이미지를 트래킹하는건 조금 무리가 있다고 생각한다. 멈춰있는 이미지의 좌표를 정확히 추적하는데는 이정도만 되어도 충분하다고는 생각하지만...

스레드를 다른방식으로 쓴다던가 아니면 OpenCV에 실시간으로 영상을 트래킹할수있는 기능이 있으면 해당 기능을 사용해서 반응속도를 좀 더 올릴 수도 있다고 생각이 되긴한다.

실제로 OpenCV를 이용한 AR 트래킹은 거의 실시간으로 오브젝트를 추적하는것이 가능하므로 실시간으로 움직이는 이미지를 추적할 방법은 있을거라고 생각되긴하지만...이후는 나중에

뭐 DPI가 무엇인가 하는 등의 기초적인 이야기는 안 하고 넘어가기로 하겠습니다

일단 여기서 이야기할 DPI는 윈도우의 DPI에 대한것.

화면을 캡처해서 캡처한 화면을 인식하는 등의 작업이나 캡처한 화면을 바로 저장해주는 캡처 기능들을 만들 때 그 특정 화면의 윈도우 크기를 알아낼 필요가 있는데

자신의 윈도우 크기를 알아내는건 쉽지만 다른 프로세스의 윈도우 크기를 알아내는건 그것보단 조금 복잡하기때문에 이 부분에 대한 설명도 넘어가기로 하고....

왜 여기서 DPI이야기가 나오느냐 하면 DPI에 따라 이미지를 crop할때 쓰이는 값에 가져온 창 크기값을 바로 적용시킬 수는 없다는 이야기이다.

너무 정직하게 '윈도우의 크기를 뽑아냈으니 그대로 집어넣으면 되겠지' 하고 값을 집어넣으면 예상했던것과는 다른 결과물이 나온다 라는 말을 하고 싶은것이다.

보통 윈도우는 96DPI에 설정이 맞추어져있지만 간혹 다르게 설정되어있는 컴퓨터들이 있다. 주로 노트북에서 설정이 되어있는 것 같고 그 외에는 해상도가 지나치게 높으면 설정을 하는것으로 보인다. 이 경우에는 96DPI에서 캡처하던것처럼 스크린을 캡처하게 되면 이상한 영역이 캡처되게된다.

DPI가 다르기때문에 달라진 배수만큼 원래 Point값을 변조해서 사용하면 문제가 해결되는것을 보고 어느정도 이해는 했지만 좀 더 깔끔한 해결법이나 다른 방법이 있으리라고 생각해본다.

지저분하게 잡설을 늘어놓았지만 결국 하고싶은 말은 스크린을 캡처하는 기능을 프로그램에 넣는다고 하면 컴퓨터의 DPI를 알아내는 부분도 고려해야 할 것이다 라는것이다.

MFC쓰다가도 가끔 충돌이 나서 골이 썩었던 문제지만 MFC에서는 리소스 파일을 직접 수정하는등의 작업으로 해결했다면

자바의 이 문제는 해결할 방법이 오타 찾는거하고 문제를 모두 수정한 후에 모든 캐시를 날려버리는거라는데 이 무슨 미개한......

맨 처음 접했을땐 .NET의 XAML바탕 개발이랑 비슷하다고 느꼈는데 하면할수록 MFC랑 유사점이 많은거같음

연습용으로 끄적거리는 중이긴하지만 프로젝트가 통째로 날아가시게 생겨서 짜증이 두배! ㅎㅎ...

Xamarin의 장점은 일단 아직 익숙하지않은 IDE에 고생할 필요가 없다는 점이겠고

단점은 자마린이 무료로 풀린게 올해 상반기라 아직 자료가 많이 없을 가능성이 높고 커뮤니티 규모도 작을 것이라는 점

ANdroid Studio의 장점은 글로벌하게 사용되는 툴의 사용법을 익힐 수 있다는 점과 이미 많은 강좌가 인터넷에 많이 올라와 있는 부분

단점은 익숙하지않은 개발도구를 사용해야하기때문에 거기서 초래하는 불편이...는 언젠간 넘어야하는 벽이긴하다만

최근 어떤 문제들을 접하게 되서 풀어볼 시간이 좀 있었는데 문제들의 수준이 생각보다 높았고 여러가지 방향에서 생각해야되는 문제들이라 해결하는데 꽤나 애를 먹었다.

동시에 문제를 풀면서 일종의 쾌감 같은것도 느끼긴했지만 역시 코드가 완성되서 완벽하게(최소한 내가 제어하는 범위 내에선) 돌아가는 모습을 볼때의 쾌감이 가장 크겠지...

물론 이 알고리즘이 에러를 뿜고 이상한 결과값을 내고 멋대로 폭주하기 시작하면 그때부턴 또 속이 쓰리겠지만

또 그 문제를 해결하면 기쁨이 올것이고 하지만 그 수정되었다고 생각한것이 또 터지고...머리 앞에당근을 매달아둔 조랑말이 된거같은 기분도 가끔 들지만

이미 블로그에 C#으로 짜여진 동일 이미지 찾기가 있지만 이걸론 반투명 러쉬를 막을수 없는것으로 판단, OpenCV를 투입하기로 결정....

http://blog.acronym.co.kr/558

이미지 분석도 해봐야겠다고 생각했으니 가벼운 튜토리얼 하는 기분으로 시도할생각

간략하게 작성할수있는게 매력적으로 보이고

비주얼 스튜디오에서도 지원해준다는걸 얼마전에 알아서 이거도 배울까 생각이

확실히 개발툴에 너무 매달리는 기분이 들긴하는데 편한건 편한거니까....

왜이렇게 끌리는것도 많고 할것도 많은지.....시간 시간이 부족하다

그래픽카드가 아예 없다는건 불가능한 이야기이지만 여기서는 내장형 그래픽카드와 PCI슬롯에 장착하는 그래픽카드의 차이

당연한 이야기이긴하지만 추가슬롯에 장착하는 그래픽카드의 유무에 따라 같은 프로그램에서 같은 파일을 읽어들이는데도 결과물에 차이가 생긴다

간단한 모델을 돌리거나 광원이 없을때는 문제가 없었지만 확실히 본격적으로 3D실습을 하기에 지금 사용하는 노트북은 부적격...