Don't force users to set up an event loop about wgpu-py HOT 6 CLOSED

I feel like we may be talking about different things here. Maybe we need another whiteboard session or something :)

from wgpu-py.

Well, I agree, but I also think it's important that we make this library easy to integrate. I don't want Qt users to deal with async-ness when they are completely unfamiliar, they will just get frustrated. Perhaps we can provide a sync version of the API or event loop adapter layers... I'm not sure. Let's keep the brainstorm going on this one...

from wgpu-py.

Short answer: wgpu has a few async functions by design, but we should not pin down on asyncio, but allow people to use trio or any other async lib.

The only use of asyncio is in requestAdapterSync() to provide a sync version of requestAdapter. I think we should indeed remove that. Our examples are now set up to be async, so we don't need it anymore.

However, the wgpu has a few functions that are async by design, i.e. these are async def, and we'll have to deal with that. I think we need some async library (asyncio or trio or ...) for that in the example, I don't think the native GUI event loops suffice, right?

from wgpu-py.

I was thinking about this a little bit more this morning, and in particular, this triggered me:

The only use of asyncio is in requestAdapterSync() to provide a sync version of requestAdapter. I think we should indeed remove that. Our examples are now set up to be async, so we don't need it anymore.

I think this might actually be very good to keep around. When I work with C#, it's quite normal for libraries to expose both async and sync APIs for the same functionality. This is often very convenient, since you might want to use a library call outside an event-loop managed area such as database migration or CLI scripts.

I think we should acknowledge that our target deployment is mainly going to be desktop GUI frameworks and rendering scripts, where async io has definitely not become mainstream yet.

So, I have two questions:

• Can we provide a sync version of all async methods using run_until_complete?
• Can we make it optional to setup an event-loop? It seems to me the sync API could very easily just use an internal isolated event loop instance that only runs for the duration of that call?

I think that would bring us where we want to be. IDL compliance, no event-loop boilerplate for users and we still offer all the advanced options for power users.

from wgpu-py.

Can we provide a sync version of all async methods using run_until_complete?

I should think so ... But we may better wait for a bit, since wgpu-native is evolving towards having an actual event-loop, and I'm not sure yet whether it's enough to only "integrate" with it during an async call, or whether we must somehow keep it alive all the time.

Can we make it optional to setup an event-loop? It seems to me the sync API could very easily just use an internal isolated event loop instance that only runs for the duration of that call?

If we can answer the previous question with yes, I see no reason why the user would have to deal with an event-loop.

I think it makes sense that a user should choose to either use the async API or the sync API, not a mix.

from wgpu-py.

In #43 every async method also gained a sync (blocking) version. I think we can manage to keep this up one way or another.

from wgpu-py.