How to set real-time priority for WebView2 in a Tauri application?

[Think-M]

I have an application scenario with high real-time requirements. In the Rust backend, I attempted to improve real-time performance using the following code:

use windows_sys::Win32::System::Threading::{
GetCurrentProcess, SetPriorityClass, REALTIME_PRIORITY_CLASS,
};

#[cfg_attr(mobile, tauri::mobile_entry_point)]
pub fn run() {
unsafe {
let process = GetCurrentProcess();
SetPriorityClass(process, REALTIME_PRIORITY_CLASS); // 高优先级（需管理员权限）
}

After launching, the Task Manager shows that the Rust process successfully achieved real-time priority, but the WebView2 process remains at normal priority.

How can I elevate the real-time priority of the WebView2 process created by my Tauri application?

[FabianLars]

MicrosoftEdge/WebView2Feedback#4610 not supported directly. i wonder if iterating over all the children processes to find webview2 and then using that same prio api works? (may only work after building the app. in dev the processes are sometimes a bit weird iirc)

[FabianLars]

hmm, can you get the process of a HWND? Can't really remember that part of Windows, but if you can, you could get the relevant hwnd via app.get_webview_window("your-label").unwrap().hwnd() and iterate over its child processes.

[Think-M]

Based on your ideas, I am attempting to obtain the PID of the corresponding label window through the following code:
let hwnd = app.get_webview_window("test-view").unwrap().hwnd().unwrap();
let mut process_id: u32 = 0;
windows::Win32::UI::WindowsAndMessaging::GetWindowThreadProcessId(hwnd, Some(&mut process_id));

However, the obtained PID is actually the PID of the rust process, which seems to have returned to the origin. By traversing this PID and its child processes, the obtained PID is the PID of all window processes, and it seems that it is still impossible to know which PID corresponds to which window.

[Think-M]

The "test-view" window is created in the JS script of the "main" window through the following code:
new WebviewWindow("test-view",{....});

However, the PID of the rust process was found through the GetWindowThreadProcessId function, which seems to be a bug in my opinion. I hope I misunderstood.

[FabianLars]

Is it possible to try to find the webview's hwnd first? It should be a child of that tauri window's hwnd and it should not belong to the rust process anymore (hopefully).

[FabianLars]

there also seems to be a webview2 api for this MicrosoftEdge/WebView2Feedback#2176 though i'm not sure if that's the correct process (you can use the webview2 apis inside https://docs.rs/tauri/latest/tauri/webview/struct.WebviewWindow.html#method.with_webview which is per-window)