Was doing O(n^2) list lookups with blender-render drawing & transform.
Also missing NULL checks would crash.
Use Object.base_flag (already used by new draw manager in places)
to avoid list lookup.
Note, transform still performs inefficient lookups,
but only for selected parents (like 2.7x), not all parents.
Now that some node types may have custom context, we need to handle that
in the (convoluted :| ) UI code of nodes as well.
Reported in T43295 by Gabriel Gazzán (@gab3d), thanks.
`BMO_iter_as_array()` may fill less items than requested in given array,
so we have to update number of items to work on from its returned value,
otherwise code might try to use uninitialized memory.
Read from the GPUMaterial to find custom-data layers used for drawing.
This resolves problem where having UV's would always calculate tangents
causing noticeable slow down compared to 2.7x.
The original code was doing a sanity check to see if existing index was
out of range. However the comparison was wrong.
So if the previous ct->user (active index of texture node) was larger
than then number of available texture nodes + 1 in the other material,
we would never re-set the index to 0.
Bug introduced on c31f74de6b.
There was an early attempt of fixing this (2b2ac5d3cc) but it was just working
by pure, luck. And failing in cases like the one from this bug report.
This is a very important, potentially deadly side-effect of this
operator. If something goes wrong, it can save a broken .blend file.
Ideally we could get rid of that operation anyway, once ID management if
fully renewed, but for now would rather keep it around.
Related to T51902.
Fix is a bit ugly, but cannot think of another solution for now, at
least this **should** not break anything else.
And now I go find myself a very remote, high and lonely mountain, climb
to its top, roar "I hate proxies!" a few times, and relax hearing the echos...
This commit makes the fullsample option for viewport renderings always
on: Render > OpenGL Render Options > Full Sample.
(The UI still allows users to set this, so we will need to revisit this
before 2.8 releases).
Even in computers that can handle MSAA we had issues.
The way Blender gpu_* implementation is handling anti-aliasing is buggy.
For example, in Blender 2.7x if you have depth of field in a viewport
with multi-sampling, the DoF gives us jagged edges.
Since Eevee uses framebuffers for a lot of things, this issue was
leading to very visible buggy render in some computers, and more subtle
inconsistent buggy renders in others (easy to test with the depth of
field in Eevee).
Some code for freeing shaders on scene updates (because of previous
dependency shaders had on lamps) had been disabled, as it is no longer
required. This removes that code altogether.
Object shaders no longer depend on lamp data at compile time, thus they
don't need to be invalidated when lamps change. Disabling shader
recompilation allows fast viewport updates when changing lamp settings.
Note that even though shaders for lamps are currently not being used,
`lamp_changed` is still freeing the lamp shaders, as at some point we
might want to use shaders for lamps...
