배터리 수명에 대해 비슷하게 집착하는 사람들을위한 해결 방법 : 커서 깜박임을 비활성화하면 CPU 사용량이 0으로 떨어집니다. 설정은 다음과 같습니다.

  "editor.cursorBlinking": "solid"

Twitter의 일부 사람들은 이것을 재현 할 수 없다고 말 했으므로 디버그를 돕기 위해 개발자 도구에 타임 라인을 기록했습니다.

TimelineRawData-20170321T114212.json.zip

• 타임 라인 스크린 샷 :

  

• 단일 프레임으로 확대하면 2fps 만 렌더링하는 동안 메인 스레드는 화살표로 표시된가는 선인 60fps (16ms마다)에서 일부 작업을 수행하고 있음을 알 수 있습니다.

  

• 얇은 선 중 하나까지 확대하면 일부 렌더링이 60fps에서 발생하는 것을 볼 수 있습니다.

  

• CPU 프로파일을 가져 오면 특정 JS 기능이 아닌 "(프로그램)"에서 사용되는 대부분의 CPU를 보여줍니다.

  

• "editor.cursorBlinking": "solid" 를 설정하면 대부분 문제가 사라집니다.주기적인 "Update Layer Tree"/ "Paint"/ "Composite Layers"가 여전히 발생하지만 16ms가 아닌 500ms마다 발생합니다.

이게 도움이 되길 바란다!

@joliss 내부 에서 일어나는 일에 대한 빠른 답변 : Chromium에서 기본 애니메이션이 60hz로 업데이트됩니다.

유사 (거의 동일) Chromium 문제 https://bugs.chromium.org/p/chromium/issues/detail?id=500259 및 Chromium의 추적 항목 https://bugs.chromium.org/p/chromium/issues/detail ? id = 361587

현재 CSS 애니메이션

<strong i="11">@keyframes</strong> monaco-cursor-blink {
    50% {
        opacity: 0;
    }
    100% {
        opacity: 1;
    }
}

.cursor-blink {
    animation: monaco-cursor-blink 1s step-start 0s infinite;
}

최신 정보

Paul Irish (Chrome guy) https://news.ycombinator.com/item?id=13941293 인용

웹 스택에 구축 된 강력한 * 텍스트 편집기는 OS 텍스트 캐럿에 의존 할 수 없으며 자체적으로 제공해야합니다.
이 경우 VSCode는 아마도 커서를 깜박이는 데 가장 합리적인 접근 방식을 사용하고있을 것입니다. CSS 키 프레임 애니메이션이있는 step 타이밍 함수입니다. 이것은 500ms마다 불투명도를 변경하도록 브라우저에 지시합니다. 한편 Chrome은 아직이를 완전히 최적화하지 않았으므로 http://crbug.com/361587입니다.
따라서 현재 Chrome은 500ms 간격으로 만 작업해야 할 때 16ms마다 전체 렌더링 수명주기 (스타일, 페인트, 레이어)를 수행하고 있습니다. Chrome의 스타일 구성 요소를 작업하는 엔지니어가이 문제를 해결할 수 있다고 확신하지만 약간의 작업이 필요합니다. 이 주제에 대한 가시성이 추가되면 수정의 우선 순위가 높아질 것입니다. :)

• 간단한 텍스트 편집기와 [contenteditable] 기반의 기본 편집기는 가능하지만 가장 원하는 기능 세트로 확장되는 경우는 거의 없습니다.

Chromium 탭의 백그라운드 CPU 사용량에 대한 이 변경 사항

그렇지 않기를 바랍니다 (https://github.com/electron/electron/issues/7553 참조). 우리는 않는 설정 backgroundThrottling 에 false 동안 이미 때문이다.

좋은 분석을 위해 @joliss @rebornix 에게 감사드립니다.

OSX에서 setInterval 로 돌아 가야 할 것 같습니다.

추신 다음은 초기 커서 깜박임 논리입니다. :)

@rebornix 우리가 얼마 전에 -https://bugs.chromium.org/p/chromium/issues/detail?id=658894 . 우리의 경우 해결 방법은 DOM을 사용하지 않았을 때 애니메이션 요소를 단순히 닫는 것이 아니라 제거하는 것이 었습니다.

현재 구현 링크-
https://github.com/Microsoft/vscode/blob/master/src/vs/editor/browser/viewParts/viewCursors/viewCursors.ts

동일한 CSS 스타일도 있지만 여기서 사용되는지 확실하지 않습니다.

<strong i="6">@keyframes</strong> monaco-cursor-blink {
    50% {
        opacity: 0;
    }
    100% {
        opacity: 1;
    }
}

https://github.com/Microsoft/vscode/blob/master/src/vs/editor/browser/viewParts/viewCursors/viewCursors.css

커서 애니메이션에 https://developer.mozilla.org/en-US/docs/Web/API/Window/requestIdleCallback 을 사용하지 않는 이유는 무엇입니까?

애니메이션을 비활성화하려면 페이지가 숨겨 졌는지 알려주는 pageVisibility API를 사용하십시오.

function handleVisibilityChange() {
  if (document.hidden) {
    // disable cursor animation with class name
  } 
  else  {
    // add back cursor animation
  }
}
document.addEventListener("visibilitychange", handleVisibilityChange, false);

제안 여기가 대신 CPU의 GPU를 사용하여 CSS 애니메이션을 렌더링합니다 :

.cursor-blink {
    will-change: opacity;
}

현재 구현에서는 에디터가 포커스를 잃으면 애니메이션을 제거하여 삶을 편하게합니다. 그러나 편집기에 포커스가 있으면 편집기가 표시되고 (숨겨 지거나 배경에 있지 않음) 활성 상태이고 사용자가 작업 중이며 (읽기가 좋은 경우)보기 / 내용 변경을 트리거하지 않음을 의미합니다. 이 경우 유휴 상태 인 경우에도 깜박이는 커서를 표시해야합니다. 이것이 깜박이는 커서입니다.

처음에이 기능은 JavaScript로 구현되었으며 약 1 년 전에 CSS 애니메이션으로 전환했습니다. @alexandrudima가 언급했듯이 OSX에서 JS로 돌아가고 싶을 수 있습니다.

@camwest 는 API가 매력적이며 유일한 문제는 호환성입니다 (슬프게도 Safari).

@mehas will-change 는 유망합니다. 시도해 보았지만이 경우 Chromium이 최적화되지 않습니다. Dev Tools에서 Paint Flashing 옵션을 켜면이 깜박이는 커서가 전혀 다시 그려지지 않음을 알 수 있습니다.

@jlukic @bcherny 귀하의 제안에 감사드립니다. 최적화하려는 것은 커서가 표시되고 활성화되고 깜박일 때이므로 가시성 검사가 있어도 여전히이 문제가 있습니다. 하지만 당신 말이 맞습니다. 가시성을 확인해야합니다. 현재 창을 스크롤하여 깜박이는 커서를 보이지 않게하면 최적화가 없습니다.

공정하게 말하면 모나코는 정말, 정말, 정말 복잡합니다. :)

@rebornix will-change는 내 프로젝트에서 작동했으며 CPU 사용량이 완전히 사라졌습니다. 그러나 내 키 프레임은 불투명도를 변경하지 않습니다. 대신 요소의 색상을 '상속'에서 '투명'으로 변경합니다.

나는 그저 잠복 자일 뿐이고 이것이 욕설로 간주된다면 미안하지만 2 프레임 애니메이션 gif가 속임수를 쓰지 않을까요? 나는 이것을 결정적으로 테스트하는 방법을 완전히 확신하지 못하지만 KHTML조차도 Chrome으로 변형되기 훨씬 전에 이미 최적화 된 경로를 가지고 있다고 상상할 수 있습니다.

