• Revert "Fix grease pencil in sequencer not responding to scene scale [WIP]"
• Different approach, same results

Also @Clément Foucault (fclem) shouldn't we have this for all modes/engines? Instead of only Eevee?

I'm not sure. Hopefully MSAA or TAA would be default for rendering, and not crappy FXAA. The performance impact of even the highest setting on Haswell intel GPU is so small...

As for the settings, if we really need to expose them, maybe we could think of an enum with presets (low-medium-high).
We can even use DRW_state_is_image_render() as a test and use a higher quality if rendering. (you may need to re-merge 2.8 in for that).

I finally managed to test this (thanks for using arcanist). I like the results. However I wonder:

In D2717#63952, @Corey Richardson (cmr) wrote:

One question I have about this is the second clause of the BSD license in the FXAA shader. Is there someplace in the manual or whatever this can be placed?

Just to clarify, when using arcanist we get:

• Context for the patch, so we can look at the patched files and see the lines before/after
• The exactly revision the patch was created against. This way when I do arc patch D2717 it always work flawlessly. Otherwise it tries to apply to the current branch as it is, and it often generates conflicts.

Can I automatically get an email at blender.studio whenever the 2.8 (or all) builbots fail then? That would be enough. Anyways, closing this for now.

An important thing, please start using arcanist for your patch submission. It makes testing it way simpler. As it is the patch is not applying cleanly.

Some minor comments inline, I will test the patch later.

Confirmed. And just to state the obvious (for developers), the same is valid for Japanese and probably any other unicode.

Small inline changes I had to do for OpenColorIO building (rB701a76769d4acb2dfda14a8fe2ef18ebd805d91c).

Overall I like the idea of adding consistence to the API. But I think we are shortening things more than we really need. See some inline comments.
That said I'm not passionate either way.

Driver 4534 has problems.
Drivers 4590 and 4627 work.

Fixed on rB1a7099f3ecf52fa8a54c2ba3f652d5827ca9103c.

Fixed since e791e01c0b0b58facf69eef11b4c46de869886d9

Resolved a few weeks/months ago.

Confirmed, crash log: P498

(for the records the original claim that clamping is the issue could be solved with P494, but RNA is already clamping the values before we get to the compositor, so this patch is uneeded)

This is not related to the directional blur node. Here is an even simpler file using another node:

The asan crash on exit was fixed on rB109447d008b4719f24a807560c6cb9a63fc8f51f.

Confirmed. Note to other testers on how to test it:

• Load file, enable auto-run scripts
• Switch viewport to rendered
• The viewport has nothing rendered.

Another way of testing the depsgraph warnings, which may (or may not) be related:

To reproduce it without the file:

./blender -b --python-expr "import bpy;bpy.context.scene.master_collection.collections.new('My Collection').objects.link(bpy.data.objects['Cube']);bpy.ops.scene.new(type='FULL_COPY');"

Mesh is corrupt, closing the report.

Full disclosure: This file may just be corrupt. Maybe it happened when applying modifiers, maybe at some other point. Unless there is anything we can do about those, I suggest we just close this bug.
@Bastien Montagne (mont29) @Campbell Barton (campbellbarton) ?

@Campbell Barton (campbellbarton) are all the critical topics addressed/committed already?