博客 / 列表

lindexi - dotnet DirectX 通過可等待交換鏈降低輸入渲染延遲

在 上一篇博客 和大家介紹瞭如何在控制枱裏面用裸 DirectX 做一個簡單繪製折線筆跡的 D2D 應用。此時的 D2D 應用的筆跡延遲還只是能夠追得上 WPF 的筆跡性能，依然有很大的優化空間。本文將在此基礎上，給出一個更低輸入延遲的渲染方案 在一些緊張的射擊類遊戲裏面，遊戲開發者很注重於減少輸入的渲染延遲。對桌面應用來説，也有很多領域有着相同的追求。比如筆跡類白板應用。這些應用都追求着儘快將用

.net , 後端

lindexi - Microsoft Agent Framework 取出 DeepSeek 思考內容

本文提供的方法適用於 DeepSeek 和豆包等模型 前置博客： Microsoft Agent Framework 與 DeepSeek 對接 C# Microsoft Agent Framework 與 豆包 對接 核心原理是從 AgentResponseUpdate 裏面的 RawRepresentation 獲取 reasoning_content 字段 核心代碼如下 AIAg

.net , 後端

lindexi - dotnet 在新進程執行某段委託的方法

大概的 API 設計如下： RemoteExecutor.Invoke(() = { // 在這裏編寫在新進程執行的委託代碼 }); 要在 Main 函數裏面調用 RemoteExecutor.TryHandle 處理命令行，因為新進程裏面執行的邏輯本身就需要 Main 函數參與。標準預期寫法如下 if (RemoteExecutor.TryHandle(args)) { ret

.net , 後端

lindexi - 記調試 RX-Explorer-WAS 文件管理器 UI 未響應問題

開始之前，先提供 RX-Explorer-WAS 的安裝地址，通過應用商店即可安裝： https://apps.microsoft.com/detail/9pdn2q3dcqs3 在我設備上覆現打開黑屏問題的界面如下圖 此時非常快速的第一反映就是打開 Visual Studio 進行附加調試。有開發環境的機器上，就不要去打 DUMP 分析了，通過 DUMP 分析是不如直接用開發機的 Visual

.net , 後端

lindexi - dotnet Vortice 無需交換鏈與 DirectComposition 對接渲染層

在 DirectComposition 裏面提供了 Commit 機制，一次 Commit 的所有內容都能在相同的一幀在屏幕顯示出來，如此可以非常方便地完成渲染對齊任務 通過 WaitForCommitCompletion 方法可以等待 Commit 內容完成渲染，此方法作用相當於等待交換鏈寫法的等待垂直同步實現 在 上一篇博客 中，採用了傳統的 DXGI 交換鏈與 DirectCompositi

.net , 後端

lindexi - dotnet Vortice 通過 Angle 將 Skia 和 DirectX 對接

ANGLE 是谷歌開源的組件，提供將 OpenGL ES API 調用轉換為實際調用 DirectX 引擎執行渲染的能力。詳細請看： https://github.com/google/angle 整體的步驟是： 基礎且通用地創建 Win32 窗口 初始化 DirectX 相關，包括創建 DirectX 工廠和 DirectX 設備，枚舉顯示適配器等 初始化 Angle 和與 Direct

.net , 後端

lindexi - Avalonia 簡易對比不同的 Win32CompositionMode 的性能情況

測試代碼非常簡單，只是嘗試修改一個控件的背景色，讓界面不斷更新而已 以下是 MainWindow.axaml 代碼 Window xmlns="https://github.com/avaloniaui" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:d="http://schemas.mi

.net , 後端

lindexi - 對比 Avalonia 和 WPF 的渲染延遲

此測試發現了 WPF 的渲染非常跟輸入，而 Avalonia 明顯落後 在我的測試用例裏面，特別讓 Avalonia 窗口去接收輸入，讓 Avalonia 驅動 WPF 的界面。如此可以排除 Avalonia 的輸入層帶來的延遲。完全只對比 Avalonia 和 WPF 的渲染層 詳細請參閲： https://github.com/AvaloniaUI/Avalonia/discussions/2

.net , 後端

lindexi - WPF 使用 Vortice 在 D3DImage 顯示 D2D 內容

本文絕大部分代碼來源於 Raspberry Monster 夥伴提供。我只是代為記錄的工具人 本文是渲染相關係列博客中的一篇，該系列博客已按照邏輯順序編排，方便大家依次閲讀。本文屬於系列博客中，比較靠前的博客，可以獨立閲讀，無上下篇依賴。如您對渲染相關感興趣，可以通過以下鏈接訪問整個系列：渲染相關係列博客導航 在開始聊 Vortice 之前，必須要先聊聊 SharpDx 庫。 眾所周知，現在 Sh

.net , 後端

lindexi - Vortice 使用 DirectComposition 顯示透明窗口

本文是渲染相關係列博客中的一篇，該系列博客已按照邏輯順序編排，方便大家依次閲讀。如您對渲染相關感興趣，可以通過以下鏈接訪問整個系列：渲染相關係列博客導航 在 DirectX 使用 Vortice 從零開始控制枱創建 Direct2D1 窗口修改顏色 博客中和大家介紹了最簡方式創建了窗口和對接了 DirectX 層。在此基礎上，大家也能看到此時創建的窗口是無法應用透明背景效果的 即使強行設置 Swa

.net , 後端

lindexi - Microsoft Agent Framework 與 DeepSeek 對接

準備工作 先使用手機號在 https://platform.deepseek.com 上註冊賬號 最後進入充值頁面充值。如果沒有充值，則後續 API 調用會返回 402 錯誤 最後進入 https://platform.deepseek.com/api_keys 創建 API key 且複製出來，後續步驟將會用到 安裝庫 按照 .NET 的慣例，使用前先使用 NuGet 安裝對應的庫 Micr

.net , 後端

lindexi - dotnet 10 已知問題 WinForms 的 TargetFramework 與 System.Drawing.Common 不匹配將拋出找不到類型異常

此問題我已經在 WinForms 倉庫反饋： https://github.com/dotnet/winforms/issues/14145 最簡復現步驟如下： 先創建一個空的 .NET 項目，編輯 csproj 文件，替換為以下代碼 Project Sdk="Microsoft.NET.Sdk" PropertyGroup OutputTypeExe/OutputType

.net , 後端

lindexi - Office 已知問題 GROOVEEX.DLL 帶崩進程

這是一位老師向我反饋的問題，我的一個 WPF 應用程序在他的設備上，任何彈出保存文件對話框或打開文件對話框的功能，都會導致進程閃退。經過進一步調查，我發現他電腦上任何軟件彈出文件保存對話框都會閃爍，問題本身和 WPF 無關。最終調查到是 Office 的一個注入組件導致的問題 問題現象： 任何 32 位應用程序調用 Win32 的保存文件對話框或打開文件對話框時，將會導致進程閃退 問題分析： 通過

操作系統

lindexi - dotnet 讀 WPF 源代碼 學習使用 Microsoft.DotNet.Arcade.Sdk 處理代碼裏的多語言

在 WPF 開源代碼裏面，可以看到是從各個項目的 Strings.resx 和對應的 xlf 文件，生成對應項目的多語言程序集。這裏的多語言程序集可用於拋出異常時，給出本地化的消息提示 在 dotnet 龐大的生態集裏，打包工具鏈是開源中很重要的部分工作。通過 https://github.com/dotnet/arcade 將打包中重複的工作放在一個倉庫中，減少基礎設施能力在多個項目中重複進行。

.net , 後端

lindexi - ASP.NET Core 製作一個低資源佔用的支持超大文件表單上傳的服務

上傳文件到服務器的經典方法是採用表單上傳的方式 在 ASP.NET Core 的默認實現中，無論是直接在參數上寫 FromFormAttribute 配合 IFormFile 接收文件，還是通過 HttpRequest.ReadFormAsync 方法，對於客户端傳入的大文件，都會先緩存到磁盤裏面。這也就是為什麼會有一些開發者會誤認為使用 IFormFile 類型屬性時，可以立刻接收到客户端發送過

.net , 後端