Thanks, good to know.

I thinked again, I notice that some user use IME as a snippet tool with dictionary. So numeric text edit is good without modify, unless adding switching IME mode auto-swtching function at Blender preference.

In T93421#1270502, @Takahiro Shizuki (sntulix) wrote:

note:
IME's mode automatic restore work at numeric edit text too. (The case: When users's manupilation goes to numeric edit text from string edit text with IME enabled.) It may be not necessary sometimes by a workflow. I think it is useful if it's automatically disabled in the numeric edit text.

@Takahiro Shizuki (sntulix) Hi, I have tested the new build in Chinese, Korean, Japanese.

• One bug, when using Chinese IME, the input / outputs "/、“ :
  
  ,which should be ”、“ :
  
  There is a redundant "/". I refer to the Microsoft Pinyin IME behaviour in notepad :
  
  Other than this, I have no idea about what should / outputs in Chinese IME.

I also tested Korean and Janpanese.

• Start Blender with Japanese IME.
  
• Click the cube's object name text field.
• Japanese IME mode doesn't auto-switch to Japanese.
• But if when in text field, manually switch the mode once, next time when after entering text field, the mode will be auto-switched.

Japanese auto-switching issue is also in 3.0 and I find ⇧ is not the hotkey to switch Japanese IME mode.
For the other two IME, auto-switching is also functional when switch to other programs.

Thanks, though I compeletely know nothing about the codes.

@Takahiro Shizuki (sntulix) Thank you for elaboration. I have seen D11929 and to me it's an amazing commit that fix a long standing issue in Blender.
According to your notes, it looks like Blender is lacking a specific event for this situation (if I comprehend correctly).

Just in case, this is how to install "Microsoft Pinyin" on Windows 10:

@Richard Antalik (ISS) @Takahiro Shizuki (sntulix) @NXSK (NXSK) I did a new bug report T93421 .

In T92410#1260340, @NXSK (NXSK) wrote:

I don't quite understand how to set IME's status to "中“ automatically. Manually switching the IME's mode, I can't reproduce this issue with MS-IME either.
I suspect the ctrl, alt, shift key may have something to do with this problem.

In T92410#1260321, @Takahiro Shizuki (sntulix) wrote:

Hi.

I do reproduce a similary malfunction everytime with the exact step at this page's description by a few different way.

Exact steps for others to reproduce the error
(Steps may need tweaking with different setup)

    Switch to Chinese input method ( microsoft).
    Click text input field
    Type something in Chinese pinyin.
    Alt-tab to different app
    Shortcuts in Blender malfunctions.

My steps is:

1. click a text box with Chinese MS-IME's alphabet mode. (IME's status Icon in system try, Chinese: "英"). By this, Focusing is set the text area and IME's status is set "中" automatically. (If it is not set automatically, change IME's mode to "中" manually with a KEY to change IME's mode changing.)
2. Keep no pressing a key and click 3D viewport and press G key. In this time, Blender don't go in Object Move modal.

Note:

• In the just switching like the above, IME's status icon does not back to "英" in 3D viewport. Usually, When focusing go to 3D Viewport, IME's status go to "英" automatically.)
• In the situation, it is seems A-Z and 0-9 Keys are handled by Windows's IME maybe. Function keys is functional.
• The key changing IME's conversion mode in Japanese, Code 243 (0xF3), Win32api constant: VK_OEM_AUTO, Meaning: OEM specific, Name: [半角／全角]

note adding:

• This situation is end by clicking other window or input some text to text box with IME word conversion.
• If some IME word conversion was made in text box, this situation is not happen.

I tested today's build and the bug is fixed it seems to me.

In my opinion, the ideal behavior should be that only when user is inputting into text field the input is handled by input methods.

@Richard Antalik (ISS) I think the way to trigger the bug is kind of diverse and in my case I'm not able to abstract a good classification.I reported a similar bug in T91355 and the reproducing way in that report is still valid as I've just tested in the daily 3.0 beta, while I can't reproduce the bug by using the steps that @NXSK (NXSK) provided (maybe I got some misunderstanding).To me, it seems like that after comfirming Chinese text input, the following user inputs are still being treated as inputing to some text field somewhere and be handled also by the input method, which leads to shot-cuts malfunction.

In T91103#1218952, @炎臻 (PrettyFireNOI7) wrote:

Though I'm not familiar with this spelling method,I suppose here the problem is the "duplicated first letter" which is similar to T80532.

Mainly I'm using is "中文(简体，中国) 微软拼音“ as in the pic above.In this case to spell "输入中文字” the input is actually "shuruzhongwenzi".

---

The spelling way the “中文(繁体，台湾) 微软仓颉" (the input method in the report) using is that firstly type in letters then hit space bar to chose Chinese charactors.Which for example, type in "jjomn" and press space bar, then the charactor "輸" should pop up.
As a result in blender also due to the problem in T80532, all the first letter in the input is duplicated and form up "j輸o入l中y文j字", in contrast , after input the result should be "輸入中文字"(Latin letters are gone).I suppose this is the error this report is mentioning.

The spelling way the “中文(繁体，台湾) 微软仓颉" (the input method in the report) using is that firstly type in letters then hit space bar to chose Chinese charactors.Which for example, type in "jjomn" and press space bar, then the charactor "輸" should pop up.
As a result in blender also due to the problem in T80532, all the first letter in the input is duplicated and form up "j輸o入l中y文j字", in contrast , after input the result should be "輸入中文字"(Latin letters are gone).I suppose this is the error this report is mentioning.

Thanks for elaboration.

Thanks for the information.I just tested 3.0 Alpha and there is no error.

In T90498#1203564, @Richard Antalik (ISS) wrote:

Can't reproduce this issue. Here is what I did:

1. Click on File > New > General
2. Set File Format to FFmpeg Video
3. Set Container to WebM
4. Set Video Codec to WEBM / VP9
5. Set Output Quality to Lossless
6. Press Ctrl+F12

Can you reproduce issue with these steps?

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, @Lillya (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.