Debugging Mlt framework in VSCode

Crossing platform with built in tool chain

Coming up soon (maybe)

Gitsoler 1.1 - Split View supported: https://marketplace.visualstudio.com/items?itemName=gandalfliang.gitsoler

翻译自己的文章才是最骚的。。。 Origin Post

要实现一个透明的 WPF 窗口？
多么简单的一个任务啊！只要设置 AllowTransparency 和 WindowStyle，你可以在毫秒间完成这个任务。

AllowTransparency="True" WindowStyle="None" Background="Transparent"

正确吧？当然。
但是（你懂得），打开你的任务管理器看看，简单的任务通常会带来大量的内存占用，特别是4K分辨率的透明窗口。100+ MB的内存被浪费了，就只为了显示一个空白的透明窗口！这是不可接受的。一年前，如果你说：”谁关心内存呀，现在的内存条太便宜了”，你可能是对的。但是查查这一年内存条的价格走向，它们现在贵上天了。

WPF 透明窗口的有趣小真相

• 内存占用随着窗口尺寸增大而增加
• Win32 窗口没有这样的问题

等等，什么？窗口越大，内存消耗的更多？嗯。。。这看起来很熟悉嘛，就像一个Bitmap。知道现在，我们并不知道 WPF 是如何处理透明窗口的，但是这种症状显示它就好像直接将整个桌面作为一个位图，然后窗口用这张位图的重叠部分作为其背景来更新自己，让它看起来是“透明”的。多么聪明的做法呀。。。
在 WPF 刚刚发布的那些日子里，低分辨率的计算机屏幕占据主流位置，即使在今天，大多数的笔记本电脑依然带着一块1366*768分辨率的屏幕被推向市场（离谱吧）。让我们唾弃那些OEM厂商讲的毫无根据的废话并且思考一下运行在高分辨率下的程序的情况。

内存并不是免费的，不要浪费之

很显然，浪费100+MB的内存来显示一个4K的透明窗口是不可接受的，特别是和 Win32 窗口只占用10+MB的内存进行比较时。这差距让 WPF 看起来蠢透了。
抱怨已经够多了，想想对此我们能做什么呢？我可不想用C++和GDI将我的UI代码重写一遍，这太没效率并且也跟不上时代，况且，没人会为此“区区小事”去放弃他们漂亮、易于维护的Xaml UI代码。

使用 Win32 承载 WPF 内容

好吧，确实，没人愿意为了区区90MB内存去重写它们的UI。与使用C++重写UI所耗费的精力相比，这个内存的占用差距看起来是可以接受的（#笑脸）。但是请记住，我们一如既往的可以在 Win32 窗口中承载 WPF 的内容。
例如，我们想创建一个全屏、半透明背景带着非透明内容的对话框。为了规避 WPF 透明窗口的内存问题，我们可以使用 Win32 创建一个半透明的窗口：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

DWORD Flags1 = WS_EX_LAYERED;
DWORD Flags2 = WS_POPUP;

HWND hWnd = CreateWindowEx(Flags1,szWindowClass, szTitle, Flags2,
    CW_USEDEFAULT, 0, 3840,2160, nullptr, nullptr, hInstance, nullptr);

SetLayeredWindowAttributes(hWnd, RRR, (BYTE)125, LWA_ALPHA);
ShowWindow(hWnd, nCmdShow);
UpdateWindow(hWnd);

case WM_ERASEBKGND:
    RECT rect;
    GetClientRect(hWnd, &rect);
    FillRect((HDC)wParam, &rect, CreateSolidBrush(RGB(0, 0, 0)));
    break;

通过启用 C++/CLI，我们可以直接访问 WPF 内容

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

namespace ManagedCode
{
    using namespace System;
    using namespace System::Windows;
    using namespace System::Windows::Interop;
    using namespace System::Windows::Media;

    HWND GetHwnd(HWND parent, int x, int y, int width, int height) {
    HwndSource^ source = gcnew HwndSource(
        0, // class style  
        WS_VISIBLE | WS_CHILD, // style  
        0, // exstyle  
        x, y, width, height,
        "hi", // NAME  
        IntPtr(parent)        // parent window   
    );

    UIElement^ page = gcnew ManagedContent::WPFContent();
    source->RootVisual = page;
    return (HWND)source->Handle.ToPointer();
    }
}

最后

1
2

//managed content
ManagedCode::GetHwnd(hWnd, 0, 0, 200, 200);

由于 WPF 和 GDI 背后的技术不尽相同，还有更多的工作需要做来解决不可避免的透明通道问题，但是，为了方便，你始终可以使用 Popup 来实现你的目标。

Macbook Pro 2016 的键盘真垃圾。。。。。。

Let’s create a light weighted wpf drop shadow effect, considering that the origin one performs badly in some special occasions.
As I mentioned before (check it out), the original WPF DropShadow Effect can cause severe preformance problem. Due to the “flaw” M$FT brought to the HLSL support for WPF, the Effect class that implements the visual effect creates and destroy GPU resource each frame, which is the worst thing you could do with GPU resources. So, what about implementing a custom shadow effect to avoid it? This sounds interesting.

