ash-window: Keep loaded fns around via new SurfaceFactory object#1019
Merged
Conversation
MarijnS95
force-pushed
the
ash-window-store-loaded-extension
branch
from
93c61ff to
9b92e12
Compare
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
Ralith
approved these changes
Nov 23, 2025
MarijnS95
force-pushed
the
ash-window-store-loaded-extension
branch
from
9b92e12 to
1d26882
Compare
MarijnS95
changed the title
SurfaceExtension objectSurfaceFactory object
MarijnS95
force-pushed
the
ash-window-store-loaded-extension
branch
from
1d26882 to
989eb03
Compare
Ralith
approved these changes
Nov 26, 2025
MarijnS95
force-pushed
the
ash-window-store-loaded-extension
branch
from
989eb03 to
62c59d0
Compare
Even though `create_surface()` is typically off the hot path, we're repeatedly loading all platform-specific surface function pointers each time a new surface has to be created (sometimes for multiple windows, and on Android after every suspend-resume cycle when the app becomes invisible). In a subsequent patch these loaded extensions can be used to call their respective `get_present_support()` without reloading the entire function-pointer struct too. Additionally some users seem to be confused about object lifetimes when seeing this `Instance::new()` being dropped inside the implementation. This patch only marginally addresses that and users are more than free to just drop their `SurfaceFactory` object if no longer used (or recreate it later) without having any impact on the "parent/child relationship" mentioned in the `fn create_surface()` documentation. For now the choice has been made to store the passed `DisplayHandle` field with the enum variant when used in `create_surface()` to reduce ambiguity by not requiring it to be passed again. The user might still pass an incompatible `WindowHandle` in which case this returns `ERROR_EXTENSION_NOT_PRESENT`.
MarijnS95
force-pushed
the
ash-window-store-loaded-extension
branch
from
62c59d0 to
0d2b61d
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #974
Even though
create_surface()is typically off the hot path, we're repeatedly loading all platform-specific surface function pointers each time a new surface has to be created (sometimes for multiple windows, and on Android after every suspend-resume cycle when the app becomes invisible). In a subsequent patch these loaded extensions can be used to call their respectiveget_present_support()without reloading the entire function-pointer struct too.Additionally some users seem to be confused about object lifetimes when seeing this
Instance::new()being dropped inside the implementation. This patch only marginally addresses that and users are more than free to just drop theirSurfaceFactoryobject if no longer used (or recreate it later) without having any impact on the "parent/child relationship" mentioned in thefn create_surface()documentation.For now the choice has been made to store the passed
DisplayHandlefield with the enum variant when used increate_surface()to reduce ambiguity by not requiring it to be passed again. The user might still pass an incompatibleWindowHandlein which case this returnsERROR_EXTENSION_NOT_PRESENT.