@eteeselink 는 흥미로울 수 있지만 커서 색상을 변경해야하고 확대 / 축소 등이 사소하지 않을 수 있으며 그 동안 js로 다시 전환하는 것이 더 쉬울 수 있습니다.

@matthiasg Ahyes, 확대 / 축소를 잊어 버렸습니다.

그렇지 않으면 테마 색상에 따라 깜박이는 GIF를 자동 생성하는 것이 너무 어렵지 않아야합니다. GIF 픽셀 데이터는 LZW로 인코딩되지만 팔레트 데이터는 압축되지 않기 때문에 미리 베이킹 된 파일에서 몇 바이트를 패치하는 문제 일 수 있습니다. 그러나 나는 그렇게 gif를 확대하면 흐릿하게 만들 것이므로 그럼에도 불구하고 이것은 나쁜 접근 방식 일 수 있습니다.

누군가가 GIF 캐럿을 확대 / 축소 할 수있는 방법을 생각해 낼 수 있다면 색상을 취하고 깜박이는 캐럿 애니메이션 GIF 데이터 URL을 생성하는 코드를 제공 할 것을 약속합니다.

@eteeselink 어쨌든 바닐라 JS, 아마도 PHP와 몇 가지 다른 맛을 절대적으로 요지해야합니다. 나는 그것이 웹 전체에서 수 톤의 사용을 얻을 것이라고 상상할 수 있으며, 원래 저자를 인정해야하는 라이선스를 사용한다면 당신은 매우 유명 할 것입니다.

@eteeselink 우리가 벽에서 벗어난 솔루션을 제안하고 있다면 캐럿을 대신 <blink></blink> 감싸는 것이 어떨까요? :눈짓:

사람들이 실질적인 개선을 시도하는 문제와 PR에 대해 쓸모없는 발언을하는 데 Reddit 여단에 합류하지 마십시오.

편집기에 포커스가 있으면 편집기가 표시됨을 의미합니다.

이것은 잘못된 가정입니다. 초점을 맞추지 않고 다른 창 위로 창을 올리는 것은 사소한 일입니다. 내가 아는 두 가지 방법 :

• "항상 맨 위에 그리기"WM 힌트
• 가상 데스크톱간에 창이 이동 될 때 (스택 순서가 전역이므로 창이 이전 데스크톱에서 맨 위에있는 경우 새 데스크톱에 있지 않을 수 있음).

둘 다 자체적으로 매우 일반적이지만 반드시 항상 문제를 일으키는 것은 아닙니다.

@ o11c 감사합니다, 글을 쓸 때 내 가정이 너무 거칠 었습니다. 그렇습니다. 초점이 필요하지 않다는 것은 보이는 것을 의미합니다. 창을 스크롤하는 것은 한 가지 경우입니다 (같은 단락에서 언급했습니다 :(). focus + visible이 가장 일반적인 경우인지 모르겠지만 모두 완화되어야합니다.

setTimeout 또는 setInterval이 아마도 requestIdleCallback보다이 사용 사례에 더 적합하다고 생각합니다. requestIdleCallback의 타이밍은 예측할 수 없으며 JS에서 수행하는 작업은 저렴하므로 가끔 타이머를 예약하는 것이 더 나을 것이라고 생각합니다.

전의. https://gist.github.com/esprehn/afec30fbc655bba6bb8f3f67c28beef4

또한이 캐럿 애니메이션은 부드러운 펄스 효과를 나타내지 만 브라우저의 시스템 커서 (예 : <input> 또는 <textarea> 내부의 커서)는 바이너리 켜기 / 끄기 만 수행합니다. . Mac과 Linux의 기본 컨트롤은 비슷하게 깜박입니다. 덜 예쁘지 만 상당히 적은 전력을 사용합니다.

감사합니다 @esprehn , 바로 지금 내가 플랫 깜빡임을 위해 한 일입니다. 그리고 당신이 언급했듯이, 그것은 애니메이션만큼 예쁘지 않으며 ease-in-out 를 사용하는 부드럽게 / 확장 깜박이는 커서를 말하는 것도 아닙니다.

@eteeselink 기다려, 1px gif를 사용하고 어쨌든 크기를 조정하고 싶지 않습니까? 블러는 문제가되지 않습니다.

예 : https://jsfiddle.net/mrkev/stxq613s/1/

곧 애니메이션 깜박임 캐럿 생성기를보기를 바랍니다.)