– 春节补充

要实现一个透明的 WPF 窗口？
What an easy task! By setting AllowTransparency and WindowStyle, you could finish it in seconds.

AllowTransparency="True" WindowStyle="None" Background="Transparent"

Correct? Of course.

However (you know this is coming), look at your task manager, easy task comes with large memory consumption, especially for 4K transparent window. 100+ MB ram are wasted for just showing an empty, transparent window! That’s unacceptable. A year ago, you might be right saying “Who cares about RAM, they are cheap as hell”, but check out the price they’ve grown over this year, they are expensive as hell now.

Fun fact of WPF transparent window

• RAM usage increase as window size enlarge
• Win32 window has no such problem

Wait, what? The larger the window is, the more RAM it consumes? Hmmmmm… this looks familiar, just like a Bitmap. For now, we don’t know how WPF handles transparent window, but the symptom shows that it’s like using the whole screen as a bitmap and the window updating itself with portion of that bitmap, making it “transparent”. What a smart move…
Back in the days when WPF was first released, low screen resolution was the main stream. Even today, most laptops still are shipping with a monitor of 1366*768 (ridiculous, right?). Let’s despise the nonsense the OEM told us and think about program running in computers with higher screen resolution.

RAM is not free, do not waste it

Obviously, costing 100+ mb of ram for showing a transparent window in 4K is unacceptable, especially compared with Win32 transparent window, which costs only 10+ mb. The gap between them makes WPF look dump.
Enough complaining, what can we do about it? I don’t want to write UI code with GDI using C++, that’s inefficient and not modern, plus, no one would abandon their beautiful, easy to maintain xaml UI code for this.

Hosting WPF content in Win32 Window

Well, indeed, no one would rewrite their UI code for just about 90mb of RAM. Compared with the work needed to rewrite C++ UI code, the RAM consumption gap seems acceptable (#smile face). But please remember, we can always host WPF content in win32 window.
Let say, we want to create a full screen notification dialog with semi-transparent background and apaque notication content in the center. To avoid the WPF ram problem, we create a semi-transparent window using win32:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

DWORD Flags1 = WS_EX_LAYERED;
DWORD Flags2 = WS_POPUP;

HWND hWnd = CreateWindowEx(Flags1,szWindowClass, szTitle, Flags2,
    CW_USEDEFAULT, 0, 3840,2160, nullptr, nullptr, hInstance, nullptr);

SetLayeredWindowAttributes(hWnd, RRR, (BYTE)125, LWA_ALPHA);
ShowWindow(hWnd, nCmdShow);
UpdateWindow(hWnd);

case WM_ERASEBKGND:
    RECT rect;
    GetClientRect(hWnd, &rect);
    FillRect((HDC)wParam, &rect, CreateSolidBrush(RGB(0, 0, 0)));
    break;

By enabling C++/CLI, we can access WPF content directly

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

namespace ManagedCode
{
    using namespace System;
    using namespace System::Windows;
    using namespace System::Windows::Interop;
    using namespace System::Windows::Media;

    HWND GetHwnd(HWND parent, int x, int y, int width, int height) {
    HwndSource^ source = gcnew HwndSource(
        0, // class style  
        WS_VISIBLE | WS_CHILD, // style  
        0, // exstyle  
        x, y, width, height,
        "hi", // NAME  
        IntPtr(parent)        // parent window   
    );

    UIElement^ page = gcnew ManagedContent::WPFContent();
    source->RootVisual = page;
    return (HWND)source->Handle.ToPointer();
    }
}

and finally

1
2

//managed content
ManagedCode::GetHwnd(hWnd, 0, 0, 200, 200);

Due to the different technologies behind WPF and GDI, more work needed to be done for the unavoidable alpha blending problem, but, you can use wpf popup to achieve your goal for short.

高斯模糊（ https://zh.wikipedia.org/wiki/%E9%AB%98%E6%96%AF%E6%A8%A1%E7%B3%8A ）是一种常见的图像处理算法，使用高斯分布与图像做卷积，得到模糊的效果。其二维定义：

σ是正态分布的标准偏差。在应用的时候，假设σ为2.5。对于模糊半径为1，则高斯矩阵为3*3的一个矩阵，以[1,1]为中心，带入公式计算高斯矩阵的值，得到：

鉴于 .NET Standard 2.0 已经支持大量的.NET api，移植CLOO已经是毫无难度的一件事情 Github

CLOO使用p/invoke方式调用opencl api，但是对于不同平台下，opencl 的名称并不一致，例如在linux下为libOpenCL.so，Windows下为OpenCL.dll，且 .NET Standard 没有提供 Mono 类似的 dllmap 模式，因此，现在来说还不能达到用一个package，在所有平台引用的目的。

Gitsoler - a Visual Studio extension, now goes public: https://marketplace.visualstudio.com/items?itemName=gandalfliang.gitsoler