| Age | Commit message (Collapse) | Author |
|---|
|
This module has no use now with the new DrawManager and DrawEngines and it
is using deprecated paths.
Moving gpu_shader_fullscreen_vert.glsl
to draw/modes/shaders/common_fullscreen_vert.glsl
|
|
|
|
D566 by @januz
Use Blender native dialog when OS dialog's aren't supported.
|
|
|
|
|
|
|
|
|
|
When adding scene strips to the sequencer, the wrong scenes were
getting getting added if some were skipped. For example:
Given 4 scenes (A, B, C, D) if you're trying to add the last 3 scenes
(B, C, D) as strips to the first scene (A), it would ended up adding
"A, B, C" instead of "B, C, D" as expected.
Fix provided by Andrew (signal9).
|
|
|
|
|
|
This is mostly to avoid re-compilation when using undo/redo operators.
This also has the benefit to reuse the same GPUShader for multiple materials using the same nodetree configuration.
The cache stores GPUPasses that already contains the shader code and a hash to test for matches.
We use refcounts to know when a GPUPass is not used anymore.
I had to move the GPUInput list from GPUPass to GPUMaterial because it's containing references to the material nodetree and cannot be reused.
A garbage collection is hardcoded to run every 60 seconds to free every unused GPUPass.
|
|
|
|
Avoid the error 170 ("The requested resource is in use").
|
|
Reverts rBb9ae517794765d6a1660 and fixes the issue properly. Old fix could cause
NULL to be passed to functions that expect all arguments to be non-NULL.
|
|
Also get rid of the static var and initialization.
This enables the user to see the progress on the info header.
Closing blender or reading a file also kill the job which is good.
Unfortunatly, this job cannot be interrupt by users directly. We could make it interruptible but we need a way to resume the compilation.
|
|
|
|
Match 'workspace_change_update'.
|
|
Note that this code will likely be generalized,
currently each new case is a little different though
so it's too early to move them into general functions.
|
|
Also minor cleanup.
|
|
|
|
|
|
This solves issue with tweaking brush size when interleaving particle edit
and texture paint modes. The issue was caused by texture paing setting more
operator properties then it's done for particle edit mode, which made window
manager to use saved proeprties for the "missing" ones.
Don't see any reason why we would want to save any of those properties.
This is a regression since rB83b60dac57a1.
|
|
Allows for each workspace to have it's own add-ons on display.
Filtering for: Panels, Menus, Keymaps & Manipulators.
Automatically applies to add-ons at the moment.
Access from workspace, toggled off by default
once enabled, add-ons can be white-listed.
See D3076
|
|
|
|
|
|
This is needed for multiple windows to draw the batch presets.
This will not be needed once we use only one context for UI.
|
|
This separate context allows two things:
- It allows viewports in multi-windows configuration.
- F12 render can use this context in a separate thread and do a non-blocking render.
The downside is that the context cannot be used while rendering so a request to refresh a viewport will lock the UI. This is something that will be adressed in the future.
Under the hood what does that mean:
- Not adding more mess with VAOs management in gawain.
- Doing depth only draw for operators / selection needs to be done in an offscreen buffer.
- The 3D cursor "autodis" operator is still reading the backbuffer so we need to copy the result to it.
- All FBOs needed by the drawmanager must to be created/destroyed with its context active.
- We cannot use batches created for UI in the DRW context and vice-versa. There is a clear separation of resources that enables the use of safe multi-threading.
|
|
Rename to WM_manipulator_group_type_poll,
use convention of other poll functions.
|
|
|
|
Wraps menutype poll, no functional changes.
|
|
|
|
Wrapps keymap poll, no functional changes.
|
|
|
|
This is not an ideal solution but blender freeing system is already well tangled.
So tracking and clearing vao caches when destroying contexts does prevent bad behaviour.
|
|
This reverts commit 87c72a7d2714de286109573055d5d5da32ece91e.
Caused T54121 which breaks blend file saving.
For now crash on exit is preferable.
Possible solution is to free screen-manipulator batches in a separate
loop.
|
|
Screen can contains manipulators that contains batches to be freed before the opengl contexts (in WM) are destroyed.
Also fix other GPU related free.
|
|
This allows allocation of VAOs from different opengl contexts and thread as long as the drawing happens in the same context.
Allocation is thread safe as long as we abide by the "one opengl context per thread" rule.
We can still free from any thread and actual freeing will occur at new vao allocation or next context binding.
|
|
Sync API changes from 2.8 to master.
|
|
|
|
Some of these API's can have 3D versions, explicitly name them 2D.
|
|
These no longer made much sense after regions were added, they just
duplicated state that was already in the regions.
|
|
|
|
|
|
header menu
While the script should be using INVOKE_PREVIEW for operators in clip view,
window manager was lacking some switch statements.
Thanks Brecht fore review!
|
|
|
|
- Use BLI_threadpool_ prefix for (deprecated)
thread/listbase API.
- Use BLI_thread as prefix for other functions.
See P614 to apply instead of manually resolving conflicts.
|
|
|
|
|
|
It's unlikely to ever be intentional to square the source alpha, as happens
with glBlendFunc, so this changes the blending throughout the code.
|
|
Now that the new 3D viewport draws to a multisample offscreen buffer, there is
no good reason anymore to create an entire multisample window and pay the
performance/memory cost for other regions that don't need it.
GL_MULTISAMPLE now only gets enabled for offscreen buffers, so we don't need
to check for it throughout the UI code anymore.
Differential Revision: https://developer.blender.org/D3062
|
