X11: remove Send requirement and process all UI and events on the main thread
Maintainer antworten meist innerhalb von 1 Tag
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Anfängerfreundlichkeit
- 35/100
Rechercherichtung
Start by reading the X11 backend’s event-loop implementation and the Host API; the issue does not name specific files or tests. Determine how timer and file-descriptor callbacks should be exposed for VST3 and CLAP, then verify that UI and event processing can stay on the main thread without the Send bound and that users can implement the revised Host API.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Currently the X11 backend spawns a new thread in order to spawn its own event loop and processes everything there.
This is done because on Linux there is no such thing as a global event loop (unlike Windows and macOS), so there is no standardized event loop for us to plug into.
The issue is that this forces a Send bound on the WindowHandler, which is only necessary for this workaround to work(Windows and macOS always keep everything on the main thread).
VST3 and CLAP now have support for either timer, or more ideally for watching any File Descriptor, and have the host call us back when any new event arrives on those. This allows us to indirectly plug into the host's event loop without blocking anything, and is how most (if not all?) plugins work in those formats.
We should augment the Host API to support timer and FD extensions, which would allow us to drop the Send bound and simplify quite a bit of code on the baseview side.
This however is a breaking change, not because of dropping the Send requirement, but because it will require all users to implement the new Host API.
- Vorherrschende Sprache
- Rust
- Sterne
- 387
- Forks
- 128
- Ø Merge
- 3 T. 2 Std.
- Gemergte PRs (30 T.)
- 15
Entwicklungsumgebung
Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus RustAudio/baseview
-
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 14/100
RustAudio/baseview#359 · 4 Kommentare ·
Maintainer antworten meist innerhalb von 1 Tag
-
Add support for TimersOffen
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 25/100
Maintainer antworten meist innerhalb von 1 Tag
-
enhancement
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 25/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 25/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 35/100
RustAudio/baseview#343 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
Alle Issues in RustAudio/baseview
Ähnliche Issues
-
area:io kernel-paused needs-triage
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
bherbruck/solvecraft#7854 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
transit-audio/transit#159 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
HakanSeven12/OpenCADStudio#2257 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
priority: low ui
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
storytold/photocraft#9884 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
triage: new type: bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 67/100
Jagalite/superseedr#376 ·
Maintainer antworten meist innerhalb von 1 Tag