💖 Thanks for opening this pull request! 💖

We use semantic commit messages to streamline the release process. Before your pull request can be merged, you should update your pull request title to start with a semantic prefix.

Examples of commit messages with semantic prefixes:

• fix: don't overwrite prevent_default if default wasn't prevented
• feat: add app.isPackaged() method
• docs: app.isDefaultProtocolClient is now available on Linux

Things that will help get your PR across the finish line:

• Follow the JavaScript, C++, and Python coding style.
• Run npm run lint locally to catch formatting errors earlier.
• Document any user-facing changes you've made following the documentation styleguide.
• Include tests when adding/changing behavior.
• Include screenshots and animated GIFs whenever possible.

We get a lot of pull requests on this repo, so please be patient and we will get back to you as soon as we can.

Ready for review. Any suggestions? Here are some answers in advance:

1. Intentionally reused 'paint' event instead of creating a new one, because I don't see mandatory needs of creating a new event, and I prefer adding an extra parameter to 'paint', which also has no breaking change.

2. offscreenUseSharedTexture might be a little bit long, but I can't figure out a shorter name with same meaning.

3. Although we cannot do anything about the texture handle in pure node.js, we can write native node modules to import the texture, example

4. Please confirm that Emit('paint') is a blocking call, as chromium will recycle the textures once the callback returns, so it has to be blocking.

5. The speed will be much faster than previous hardware accelerated one (~3ms vs <100us), and it has no more words about the software output device which has no GPU support and slow.

Tested to be working on Windows, example repo

3. Although we cannot do anything about the texture handle in pure node.js, we can write native node modules to import the texture, example

Speaking as an interested outsider: how possible would it be to make it so that the texture could be used in the renderer process via webGPU with a workflow something like:

Main Process

const appWin = new BrowserWindow({ width: 800, height: 800 })
appWin.loadFile('index.html')

const win = new BrowserWindow({ webPreferences: { offscreen: true, offscreenUseSharedTexture: true } })
win.webContents.on('paint', (event, dirty, image, texture) => {
  appWin.webContents.send('texture', texture)
})
win.loadURL('https://github.com')

Renderer Process

ipcRenderer.on('texture', (_event, source) => {
  // Or similar function for chromium shared textures
  const externalTexture = gpuDevice.importExternalTexture({ source })
  // Use the texture in a webGPU pipeline and eventually
  // render the result to a canvas element
})

I'm biased as this is something I've been dreaming of for a long time, but if it is relatively simple to achieve, and performant, I think it could make this feature a lot more useful and accessible for the majority of the userbase.

renderer process via webGPU

Definitely possible. Actually I already did some research when I was walking through dawn's source. At least on Windows you can import a DXGI handle into dawn world (via webgpu native), then you can try convert it to a v8 webgpu texture to use it anywhere. There's no existing js api for this, you need to write one.

// PendingRemote instances may be freely moved to another thread/sequence, or
// even transferred to another process via a Mojo interface call (see
// pending_remote syntax in mojom IDL).

I think ipcMain ipcRenderer doesn't support passing a pending_remote mojo? so I think the release callback it not able to pass to another process. The only reason will be supporting async on paint event to let you release the texture after some awaits.

@Hate-Usernames Good news: I managed to let user able to release the texture when they want, which means you can pass the texture to wherever process you want, but releasers need to be maintained in the callback process and cannot be ipc. I think it can already do what we want, nnaintaining that would be easy with few more ipc calls, like posting the texture to the other process, and it replies a release message, then main process call the releaser.

About WebGPU, I think we can make that possible in another PR. I think CEF would also be interested in such capability. It will be awesome to directly use the texture in WebGPU pipelines.

I think the CI machines are dead for this PR? 🙂

Hi! Thanks for the review.

Also, I feel like it ought to be possible to pass the texture handle across a mojo pipe to be released in another process, so if you're running into trouble with that I'm curious what the roadblock was!

According to the comments in chromium is possible to pass a PendingRemote mojo to another process, however forgive my unfamiliar with mojo, I thought it needs a explicit interface that declare such field to let it pass to another process with another receiver that accepts such parameter.

In this OSR senario, I passed most of shared texture info to v8 by conversion, but I took a glance at electron's ipc and i think the serialization / deserialization process is not able to pass a PendingRemote object.

So currently I wrapped the PendingRemote object in a structure pointer and save it in a v8 external, just passing it to local function to make it a release callback. The releaser function is also not serializable so I really think it is not possible to pass purely at javascript side, without additional design in native side.

In conclusion, it is possible to pass PendingRemote as a parameter of mojo interface in native side, but I find no clue about how to integrate such behaviour in electron's ipc to make it possible purely at javascript side.

Hope you can help me out.