This type of indices is not natively supported on modern GPU and
gives warning on some implementation. The memory savings it
provides is also quite minimal and unlikely to be visible on
nowadays hardware.
This remove some uneeded struct members and makes primitive
restart always enabled by default. This can be broken by addons
if they are not careful enough but many other states have this
problem.
Also leverage GL_PRIMITIVE_RESTART_FIXED_INDEX if
ARB_ES3_compatibility is supported. This removes all API calls
to change restart index depending on indices length.
Use drag-only keyamp to adjust gizmos which use drag motion
to change a value. By default gizmos still activate on press.
This allows for left click select to be used with transform
without the gizmos getting in the way.
Even though this isn't necessary for right click select
it allows click events to pass through and be used by tools
which can be useful.
Resolves T63996
Now a small threshold is used for mouse input,
avoiding delay when gizmos are activated on drag.
Tablet input threshold remains unchanged since
it's easier to make small movements when using a tablet.
A larger threshold for non-cursor input is now used (typically keyboard)
which improves usability when the "Pie Menu on Drag" key-map preference.
The issue is that generic ANIM_animchannel_keyframes_loop can't
handle non-FCurve keyframes, so every selection operator does
its own looping over special key types, and the box and region
select operators didn't have code to deal with the summary.
This adds code to handle that in a similar way to other ops.
This is more of a temp urgent hack than a proper fix, chenages required
for the later are too involved for 2.80 at that point of time and will
be done later.
That commit merely keeps the whole existing logic for 3D painting
textures, but instead of re-creating a pool of threads for *every* (!)
stroke evaluation (i.e. mouse move event during painting), we instead
use Blender's task scheduler.
That remains sub-optimal, there are likely more improvements possible in
that code, but it should address the main issue reported (which is
presumably caused by windows thread launching being rather heavy process).
Before it was not possible to see everything in the outliner
when there are e.g. long icon rows. This is because Blender
did not allow panning the view to the right, since it did not
know the actual width.
Most of the code to compute the width correctly was there already,
but there were a couple of issues that made it not work.
* The tree width was computed before the tree was drawn.
This does not work, since the width is only known, after
it is drawn.
* Every `TreeElement` stores its right-most position in `xend`.
However, in the current code, the `xend` of e.g. an object is
the position where the text ends. The `xend` of the icons
is stored in the sub-tree-elements. Therefore, to compute
the maximum width, you may not skip the closed tree elements.
* The current drawing code had an early exit when the icon row
would not be visible anymore. This also skipped the calculation
of `xend`. So it would work correctly, when the icon was visible
a little bit, but not when it was not visible at all.
This patch fixes these issues. So even in more complex files, the
width is computed correcly. At least I haven't found a case, where
it does not.
Unfortunately, some optimizations had to be turned off, to make
it correct.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D4887
Fix for GPencil and Cycles Render draw type. GPencil objects were only
shown when overlays were turned on. The cause of this is an
optimization we did to not populate any draw engine when an
external renderer was used with overlays turned off.
This will check if there is any visible GPencil object in the scene. if
so it will still perform the loop.
`DEG_id_type_any_exists` can check if any object of a certain type_id is in the
result. This check is also being used to check if there are any
visible grease pencil objects as a precheck in `DRW_render_check_grease_pencil`.
Reviewed By: brecht, fclem, antoniov
Maniphest Tasks: T65191
Differential Revision: https://developer.blender.org/D4962
The idea is to share a mesh data-block as a result across all objects
which are sharing same original mesh and have no effective modifiers.
This mesh is owned by an original copy-on-written version of object data.
Tricky part is to make sure it is only initialized once, and currently a
silly mutex lock is used. In practice it only locks if the mesh is not
already there.
As an extra bonus, even viewport memory is also lower after this change.
Reviewers: brecht, mont29
Reviewed By: brecht, mont29
Differential Revision: https://developer.blender.org/D4954
