#[Tauri v2] Disabling hardware acceleration on some windows

168 messages · Page 1 of 1 (latest)

stiff sinew
#

Heya! I wrote an OBS overlay app, but OBS's window capture cannot capture any of my overlay windows because they have hardware acceleration enabled by default. I've looked for about 2 hours now and all I could find was the --disable-gpu browser arg, which causes the windows to immediately close every time I open them. I've also tried having a look around some of the webview stuff (using Window#with_webview) and I couldn't find anything there either.

Is there any good, reliable way to disable hardware acceleration? Or at least get my windows to capture in OBS? (yes, I'm using the "Windows 10" capture method)

stiff sinew
#

[Tauri v2] Disabling hardware acceleration on some windows

sonic pagoda
#

where did use the --disable-gpu flag?

stiff sinew
#

As soon as the window opens, it immediately closed and cannot be created again

sonic pagoda
#

try putting it in tauri.config.json like:

"windows": [
{
...,
"additionalBrowserArgs": "--disable-gpu"
}
]
stiff sinew
#

Sure, one sec

#

Nope, same thing

#

Alongside obviously making every update in the main window take forever

sonic pagoda
#

can you provide the console log for when you try and run it?

stiff sinew
stiff sinew
sonic pagoda
#

run with --verbose

stiff sinew
sonic pagoda
#

open the browser console too

stiff sinew
#

Of the main window?

sonic pagoda
#

inspect element

#

yeah

stiff sinew
#

Nothing

sonic pagoda
#

make sure you have it open while trying to open the overlay

stiff sinew
#

Yep, I did

#

Opened it right before clicking the button

sonic pagoda
#

and if you get rid of the gpu stuff, the overlay opens fine?

stiff sinew
#

Yep

#

I should mention that this same code, including capturing the window in OBS, worked fine with Tauri v1

#

Meaning that I didn't need to disable hardware acceleration in the first place ^^

#

Issue only started happening after migrating

sonic pagoda
#

what happens if you use a browser source in obs? can you select the overlay like that

stiff sinew
sonic pagoda
#

try?

stiff sinew
#

Yeah, it seems like I can use a browser source for it

sonic pagoda
#

functions as intended?

stiff sinew
#

No, because it relies on the app window

sonic pagoda
#

youre going to have to be more specific

stiff sinew
stiff sinew
sonic pagoda
#

the overlay window that you are creating IS a tauri window

#

which means that the API should work as intended

stiff sinew
#

Yes, and the OBS browser source only renders a webpage

#

Meaning that it's not capturing the Tauri window itself

sonic pagoda
#

your best bet is setting up logging and figuring out why its closing

stiff sinew
sonic pagoda
#

can you share the code here that opens the window?

#

in text, not image

stiff sinew
#
pub fn maybe_open(&mut self) -> Result<(), Error> {
    if self.app.get_webview_window(&self.label).is_none() {
        WebviewWindowBuilder::new(
            &self.app,
            self.label.clone(),
            WebviewUrl::App(self.url.clone().into()),
        )
        .title(self.title.clone())
        .transparent(true)
        .resizable(false)
        .inner_size(800.0, 600.0)
        .skip_taskbar(true)
        .center()
        .build()?;
    }

    Ok(())
}
sonic pagoda
#

try making the function async

stiff sinew
#

No difference

sonic pagoda
#

what happens when you .unwrap instead of ?

stiff sinew
#

Again, no difference

#

No panic

sonic pagoda
#

what happens when you try and open the second webview window on startup by adding it to the config?

stiff sinew
#

One moment

#

Still closes

#
"windows": [
    {
        "minWidth": 1280,
        "minHeight": 720,
        "center": true,
        "fullscreen": false,
        "resizable": false,
        "title": "DiscOverlay",
        "decorations": false
    },
    {
        "minWidth": 800,
        "minHeight": 600,
        "fullscreen": false,
        "resizable": false,
        "title": "Voice Overlay",
        "decorations": true,
        "label": "voice",
        "url": "http://localhost:5173/voice-overlay",
        "transparent": true,
        "additionalBrowserArgs": "--disable-gpu"
    }
],
sonic pagoda
#

and that same config but without disable gpu works?

stiff sinew
#

Yep

sonic pagoda
stiff sinew
#

With and without verbose mode

sonic pagoda
#

do -vvv

stiff sinew
#

Nothing, again

sonic pagoda
#

what happens when you navigate to the url http://localhost:5173/voice-overlay in your browser when the app is open

stiff sinew
#

It's just a brown page

sonic pagoda
#

is that what you should be seeing, excluding the loss of functionality?

#

can you tauri info and share that here

stiff sinew
stiff sinew
# sonic pagoda can you `tauri info` and share that here
[✔] Environment
    - OS: Windows 10.0.22631 x86_64 (X64)
    ✔ WebView2: 128.0.2739.79
    ✔ MSVC: Visual Studio Community 2022
    ✔ rustc: 1.79.0 (129f3b996 2024-06-10)
    ✔ cargo: 1.79.0 (ffa9cf99a 2024-06-03)
    ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
    ✔ Rust toolchain: stable-x86_64-pc-windows-msvc (environment override by RUSTUP_TOOLCHAIN)
    - node: 22.6.0
    - pnpm: 9.4.0
    - npm: 10.8.2

[-] Packages
    - tauri 🦀: 2.0.0-rc.15
    - tauri-build 🦀: 2.0.0-rc.12
    - wry 🦀: 0.43.1
    - tao 🦀: 0.30.0
    - tauri-cli 🦀: 2.0.0-rc.16
    - @tauri-apps/api : 2.0.0-rc.0
    - @tauri-apps/cli : 2.0.0-rc.16

[-] Plugins
    - tauri-plugin-single-instance 🦀: 2.0.0-rc.4
    - @tauri-apps/plugin-single-instance : not installed!

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../build
    - devUrl: http://localhost:5173/
    - framework: Svelte
    - bundler: Vite
sonic pagoda
#

cargo update

stiff sinew
#

Still closes

#
[✔] Environment
    - OS: Windows 10.0.22631 x86_64 (X64)
    ✔ WebView2: 128.0.2739.79
    ✔ MSVC: Visual Studio Community 2022
    ✔ rustc: 1.79.0 (129f3b996 2024-06-10)
    ✔ cargo: 1.79.0 (ffa9cf99a 2024-06-03)
    ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
    ✔ Rust toolchain: stable-x86_64-pc-windows-msvc (environment override by RUSTUP_TOOLCHAIN)
    - node: 22.6.0
    - pnpm: 9.4.0
    - npm: 10.8.2

[-] Packages
    - tauri 🦀: 2.0.0-rc.15
    - tauri-build 🦀: 2.0.0-rc.12
    - wry 🦀: 0.43.1
    - tao 🦀: 0.30.1
    - tauri-cli 🦀: 2.0.0-rc.16
    - @tauri-apps/api : 2.0.0-rc.0
    - @tauri-apps/cli : 2.0.0-rc.16

[-] Plugins
    - tauri-plugin-single-instance 🦀: 2.0.0-rc.4
    - @tauri-apps/plugin-single-instance : not installed!

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../build
    - devUrl: http://localhost:5173/
    - framework: Svelte
    - bundler: Vite
```it appears there was nothing to update either
heady jolt
#

changing additionalBrowserArgs typically means you have to change the webview's data folder (if you have multiple webviews at least) which you can only do by spawning the window in rust

#

though i have to say it's quite confusing that you only have to disable acceleration in v2 as there were no relevant changes in v2 that should matter here

stiff sinew
#

I should mention, I obviously had to switch OBS's capture method to "Windows 10" (which supposedly is meant to work for hardware accelerated windows + support transparency) when using v1

#

With v2, the Window Capture outright has no content and the other capture method options just result in a blacked out window (whereas, iirc, with v1 it'd still show the window content at least, just without transparency)

heady jolt
#

can you try it with tauri's unstable feature flag? Can't remember if that changed the webview->window injection method or not but worth a try.

stiff sinew
#

Sure thing, one moment

#

No OBS capture still

And the window still immediately closes if I add the arg

heady jolt
#

No OBS capture still
That makes no sense to me then, either stable or unstable should match the v1 behavior unless there was a change i missed. :/
And the window still immediately closes if I add the arg
Which i am fairly sure is because of the data dir i mentioned above.

stiff sinew
heady jolt
#

which is a good thing because otherwise you couldn't change the data dir

sonic pagoda
#

what is the data_directory exactly?

heady jolt
#

the webview's data/cache/storage dir

#

everything the webview may have to write to disk (not including tauri's js apis) will be written to that dir

#

and for some reason 2 webviews with different browser args can't share the same dir

sonic pagoda
#

weird

#

given that the reason for that behavior is unknown, how would one go about uncovering it?

heady jolt
#

not just maybe :P

stiff sinew
#

Wouldn't explain (to me) why the other webview window closes itself, though

#

If it's sharing data with the main window, my assumption would be that it would simply not use the new arg

sonic pagoda
#

if both webviews have --disable-gpu as the browser args, then it should be able to share the data dir?

heady jolt
#

yes, as long as the args (including the "no args" option) match the data dir can be shared

#

but once 2 processes try to access the same dir with different args it'll explode

#

now why the first process crashes and not just the second doesn't make much sense to me either but doesn't matter either really, at least one of them has to crash i guess

sonic pagoda
#

well that sounds like a bandaid solution for Deftu, given the looks of their app it doesnt seem like acceleration is needed.

#

but it still doesnt explain why its not playing nice with OBS when it should

heady jolt
sonic pagoda
#

queer bug

#

no way i would have ever figured this out

stiff sinew
#

Me neither

#

What I found weirder is that there's a difference (here) between v1 and v2

#

There were several differences, actually

sonic pagoda
#

i guess for now just try out this solution and let us know if it works

heady jolt
#

didn't find an existing one at least

stiff sinew
#

Sure thing, which repo would that be on?

heady jolt
#

the main tauri repo

stiff sinew
#

Alrighty, will do

heady jolt
#

thanks

stiff sinew
#

Alright so it didn't crash this time, thankfully

#

But it's still not capturing anything in OBS

#

Now I'm really confused lol

heady jolt
#

what made you think that hardware acceleration was the issue?

#

i didn't read the full convo

sonic pagoda
#

its a known thing

#

TLDR

stiff sinew
sonic pagoda
#

electron has issues too

stiff sinew
#

BUT there was a "Windows 10" capture method added which was meant to fix this

#

But that doesn't seem to be working

sonic pagoda
stiff sinew
#

It seems to be capturing the main window fine, which is also confusing

#

Maybe it's the transparency?

heady jolt
#

works in my app with transparency

stiff sinew
#

Here's the function I use for opening the window

pub fn maybe_open(&mut self) -> Result<(), Error> {
    if self.app.get_webview_window(&self.label).is_none() {
        WebviewWindowBuilder::new(
            &self.app,
            self.label.clone(),
            WebviewUrl::App(self.url.clone().into()),
        )
        .title(self.title.clone())
        .transparent(true)
        .resizable(false)
        .inner_size(800.0, 600.0)
        .skip_taskbar(true)
        .additional_browser_args("--disable-gpu")
        .data_directory(self.data_dir())
        .center()
        .build()?;
    }

fn data_dir(&self) -> PathBuf {
    let mut path = self
        .app
        .path()
        .app_data_dir()
        .expect("Failed to get app data dir");
    path.push("overlays");
    path.push(&self.label);
    if !path.exists() {
        std::fs::create_dir_all(&path).expect("Failed to create app data dir");
    }

    path
}
```~~I doubt that's the correct data dir but it's functional atm~~
sonic pagoda
#

did you try disabling transparency on the second window?

stiff sinew
#

I haven't, no

#

One sec

#

I found the issue concern

heady jolt
#

what

stiff sinew
#

OBS is the bane of my existence

#

This is just evil atp

#

Keep in mind, I was setting this in v1 too

#

And there were no issues. I'd assume that it wouldn't even give me the option to select the window if this is why it can't capture it

#

Or, maybe this is a Windows problem

sonic pagoda
#

so since you had that enabled, it wouldnt show in obs?

stiff sinew
#

Yep

sonic pagoda
#

oy

#

so gpu can stay on

stiff sinew
#

Yep, thankfully

#

Should I still open an issue about it?

heady jolt
stiff sinew
#

Could be. I'm sure something was changed at some point down the line which may affect that. Very peculiar issue, though

heady jolt
#

interestingly enough, with setSkipTaskbar true the "old" window capture method works fine.

#

so basically setSkipTaskbar decides whether you have to use bitbit or win10

#

which again, makes no sense to me x)

stiff sinew
#

I'd safely assume that's an OBS issue then lol

heady jolt
#

i'll compare it with v1 too real quick

#

okay, almost the same behavior except that i can't record anything in v1 with skipTaskbar true kkushKEKW

#

though bitbit at least tries to. with skipTaskbar false it's black, and with true it's white

#

so maybe check that out too before creating an issue?

stiff sinew
#

I have a released binary here which has working recording ^^

#

Or, it worked for my friend and I at least

#

Don't mind how incredibly messy the code is there lol

#

Basically rewritten everything since, was just trying to get a working MVP

heady jolt
#

it has the same behavior as my v1 test above on my machine

#

so "nothing" with win10 recording and a black window with the other method

stiff sinew
#

That's really strange, since it's been working for me