Just tested and no issue,thanks for replying.

In T88170#1159717, @Clément Foucault (fclem) wrote:

This is due to a difference between Cycles and EEVEE.

EEVEE applies ensure_valid_reflection on glossy normal input where Cycles only applies it on normal mapped & bump node output.

Here is an example of the same behavior in cycles.

Unfortunately, we need to use ensure_valid_reflection to avoid nasty artifacts on glossy BSDF even without bump/normal mapping (see T81070 & T78501).

We keep the same behavior when SSR is off to keep consistency.

Note that EEVEE won't distort the normals for diffuse.

In T60017#650617, @Clément Foucault (fclem) wrote:

Since last asking for information it has been 7 or more days, due to the policy of our bug tracker we will have to archive the report until the requested information is given.

Accidentally pressed Enter,rewriting the report.

Sorry for the bothering.I'll wait for tomorrow's build to check the status,if it's as usual then the new build should be coming soon (or maybe 2.92 official release).

Yeah I found the commit date is kind of old.It looks like the builds on https://builder.blender.org/download/ might get uploaded wrong,I download from there a few hours ago.

Working well for me .

In T85844#1117427, @Nicholas Rishel (nicholas_rishel) wrote:

All: this build reverts changes to that caused this issue. Please +1 if this fixes things for you or comment if there is still an issue.

In T85844#1117075, @kursad k (kursadk) wrote:

In T85844#1116568, @炎臻 (PrettyFireNOI7) wrote:

This issue might needs other stylus or Wacom tablet users.I can't find a way to enable Windows Ink only while keeping my tablet functioning.
"Use Windows Ink" setting in Wacom driver can't fix this problem and possibly my tablet is too old to work correctly without Wacom driver.

Blender offers an option to choose "Windows Ink" under "Input" settings, see if you are able to change it.

P1978 for:

In T85844#1116544, @Nicholas Rishel (nicholas_rishel) wrote:

Note to anyone looking into this issue:

This issue is a result of Win32 mouse input not being synchronized with Wintab pressure. This has been an issue before 2.92, and has reappeared because the heuristics which discourage it from happening no longer work as well because Win32 mouse input was modified to support more accurate mouse movement (smooth lines when drawing).

There is no good long term fix, the issue is how Wintab works and the compromises to support current workflows in Blender.

The fix for this issue is to use Windows Ink (may require restarting Blender).

Could you test about how the pressure is functioning with Windows Ink?

This issue might needs other stylus or Wacom tablet users.I can't find a way to enable Windows Ink only while keeping my tablet functioning.
"Use Windows Ink" setting in Wacom driver can't fix this problem and possibly my tablet is too old to work correctly without Wacom driver.

In T85733#1116549, @Nicholas Rishel (nicholas_rishel) wrote:

@Marek Trejbal (marek3ball) @炎臻 (PrettyFireNOI7) updated build to test, I believe this will resolve your remaining cursor jump issues.

In T85733#1116342, @Vinicius Francisco (Lillya) wrote:

The issue has been solved for me too, using a Huion H950P.

I don't know if wintab is supposed to work on this build too, but I noticed that there's a new problem, on the start of every stroke the pressure is always 100%, causing these dots:

Console log : P1977
There is some movement me trying to open the console window at the beginning of the log and trying to switch programme window at the end.And following pictures showing my progression during the log process:

@Nicholas Rishel (nicholas_rishel)
Much appreciate the new build.
While I did some test in weight paint mode and maybe there is still some reason casuing glitches (possibly too rare cases and I couldn't find a reproducible reason for those spikes(I just kept drawing random lines)):

I can confirm this with my wacom tablet(CTL-690),it seems not a mouse problem.And these glitches also happens with grease pencil.

In T85639#1113112, @Philipp Oeser (lichtwerk) wrote:

Please post english language here.

Like @Leroy (Leroy) said, this can have the reason of running out of memory (by e.g. having a subdivision modifier with too high subdivision -- but there are many more thinkable situations where this can happen).
Note that running out of memory is not considered a bug:

While we want to improve Blender to handle such cases memory gracefully, this is not currently considered a bug.

To really tell though, we'd need an example .blend file where this happens (with clear steps to reproduce the issue from the point of opening that file)

翻译(Manual Translate):

Manual Translate:

In T85495#1110581, @Germano Cavalcante (mano-wii) wrote:

Thanks for the report, I can confirm the crash:

>	blender.exe!CustomData_get_active_layer(const CustomData * data, int type) Line 2362	C
 	blender.exe!overlay_edit_uv_cache_populate(OVERLAY_Data * vedata, Object * ob) Line 426	C
 	blender.exe!OVERLAY_edit_uv_cache_init(OVERLAY_Data * vedata) Line 411	C
 	blender.exe!drw_engines_cache_init() Line 1036	C
 	blender.exe!DRW_draw_render_loop_2d_ex(Depsgraph * depsgraph, ARegion * region, GPUViewport * viewport, const bContext * evil_C) Line 2111	C
 	blender.exe!image_main_region_draw(const bContext * C, ARegion * region) Line 656	C
 	blender.exe!ED_region_do_draw(bContext * C, ARegion * region) Line 563	C
 	blender.exe!wm_draw_window_offscreen(bContext * C, wmWindow * win, bool stereo) Line 732	C
 	blender.exe!wm_draw_window(bContext * C, wmWindow * win) Line 875	C
 	blender.exe!wm_draw_update(bContext * C) Line 1074	C
 	blender.exe!WM_main(bContext * C) Line 644	C
 	blender.exe!main(int argc, const unsigned char * * UNUSED_argv_c) Line 527	C
 	[External Code]

This problem appears to have been introduced recently.

Crash also happens in Image Editor Draw mode situation.

Confirmed this doesn't tackle T84081.

Thanks and Poke T80532 .

In T84167#1085343, @Robert Guetzkow (rjg) wrote:

I can reproduce the behavior. The issue appears to be that your file produces values that exceed the range of half-float which is +/- 65.504 (IEEE 754). The maximum RGB value in the 0001Full Float.exr file is 40852116.0. It seems that the floating point arithmetics result in -nan instead of nan, which produces pure black instead of white in the image.

This is quite an edge case. Perhaps COM_GlareStreaksOperation.cpp or parts of the pipeline that process the results could handle this better, but this may be seen different by the VFX module owner @Sergey Sharybin (sergey).

In T82833#1057624, @Dalai Felinto (dfelinto) wrote:

Small note, @炎臻 (PrettyFireNOI7) nice presentation of the bug report. Usually it is not encouraged to deviate from the template, but I actually like what you did here

I can confirm:
Using default scene saved in Blender 2.92 then opened it up via Blender 2.90.1 and today's 2.91 beta.Immediately crashed.So as my other files saved in today's 2.92 alpha.

I tested Japanese input and fond the same problem: