Either these calls to `replace` are unnecessary, or I'm going to learn something
I really need to know.
The only way difference I can see between `replace` and a simple assignment is
that `replace` returns ownership of the value to the caller, so the old value is
dropped after the new value has been put in place. But if Rust lets us assign to
or move from a variable, that means that no other alias can observe that
happening --- which I think means that the drop can't possibly care whether it
occurs before or after the move.
The previous expression gives unreasonable answers for some combinations of
`swapchain::Capabilities`' `min_image_count` and `max_image_count` values. For
example, for `3` and `None`, the expression evaluates to 2, which isn't a
permitted image count.
I looked for a terser expression (using `Option` methods, say), but the `match`
expression ended up being the most legible I came up with.
It was recently discovered in rust-lang/rust#50781 that `Self: Trait` bounds in trait methods are really not object-safe. This will be made into a warning by rust-lang/rust#50966, and vulkano will be affected by the warning .
Thankfully the fix looks simple, by just moving `fn len` from `BufferAccess` to being directly in `TypedBufferAccess`.
This updates the asserts in `RenderPass` creation to allow
`VK_SUBPASS_EXTERNAL` as a special value in addition to any value less
than the total number of subpasses. This enables custom unsafe
implementations of `RenderPassDesc` to define their external dependencies.
* Allow Surface to reference an external window object
This makes the Surface struct generic across a Window
type, so that a surface can own (or reference, if W is
an Arc) an external window object.
This also updates vulkano-win to take advantage of this.
There is no longer a dedicated Window struct in vulkano-win.
Instead, the Surface is simply passed ownership of the
winit::Window.
This fixes#844
* Update examples for new surface API
* Update Changelog
* Remove unnecessary send/sync bounds
* Update swapchain docs for new Surface behavior
This isn't full documentation of everything that the crate generates,
but it at least covers how to use it. I'm only working off my reading
of the source code, so it's entirely possible I got things wrong, but
crappy documentation is better than no documentation. I think.
Note that this has to add vulkano itself as a dev-dependency in order
for the doctest to compile, but that's also going to help with writing
tests if that ever happens.
An improvement over this would be to detail what the proc macro itself
generates and the functions, structs, etc you get from it. The details
on that are in vulkan-shaders, and are a bit harder to decipher.
Previously, it was possible for the hardlinked glslangValidator
to become truncated when the glsl-to-spirv crate was rebuilt. The
file would be successfully hardlinked the first time, but on
subsequent builds the hardlink attempt would fail becasue the target
already exists. This would cause the build script to fall back to
a copy, which truncates when source and dest are the same file.
This removes the hardlinking entirely, meaning that we always just
copy our built glslangValidator to where we want it. While it would
be possible to try to make the hardlinking/copying logic idempotent,
the complexity (and potential fragility to similar bugs in the
future) doesn't seem worth it to avoid one copy.
This fixes#95
