Archive for the ‘Windows’ Category
When MSDN document doesn’t answer your question on how to handle DirectWrite text layout, this great blog post can help you.
What is even better is that it has fully working sample project.
The solution file can be built using Visual Studio 2013.
Marg Gregoire’s Blog : Introduction to DirectWrite
On most PC tech magazines and tech blogs, they say Windows 10 brought Start menu back and got rid of ‘Start Screen’.
However, actually the answer should be ‘Yes’ and ‘No’.
Most English-speaking people I have met so far tend to consider only surface of issues, not the implication of an issue or another aspects under the surface.
I know what kind of answer they want. But if I just answer so, I know that they will not understand things correctly. On the other hands, Koreans ( not current young generations, but till the generation I’m in ) tend to understand by applying individual case which is mentioned in broader way. In other words, if one things is explained, Koreans tend to apply it for broader case and tries to figure out if it can be true for that broadened case. Then they find the optimal boundary where it can be applied.
Back to the Windows 10 stuff..
The Start menu have integrated Start Screen. So, depending on how you see it, you can say it’s still there or there is no Start Screen.
There is another aspect.
On desktop, you can set “Tablet mode” forcefully.
Then the Start Screen appears like Windows 8.x.
However, the reason MS brought its Start menu back in Windows 10 and thus put the precedence of Start Screen backward is that users complaint about the awkwardness of Start screen on desktop and inconvenience of not having Start menu.
So, I don’t think there will be more people to turn on tablet mode on desktop environment.
So, although the Start Screen is there, it will be more rational to say “there is no Start Screen” for most users.
Probably it’s the reason most magazines and blogs for PCs describe that Windows 10 ( for desktop ) don’t have Start Screen and superseded by new Start menu on steroid.
I was trying to figure out how to create ID2D1Bitmap1 instance which is to be mapped to memory region. But I found out that MSDN documentation put me in self-repeating cycle ( so, I call it squirrel treadwheel. ). In on document it says, the options can’t be used for bitmap instance created with ID2D1DeviceContext, while on the other page, the device context is to be used to create ID2D1Bitmap.
I posted this to MSDN page, ID2D1Bitmap1::Map page.
“These flags will be not be able to be used on bitmaps created by the ID2D1DeviceContext”
However on this “ID2D1Bitmap1 interface” page, it says :
Creating ID2D1Bitmap Objects
Use one of these methods to create an ID2D1Bitmap object.
It’s a squirrel’s wheelmill. Don’t you think so?
( this flags can’t be created by ID2D1DeviceContext => on other page, ID2D1Bitmap1 is created using those device context.)
Moreover, throughout Direct2D/DirectWrite and related technology pages, it’s not clear whether methods/functions returns using a parent class pointer ( like ID2D1Bitmap *) can actually return one for its child class instance like ID2D1Bitmap1. By trial and error, I found out that it’s strictly for the stated class. It’s better to be documented. ( Especially you guys are aware of that C++ has supported late binding.)
Secondly, for this issue on how to create ID2D1Bitmap1 with D2D1_MAP_OPTIONS_READ, and thus D2D1_BITMAP_OPTIONS_CANNOT_DRAW | D2D1_BITMAP_OPTIONS_CPU_READ specified in creating an instance of ID2D1Bitmap1, I found some answer here.
The post marked as “Answers”, he created an instance of ID2D1Bitmap1 using CreateBitmap() method of ID2D1DeviceContenxt. It’s opposite to what is mentioned on this page. ( for your convenience, I put it on the top. This document clearly said “These flags will not be able to be used on bitmaps created by ID2D1DeviceContext.” ) You can see that the ID2D1Bitmap1 is created using the device context’s CreateBitmap() method, and it has CPU_READ and CANNOT_DRAW option, and when Map() is called, D2D1_MAP_OPTIONS_READ is specified.
I will test this. But because people marked it as an “Answer”, I sort of believe that it works.
Didn’t it say that D2D1_MAP_OPTIONS_READ is not available for bitamps created by ID2D1DeviceContext?
Come on, Microsoft people! What are you guys thinking about? Do you guys really think the MSDN document is good?
It’s also creating ID2D1Bitmap1 by “ID2D1DeviceContext”.
On Windows 7 and earlier, you use a ID2D1HwndRenderTarget or another render target interface to render to a window or surface. Starting with Windows 8, we do not recommend rendering by using methods that rely on interfaces like ID2D1HwndRenderTarget because they won’t work with Windows Store apps. You can use a device context to render to an Hwnd if you want to make a desktop app and still take advantage of the device context’s additional features. However, the device context is required to render content in a Windows Store apps with Direct2D.
- Windows 7 and earlier : ID2D1*RenderTarget are expected to be used to render drawing primitives/text etc.
- Windows 8+ : Device context are expected to be used, because those ID2D1*RenderTargets don’t work for Windows Store apps.
Question 1: Why are classes/interfaces for drawing affected by Windows Store? Technically Windows Store is for selling S/W. They may require some, but is there any valid reason to prevent some drawing classes/interfaces from being used?
Question 2: If it’s that critical, shouldn’t there be any warning message on ID2D1*RenderTarget MSDN pages, at least on their 1st page?
Question 3: So, if you are not going to sell your S/W on Windows store infrastructure, you don’t have those restrictions, right? (Anyway Windows store doesn’t look to draw people’s attention as much as Apple’s app store. So, it will not serve as “People, you don’t know where to find your Windows app, come here!” role.
MS는 참 웃기는 것이..
Windows SDK를 Win 7때는 Microsoft SDK 폴더에 다 설치하더니, Win 8 SDK는 .NET쪽은 여전히 거기에, 그 외는 Windows Kit에 설치한다.
그래서 Win 7은 DirectX/2D/3D등이 Microsoft SDK에 있고, Win8 SDK는 Windows Kits에 있다.
문제는 레지스트리에서 여전히 Microsoft SDK에 가서 헤더나 라이브러리를 찾게 되어 있다.
그렇기 때문에, Win 8 SDK를 VS 2012등에 설치하면 제대로 설치된 SDK를 인식 못한다.
도대체 왜 이러냐 MS? 좀 일관적으로 해라.
사람이 많이 들러 붙어서 만드니까, 어느 정도 바보 같은 것이 있는 것은 이해한다.
근데 가만 보면.. 안드로이드나 윈도우즈 쪽은 서로 비슷한 데가 있다.
버그가 생기거나 이렇게 일관성 없는 일이 생길 때 보면, 얘네들은 뭔가 개념이 없어 보인다.
반면에 애플쪽에서 생기는 문제는, 문제를 인식은 하고 있는데, 시간이 없어서 못하는 느낌이 나고.
적어도 접촉을 해봐도, 애플 쪽은 답변이 비교적 감을 잡고 온다. (물론 최근 5년 사이엔 무척 후져졌다. Xcode 4 이래로. Xcode 4를 누가 만든지 안다. 애플 내에서도 잡음이 많았던 것으로 안다. 버그 리포팅을 하면 오는 답변의 태도나 방식이 이전에 비해 엉망이다.)
하지만 MS쪽이나 Android 쪽/전반적 구글쪽은 그렇지 못하다.
그래도 예전에 구글에서 Picasa app 나오고 할 땐 괜찮았는데. S/W에 개념이 있는 회사라고 생각했는데…
한쪽만 이야기 하면, 윈빠네, 애플빠네들 소리들 할 거 같은데.. 난 윈도우즈, 맥, 유닉스 다 하는 사람이고..
선호하는 플랫폼은 있어도, 무조건 한쪽을 좋다하진 않는다. 나같은 사람이 미국에서도 엄청 적더라. 말이 엔지니어들이지 빠들에 가까워서.. 자기가 싫어하는 플랫폼 쪽은 무조건 나쁘다하는 사람들이 태반이다.
그러니 문제를 공론화하기도 참 힘들다.