The intention is to fix a too low default threshold on high DPI screen.
Users with high DPI screens that have increased the threshold to fix this
or liked the lower threshold will need to lower it again.
This is still somewhat of a guess, ideally this would be based on the
physical distance travalled, and maybe different per type of input device.
However we do not have access to this information, and hope this gives a
better default.
For Blender 2.8 we had to be compatible with very old OpenGL versions, and
triple buffer was designed to work without offscreen rendering, by copying
the the backbuffer to a texture right before swapping. This way we could
avoid redrawing unchanged regions by copying them from this texture on the
next redraws. Triple buffer used to suffer from poor performance and driver
bugs on specific cards, so alternative draw methods remained available.
Now that we require newer OpenGL, we can have just a single draw method
that draw each region into an offscreen buffer, and then draws those to
the screen. This has some advantages:
* Poor 3D view performance when using Region Overlap should be solved now,
since we can also cache overlapping regions in offscreen buffers.
* Page flip, anaglyph and interlace stereo drawing can be a little faster
by avoiding a copy to an intermediate texture.
* The new 3D view drawing already writes to an offscreen buffer, which we
can draw from directly instead of duplicating it to another buffer.
* Eventually we will be able to remove depth and stencil buffers from the
window and save memory, though at the moment there are still some tools
using it so it's not possible yet.
* This also fixes a bug with Eevee sampling not progressing with stereo
drawing in the 3D viewport.
Differential Revision: https://developer.blender.org/D3061
Border and circle select wait for input by default.
This commit uses bool properties on the operators instead of
magic number (called "gesture_mode").
Keymaps that define 'deselect' for border/circle select
begin immediately, exiting when on button release.
Notes:
- Changes in paint_vertex.c were simple to merge, mainly related on passing
evaluation context.
- Conflicts in EditDM and drawmesh.c are solved using code from blender2.8
branch. Those areas are deprecated and not to be used in final release.
However, it's possible that some reference code from master is lost, so
keep attention when adding alpha support for vertex painting.
Goal is to make them more modular, to allow more variants (variable
single-color, thickness, ...) to be added without having to
copy-and-change-one-line of whole chain of shaders.
Using geometry shader allows us to get rid of the 'line origin' extra
vertex attribute, which means dashed shader no longer requires fiddling
with those vertex attributes definition, and, most importantly, does not
require anymore special drawing code!
As you can see, this makes code much simpler, and much less verbose,
especially in complex cases.
In addition, changed how dashes are handled, to have two 'modes', a
simple one with single color (using default "color" uniform name), and a
more advanced one allowing more complex and multi-color patterns.
Note that since GLSL 1.2 does not support geometry shaders, a hack was
added for now (which gives solid lines, but at least does not make
Blender crash).
The scale version was working(ish), but it was not really extendable to
a 3D line version of the shader.
Also note that sequencer view still keeps its 'UI scale' adaptation
(dashes grow together with UI scale setting). Would be nice to do that
everywhere ultimately imho, but nothing urgent here.
Even though in some cases this does not seems useful, in others (like
zommed 2D views) we have to correct MVP matrix scaling to get fixed
dashes size.
Note that we could do that differently (commented about it in shader),
would also have been cleaner to extract that MVP scale from within the
shader, but there does not seem to be a way to initialize uniform values
from within a shader, and would rather avoid recomputing the scale for
every run (especially since 3DViewport does not need it e.g.).
Part of D2647.
The specialized color functions are better in every way:
- faster lookup (don't have to match "color" string)
- flexible inputs (RGB with separate alpha)
- automatic alpha = 1.0 if not specified
Sort of related to T49043
The issue was caused here by usage of deprecated GL_CURRENT_PROGRAM
which was returning rubbish value.
Now we use imm API and create vertex format prior to immBindProgram.
This made us required to have some sort of state passed from setup
function to actual drawing.
Single quads are drawn as a TRIANGLE_FAN, with 4 verts in the same order.
Multiple quads now use PRIM_QUADS_XXX and will need further work. Only 8 places still use this.
Part of T49043
See intern/gawain for the API change. Other files are updated to use the new name. Also updated every call site to the recommended style:
unsigned int foo = VertexFormat_add_attrib(format, "foo", COMP_ ... )
- use 'imm_draw_' prefix for functions that draw.
- use '_3d' suffix for 3d functions, no suffix for 2d functions.
- use terms fill/wire (shorter than filled / lined).
Also add `imm_draw_circle_fill_3d` (only had wire version)
Just do early output and don't bother with any GLSL program bind when
there is not enough points of lasso to draw.
This could have happened at the very beginning of the stroke.