@mrkev your 1px gif as data uri : data : image / gif; base64 , R0lGODlhAQABAPAAAAAAAP /// yH / C05FVFNDQVBFMi4wAwEAAAAh + QQFMgABACwAAAAAAAAQABAAACAkwBACH5BAUyAAOALAAAAABABAC

트윗 담아 가기 gif는 이론상 색상 표를 사용하기 때문에 "on"프레임에있는 픽셀 검은 색을 찾는 3 바이트를 찾기가 너무 어렵지 않아야합니다 (프레임에 저장되지 않으므로 헤더를 너무 깊숙이 지나갈 필요가 없습니다). ). 내일 여가 시간을 찾으면 더 깊이 들어갈 수 있습니다.

어쨌든 잠이 필요한 Welp는 이것을 조금 더 탐구하기로 결정했습니다. gif는 항상 14 번째 바이트에서 시작하는 전역 색상 표 를 사용하기 때문에

이제 정말 성가신 것은 base64에서 각 숫자가 6 비트 만 인코딩하므로 상황이 제대로 정렬되지 않는다는 것입니다. 숫자 18의 최하위 비트이며 숫자 22의 최상위 비트는 해당 gif에서 검은 색을 인코딩합니다. 따라서 본질적으로 위치 18-22에서 문자 [A-P] [A-/] [A-/] [A-/] [P,f,v,/] 의 일부 순열은 모든 색상으로 해당 픽셀을 그립니다.

다음은 임의의 색상에 대한 GIF의 예입니다. 나는 본질적으로 18-22 문자에있는 것을 G8ABf (위에서 언급 한 기준에 맞음)로 대체했습니다.

https://jsfiddle.net/mrkev/stxq613s/7/

