If an async source is cropped on one side, then when the program is
restarted and the source is loaded from file, the async source will
start out with a width/height of zero. This will cause the async source
to not be drawn if cropping or scale filtering is added to the scene
item, because it has to be rendered to a texture first. However, the
source cannot reset its size until it's drawn, so it leaves it in
perpetual state of having a 0x0 size.
This fixes that problem by ensuring that the async source size is always
reset even when not being rendered.
Closejp9000/obs-studio#686
Adds preview scaling to the right-click context menu for the preview
pane. This allows the ability to, for example, zoom the preview and
edit the preview 1:1 (canvas/base resolution). This was a missing
parity feature. Additionally, also allows scaling to the
"output/scaled" resolution the program is set to.
When the preview is in scale mode and is the focused widget, you can
hold space and drag with left click to change the zoomed position.
(Notes added by Jim)
Closesjp9000/obs-studio#687
Commit aa899c2 (PR #603) added logging for Windows bitness/arch, but it
was a bit incomplete/short-sighted. It only added that information to
the regular logs. This commit makes it easier to retrieve that
information for other purposes, like the crash handler.
When a scene is duplicated the filters on the scene were not copied to
the new scene. This causes that a temporary copy of a scene renders
differently in the program than in the preview when using studio mode.
Whenever a cursor is captured and the cursor icon changes, it creates a
new texture. This isn't particularly optimal, so instead just store a
cache of cursor textures (based on size), and make the textures dynamic.
Doing this will prevent unnecessary texture reallocation.
Due to an NVIDIA driver bug with the Windows 10 Anniversary Update,
there are an increasingly large number of reports of "Device Removed"
errors and TDRs. When this happens, OBS stops outputting all data
because all graphics functions are failing, and it appears to just
"freeze up" for users.
To temporarily alleviate this issue while waiting for it to be fixed,
the D3D subsystem can be rebuilt when that happens, all assets can be
reloaded to ensure that it can continue functioning (with a minor hiccup
in playback).
To allow rebuilding the entire D3D subsystem, all objects that contain
D3D references must be part of a linked list (with a few exceptions) so
we can quickly traverse them all whenever needed, and all data for those
resources (static resources primarily, such as shaders, textures, index
buffers, vertex buffers) must be stored in RAM so they can be recreated
whenever needed.
Then if D3D reports a "device removed" or "device reset" error, all D3D
references must first be fully released with no stray references; the
linked list must be fully traversed until all references are released.
Then, the linked list must once again be traversed again, and all those
D3D objects must be recreated with the same data and descriptors (which
are now saved in each object). Finally, all states need to be reset.
After that's complete, the device is able to continue functioning almost
as it was before, although the output to recording/stream may get a few
green frames due to texture data being reset.
This will temporarily alleviate the "Device Removed" issue while waiting
for a fix from NVIDIA.
Instead of letting vertex buffer data be freed immediately, store it so
it can be used for rebuilding later. Also, separate the buffer building
to a function.
Unloads all device data and clears all device references. Probably not
necessary, but it's unknown how D3D11 handles this internally so
probably best to be safe.