RGB를 사용하고이 gif를 해당 색상으로 반환하는 함수를 빌드하는 것이 나쁘지 않아야합니다 (:

나는 7 시간 안에 수업을 듣는다. 나는 말 그대로 자신을 찢어 버리고있다.

그러나 어쨌든 누군가가 이미 hex-to-base64 함수를 작성했으며 빠른 스택 오버플로 검색만으로도 충분하다는 것을 깨달았습니다. 여기에 기능이 있습니다.

// takes color as string 'RRGGBB'
var generate_cursor_image = color => {
  var gif = '47494638396101000100F00000' + color + '00000021FF0B4E45545343415045322E30030100000021F90405320001002C00000000010001000002024C010021F90405320001002C00000000010001000002024401003B'
  return 'data:image/gif;base64,' + btoa(gif.match(/\w{2}/g).map(a => String.fromCharCode(parseInt(a, 16))).join(""))
}

모두 잘 자요!

젠장, @mrkev 가 나를 이겼습니다. 어쨌든, 여기에 동일한 구현이 있습니다.
https://jsfiddle.net/a6g4ob7h/

일치 및 매핑이 진행되지 않고 btoa 만 있기 때문에 조금 더 빠를 수 있습니다. 하지만 속도가 중요하다고 생각하지 않으며 결과를 캐시하는 것이 좋습니다.

내가 정말로 궁금한 것은 이것이 속도를 높이는지 여부입니다. 테스트 할 좋은 설정은 없지만 애니메이션 GIF도 60fps로 다시 렌더링 될 수 있습니다.

확대 / 축소하고 직사각형 모양의 커서가 없는 경우 애니메이션 SVG를 사용할 수도 있습니다. ( <animate> 요소는 이미 SVG 1.0 사양의 일부였습니다.)

@eteeselink Max는 약 http://nullsleep.tumblr.com/post/16524517190/animated-gif-minimum-frame-delay-browser

나를 위해 그것은 대부분 0으로 유지됩니다 (cpu 사용량은 첫 번째 열입니다-OSX 10.12.3-MacBook Pro Retina, 15-inch, Late 2013)

커서와 관련하여 기본 설정이 있습니다.

아무도 Linux에 대해 언급하지 않았지만 Wayland (Ivy Bridge Graphics)를 사용하는 GNOME Shell에서 약 5 ~ 7 %에 해당합니다.

blink 커서 깜박임 스타일에 대해 setInterval 로 돌아가서이를 완화하는 PR # 23121을 병합했습니다. Mac mini에서는 CPU 사용량이 5.9 %에서 0.9 %로 떨어집니다.

네이티브로 전환하고 OS가 커서를 무료로 제공하도록 고려한 적이 있습니까?

@justjoeyuk 위의 @rebornix의 인용문을 참조하십시오.

@justjoeyuk 대신 완전히 네이티브가 아닌 웹 스택 기반 응용 프로그램을 제안하는 경우 : VSCode와 같이 테마가 매우 크고 DPI에 독립적 인 크로스 플랫폼 응용 프로그램의 가능성이 높은 요구 사항을 탐색 할 때 네이티브가 아닌 커서 대체가 될 가능성이 있습니다. 상관없이 필요합니다.

긴급 속보! 마이크로 소프트는 끔찍하게 코딩 된 느린 소프트웨어를 만들고 있으며, 문제는 MacOS 10에서 더욱 두드러집니다.

누가 추측했을까요?

@LandonPowell 문제에 대한 실제 토론을 오염시키고 있습니다. 여기 reddit / hackernews 여단은 우스꽝 스럽습니다.

터미널 커서는 어떻습니까? 이로 인해 CPU 주기도 급증합니까?

@mehas

CPU 대신 GPU를 사용하여 CSS 애니메이션을 렌더링하기위한 제안 :

CPU에서 GPU로 부하를 이동하여 문제를 숨 깁니다. 실제로 그것을 고치는 것은 아닙니다.

헉헉

CPU에서 GPU로 부하를 이동하여 문제를 숨 깁니다. 실제로 그것을 고치는 것은 아닙니다.

CPU 부하 가 문제입니다. GPU를 사용하도록 애니메이션을 최적화하면이 문제가 해결됩니다.

(이것은 내가 가장 좋은 수정이라고 제안한 특정 수정에 대한 질문과는 별개입니다)

그것을 재현하는 방법을 잘 모르겠습니다. vim 에뮬레이션 플러그인을 사용하고 있습니다. 관련이 있는지 확실하지 않습니다.

나는 이것이 어떻게 진행되는지 알고 싶습니다.

GPU를 사용하도록 애니메이션을 최적화하면이 문제가 해결됩니다.

그래도 불필요한 GPU로드가 발생합니다. 그래픽 카드의 프로세서에 부하가 있다는 점을 제외하면 유사한 문제입니다. 정말 수정이 아닙니다 😛

예수님은 아프리카에서 태어났습니다.

천만에요.

커서에 gif를 사용하지 않는 이유는 무엇입니까?

그래도 불필요한 GPU로드가 발생합니다. 비슷한 문제입니다

맞지만 유휴 상태에서도 CPU 사용량이 문제가 아닙니다.

@ efroim102 https://github.com/Microsoft/vscode/issues/22900#issuecomment -288832322

오, 신 이시여,이 논쟁은 목표가 무엇인지 결정될 때까지 계속 될 것입니다.

1. 배터리 소모량 감소
2. CPU 경합 감소

잠시 동안 (1)을 가정하십시오. 그런 다음 (a) 같은 양의 에너지를 사용하는지, (b) 더 적은 에너지를 사용하는지, (c) 더 많은 에너지를 사용하는지에 대해 CPU에서 GPU로 오프로드하는 것에 대해 좀 더 데이터 중심적 일 수 있습니다. 나는 이러한 문제에 대한 전문 지식이 없으므로 어느 것이 사실인지 예측할 수 없습니다.

그러나 GPU 오프로드가 (b)로 이어진다 고 가정 해 보겠습니다. 완벽하지는 않지만 Chromium이 근본적인 문제를 해결하는 동안이 경로를 추구 할 수있을만큼 절충안이 허용 될 수 있습니다. 그러나 VSCode 팀이이 문제를 한 번에 고칠 필요가 있다고 판단하는 경우 오프로드는 선택의 여지가 없을 것이며 장기적인 수정을 추구하는 것이 좋습니다 (아주 오래 걸리더라도). 적어도 내 소견으로는이 문제에 관심이 있고 종속성이 의도 한 수정을 가능하게 할 때 우선 순위가 지정된다는 것을 알면 충분할 것입니다.

(나는 어떤 솔루션이 사용 가능 / 차단되는지에 대한 미묘한 세부 사항을 혼동했다고 확신하지만, 사람들이 솔루션 공간으로 뛰어 드는 대신 해결하고자하는 문제를 주장하는 데 집중할 수 있기를 희망합니다.)

어느 쪽이든 렌더링 부하를 처리하기 위해 GPU가 더 잘 장착되어 있지 않을까요? 그것이 바로 그것이 만들어진 것입니다.

동의합니다. 우리는 CPU와 GPU를 다르게 사용하는 것에 우선 순위를두고 그래픽 관련 기능이 그래픽 관련 리소스를 사용하는 것이 더 합리적입니다. CPU의 이득은 GPU의 1 : 1 손실이 아니며 그 반대의 경우도 마찬가지입니다. 대부분이 시점에서 (Chromium의 버그가 패치 될 때까지) 논쟁이 있지만 현재 솔루션이 여전히 CPU를 사용하기 때문에 다소 관련이 있습니다 (무게는 훨씬 적음에도 불구하고).

나는 사람들이 데스크톱에서 웹 기술을 사용하지 말아야한다고 생각한다. 각 프로그램마다 완전한 브라우저를 제공해야하기 때문이다.
언급 한 프로그램이 여러 개인 경우 여기 저기에서 동일한 바이너리가 복제됩니다.

베어 메탈로 돌아 가야합니다.

추신 : JScript는 Obj-C가 그랬어 야했던 것처럼 10 년 전에 버려 졌어 야했습니다. Apple이 부활하지 않았다면 말입니다.
PPS : ^^^^ 이것은 폭언입니다.

PPS : ^^^^ 이것은 폭언입니다.

@ bit2shift 실제로

@ bit2shift- 일부 부분에 동의하지만 (브라우저 기반 앱이 실제 네이티브 앱에 비해 "네이티브"라고 느껴지지 않을 수 있다는 사실과 같은) "베어 메탈"수준은 얼마나 낮습니까? 기계 코드? 어셈블리어? 씨? C ++? 씨#? 기술 스택에 관계없이 항상 여러 계층의 추상화가있을 것입니다.

언급 한 프로그램이 여러 개인 경우 여기 저기에서 동일한 바이너리가 복제됩니다.

하지만 NuGet 패키지를 사용하는 모든 C # 앱과 동일합니다. 모든 어셈블은 앱에 로컬입니다. .NET Core는 프레임 워크의 많은 부분을 NuGet 패키지로 배포하기도합니다.

각 프로그램과 함께 완전한 브라우저를 제공해야하기 때문입니다.

기술적으로는 별도의 브라우저 런타임을 설치할 필요가없는 Edge 엔진을 사용할 수 있습니다. Internet Explorer 는 거의 20 년 전에 HTML 응용 프로그램으로 비슷한 일을했습니다 . 또 다른 예는 가능한 경우 OS의 기본 JS 엔진을 사용하는 React Native입니다. JavaScript 기반 앱의 경우 Windows 용 React Native와 같은 것이 네이티브 UI 위젯을 사용하므로 더 네이티브처럼 느껴지므로 웹 기술보다는 미래 일 것입니다.

헉헉

(...) "베어 메탈"은 얼마나 낮은 수준입니까? 기계 코드? 어셈블리어? 씨? C ++? 씨#?

기계 코드로 컴파일 할 수있는 모든 언어 ( source -> ELF/PE 계산)는이 컨텍스트에서 "베어 메탈"로 간주되므로 여기서 추상화 계층은 중요하지 않습니다.

Internet Explorer는 거의 20 년 전에 HTML 응용 프로그램으로 비슷한 일을했습니다.

mshta.exe 에서와 같이 "유사한 것"은 90 년대부터 system32에있는 mshtml.dll 를 사용합니다.

또 다른 예는 가능한 경우 OS의 기본 JS 엔진을 사용하는 React Native입니다. JavaScript 기반 앱의 경우 Windows 용 React Native와 같은 것이 네이티브 UI 위젯을 사용하므로 더 네이티브처럼 느껴지므로 웹 기술보다는 미래 일 것입니다.

데스크톱 JS 앱에서 고성능이 필요한 경우 손에 충분한 시간이있는 사람은 LLVM에 대한 프런트 엔드를 작성해야합니다.
임의의 코드 스 니펫을 실행할 수있는 능력을 잃게되지만 보안 관점에서 보면 이점이 될 것입니다.

/실

이 실을 탈선시킬 수 없습니까? 이것은 커서가 깜박이는 특정 성능 문제에 대한 문제이며 JS 기반 데스크톱 앱 개발의 일반적인 장점을 논의 할 장소가 아닙니다.

이러한 폭언에 관심이없는 사람들의 우편함을 스팸하는 것입니다.

2px * 10px 크기의 <input type=text> 를 커서가있는 곳에 두는 것은 어떻습니까? 이렇게하면 <input> : P <blink></blink> 의 기본 깜박이는 커서가 사용됩니다.

또한이 문제가 얼마나 심각한 지 잘 모르겠습니다. VSCode가 유휴 상태 일 때 (코드를 작성하고 있지 않음) 거의 항상 초점이 맞지 않고 다른 응용 프로그램에 초점이 맞춰져 있습니다. 커서가 깜박임을 멈 춥니 다.

내 경험상 gif는 그다지 좋지 않습니다. 나는 한때 gif 이미지로 로딩 스피너를 가지고 있었다. indexeddb와 상호 작용하는 동안 사용했습니다. 때로는 데스크탑에서도 스피너가 멈추는 것을 볼 수 있습니다.

터미널 커서 변경을 마스터 및 릴리스 /1.11로 눌렀습니다 (CSS 애니메이션-> setInterval ).

이 문제를 조사해 주셔서 감사합니다. 귀하의 조사와 제안은 근본 원인과 가능한 해결책을 찾는 데 도움이되었습니다! JavaScript setInterval , 애니메이션 GIF 및 기타 여러 기술을 비교하고 다음 솔루션을 결정했습니다.

• editor.cursorBlinking 가 blink 되거나 terminal.integrated.cursorBlinking 가 true 로 설정된 경우 깜박이는 논리가 이제 JavaScript에서 구현됩니다. 테스트 결과 CPU 사용량이 1 % 미만으로 떨어졌습니다.
• editor.cursorBlinking 이 CSS 여유 기능을 사용하는 smooth , expand 또는 phase 설정된 경우 커서가 다음 시간 동안 유휴 상태가 된 후 깜박이는 애니메이션을 중지합니다. 10 초.

이 수정 사항은 이미 Insider 빌드 에 있으며 향후 며칠 내에 릴리스 될 4 월 Stable 빌드에서 사용할 수 있습니다. 여러분 중 일부가 우리의 테스트 결과를 확인할 수 있다면 좋을 것입니다. 문제가있는 경우 새 문제를 작성하십시오.

@rebornix "또는" terminal.integrated.cursorBlinking 가 true 설정되어 있다고 하셨나요? 아니면 "and"가 의도적 이었습니까?

@jedmao 수정 or 합니다.