لم أر هذا على جهاز VM الخاص بي ، فقم بتخصيصه إلى Tyriar للتحقق مما إذا كان يراه أيضًا على نظام

ليس لدي كمبيوتر Linux المحمول معي في الوقت الحالي ، وسأحدد شهر أكتوبر لتذكيرني. @ ccalexandrudima /

لدي هذا ، رغم أنه غير موجود في كل مكان. لم تعد لوحة عرض الشجرة وجميع المحررين تمريرًا سلسًا ، ولكن الإدخالات التي (أفترض) ربما تستخدم عرض المتصفح ، مثل صفحات تفاصيل الامتداد ، لا تزال تقوم بالتمرير السلس.

ادارة:
قوس لينكس - x86_64 Linux 4.7.6-1-ARCH
جنوم شل 3.22.1

لا يمكنني معرفة اختلاف في عرض الشجرة أو المحرر الذي يقارن 1.6.0 و 1.5.3 باستخدام Ubuntu 16.04. bpaseroalexandrudima أي أفكار؟

نسخة طبق الأصل من https://github.com/Microsoft/vscode/issues/12637

لا أعتقد أن هذه نسخة مكررة من هذه المشكلة ، فهذه المشكلة تشير إلى أنها لا تعمل على الإطلاق ، في حين أن هذه المشكلة تتعلق تمامًا بالتمرير السلس: يعمل التمرير بإصبعين ، ولكنه يعمل مثل التمرير العادي "السريع".

أتفق مع @ jshap70 ، هذه مشكلة مختلفة كما وصفها.

أعتقد أن هذا هو الانحدار في Chromium (لقد لاحظته أيضًا هناك) والذي تم إصلاحه بالنسبة لي في 54.

يمكن تأكيد ذلك ، استخدام التمرير بإصبعين للمحرر بطيء. باستخدام الإصدار 1.6.1 على جهاز Windows 10 الخاص بي.

AFAIK لم تحدث أي تغييرات في منطق معالجة التمرير ، لكننا قمنا بالتحديث إلى إصدار إلكتروني أحدث (يتضمن Chromium 52).

سيكون من المثير للاهتمام معرفة ما إذا كان Chrome 52 يعاني أيضًا من هذه المشكلة. لدينا نفس رمز التمرير بالضبط في المحرر https://microsoft.github.io/monaco-editor/ لذلك إذا كان أي شخص يرغب في تجربته والإبلاغ عن النتائج هنا ، فسأكون ممتنًا.

هناك الكثير من مشكلات لوحات اللمس على Chromium: https://bugs.chromium.org/p/chromium/issues/list؟can=2&q=touchpad

هل نواجه مشكلة معروفة لهم؟

التمرير في موناكو سلس ويشعر تمامًا كما فعل vscode من قبل بالنسبة لي داخل Chrome (تجريبي) 55.0.2883.21 بالإضافة إلى Chromium 54.0.2840.71.
لقد قمت للتو بإنشاء إصدار من Chromium 52.0.2743.85 للاختبار ، ويمكنني التأكد من أنه يحتوي على نفس التمرير السريع. استخدام موناكو بداخلها صعب بشكل خاص. هذا يؤكد فكرة أنه من المحتمل أن يكون خطأ في الإلكترون وليس خطأ vscode. المشكله.

@ jshap70 شكرًا جزيلاً fyi bpasero

لقد اختبرت هذا اليوم أيضًا على جهاز Surface Book. إنها مشكلة حقيقية. الأكثر غرابة ، بعد استخدام الماوس قليلاً ، كانت لوحة التتبع تعمل بشكل طبيعي مرة أخرى. أنا آسف أنه لا يوجد شيء يمكنني القيام به من جانبنا ، فنحن نحصل على أحداث عجلة الماوس ونحترمها عندما نحصل عليها.

لم تتبنى Electron Chrome 54 بعد ، لكنها في خطتها.

@ jshap70 هل الإصلاح مضمن في Chrome 53 أو 54؟

bpasero لقد قمت للتو بإنشاء نسخة من Chromium 53.0.2785.92 ، وهي أعلى 53 نسخة متوفرة لدي ، ولا تزال تواجه مشكلة التمرير المتقطع عند استخدام موناكو. إذن 54 هو الإصدار الأول الذي تم إصلاحه عليه.

كنت ألعب مع هذا لفترة من الوقت. الاختبار باستخدام Lenovo Yoga 910 (Kaby Lake) - Windows 10 Pro.

أثناء الاختبار ، اكتشفت أن التأخر يحدث إذا قمت بتشغيل VS Code إلى أقصى حد. ظننت أنني ربما أصاب بالجنون ، لكن كل ما فعلته هو استعادة النافذة ثم إعادة تكبيرها إلى الحد الأقصى واختفت كل مخلفات التمرير.

فقط للتأكد من أنني لم أفقد الكرات الزجاجية الخاصة بي ، أجبرت زوجتي على اختبارها. كان اختلاف الليل والنهار. آمل أن يساعد هذا في تحديد المشكلة ، سأقوم بالغوص لإعطائها فرصة بنفسي الليلة أو غدًا.

لدي نفس مشكلة التمرير على Lenovo Yoga 910.
بعد تغيير حجم النافذة التمرير سلس مرة أخرى.

لدي جهاز Surface 4 Pro وأواجه نفس المشكلة. يؤدي تغيير حجم النافذة إلى إصلاح التمرير.

ربما ينبغي أن أذكر أن المشكلة التي كنت أتتبعها من خلال الكروم موجودة فقط بالنسبة لي على Lenovo W530 Thinkpad في Linux ، وليس Windows ، ولا يتم حلها عن طريق تغيير حجم النافذة. قد تكون هذه قضية مختلفة تماما.
هل يمكن لأي شخص يواجه هذه المشكلات محاولة تثبيت إصدار chrome أو chromium 52 أو 53 والتحقق مما إذا كانت موناكو لديها نفس المشكلة؟

أواجه هذه المشكلة على جهاز SurfacePro4. يؤدي استخدام لوحة اللمس إلى تأخر المحرر عند التمرير إذا كانت النافذة بالحجم الكامل. إذا قمت بتغيير حجم النافذة حتى أتمكن من رؤية سطح المكتب قليلاً ، فستختفي المشكلة.

حدثت نفس المشكلة بالنسبة لي باستخدام Win 10 و Surface Book الجديد. يمكن أن يؤكد أن تغيير حجم النافذة وإعادة تكبيرها يبدو أنه يحل المشكلة (على الأقل حتى الآن).

أنا حاليًا أستخدم أحدث إصدار مع Dell XPS 15 9550 (إصدار شاشة تعمل باللمس ، Win10 x64) وأواجه هذه المشكلة بالضبط. لم أكن أعرف حتى أنه لا يحدث عندما أستخدم تمرير الشاشة التي تعمل باللمس ، فقط باستخدام لوحة اللمس.

تعمل خدعة تغيير الحجم / التكبير على إصلاحه قليلاً على الأقل.

نفس المشكلة هنا. Surface Book / Windows 10 ، ولكن يعيد تعظيم الحلول. سيكون من الرائع ألا تضطر إلى ذلك في كل مرة أقوم فيها بفتح VS Code.

منذ أن تم دمج Chromium 54 في Electron ، فربما يمكن لـ VSCode التبديل إلى Electron الجديد لحل المشكلة بالتأكيد؟

لا يوجد حتى الآن إصدار Electron مع Chrome 54 out.

من المفترض أن يتم إصدار الإلكترون مع Chrome 54 في يناير

من الإلكترون / سحب / 8406

(...) سنقوم بإصدار هذا الإصدار التجريبي 1.5.0 إلى npm الآن

هل هناك طريقة لإعلامك عندما يقوم المطلعون بالتحديث إلى الإلكترون الجديد؟

أنا في انتظار الإلكترون الجديد أيضًا. إن وجود مثل هذه الشاشة الجميلة والمحرر الذي يعاني من التمرير الرهيب أمر سيء للغاية.

توجد هذه المشكلة أيضًا في Dell XPS 13 9360 QHD في أواخر عام 2016. لاحظت أن لوحة اللمس فقط (برامج تشغيل دقة Windows) هي التي تتأثر أثناء التمرير بشاشة تعمل باللمس تعمل بشكل جيد.

لا تزال هذه مشكلة في 1.10.2 (Dell XPS 15 ، شاشة اللمس سلسة)

إذن ما هي المشكلة الآن؟ وأشير إلى أن هذا كان يجب أن يتم إصلاحه في يناير.

أود أن أكرر تعليقي السابق بأن هذه المشكلة المحددة لا تتعقب المشكلة حقًا على النوافذ ، لأن المعلومات التي نشرتها حول التمرير المكسور في الكروم كانت مرتبطة بنظام التشغيل Linux.
ومع ذلك ، لا تزال المشكلة موجودة في الإصدار الحالي من vscode

يمكننا تطوير التمرير السلس المخصص كما هو الحال في atom وهو مرتبط أيضًا بـ https://github.com/Microsoft/vscode/issues/21359

تستخدم شفرة pixieaka حاليًا التمرير الأصلي لـ chrome ، والذي في رأيي الشخصي أفضل بكثير من أي شيء تم إنشاؤه فوقه عندما يعمل بشكل صحيح. علاوة على ذلك ، تم إصلاح التمرير ويعمل بشكل صحيح عند إجراؤه في موناكو على إصدارات أحدث من الكروم (انظر هنا ) ، وهذا هو السبب في أنه من المعروف أنه مشكلة إلكترونية. لذلك ليست هناك حاجة حقيقية لإعادة كتابتها لأنها ليست مشكلة في التعليمات البرمجية.

إنهم بحاجة فقط إلى انتظار تحديث الإلكترون إلى Chromium 54 ، والذي أعتقد أنه يمكن تتبعه هنا

@ jshap70 Electron v1.6.2 تم إصداره بالفعل مع Chromium (56.0.2924.87) منذ 16 يومًا

@ jshap70 https://github.com/Microsoft/vscode/issues/11953 تم إنشاء هذا باستخدام أحدث إصدار من Electron 1.6.2 مع Chromium (56.0.2924.87) لنظام التشغيل Windows هنا: https://az764295.vo.msecnd.net/insider /d42d4467e681308a5f82b61cb11ee6b91f1b9864/VSCode-win32-1.11.0-insider.zip

لكن مشكلة التمرير لم تحل بعد

pixieaka أي مشكلة في التمرير؟ هذه المشكلة تتعلق بالتمرير على نظام Linux وليس windows

@ jshap70 https://github.com/Microsoft/vscode/issues/20840 لدي نفس المشكلة مع كمبيوتر Dell المحمول على Windows 10. التمرير سريع للغاية مع لوحة التتبع .

pixieaka قد يكون مرتبطًا بتمرير التأخير في النوافذ. أواجه نفس المشكلة هنا. https://github.com/Microsoft/vscode/issues/20348#issuecomment -291060102

هذا يقودني للجنون ، يجب أن أستعيد / أعظم كل دقيقة أثناء العمل. أي تحديثات على هذا؟

يأتي إصدار اليوم من VS Code Insider مع Electron 1.6.x ، وسيكون من المثير للاهتمام معرفة ما إذا كان هذا التحديث يحل هذه المشكلة لأي شخص: http://code.visualstudio.com/Download#insiders

bpasero لا أعتقد أن هذا الرابط يعمل ، فهل يجب أن يكون https://code.visualstudio.com/insiders بدلاً من ذلك؟
سوف أتحقق من ذلك عندما تسنح لي الفرصة وأعلمك بذلك.

bpasero يسعدني أن أقول إن التمرير السلس قد عاد في أحدث إصدار من المطلعين! على لينكس ، هذا هو.

رائع شكرا!

على Dell XPS 13 SkyLake ، Precision TouchPad ، Windows 10 @ 125٪ تحجيم ، لا يزال يعرض نفس المشكلة بالنسبة إلى الإصدار الحالي من الداخل a5e9d3

بعض مزيد من المعلومات:

يبدو أن الشاشة يتم تحديثها فقط في وضع scoll-end. لذا انتقل بإصبعين ... (يبدو أنه لم يحدث شيء / تم تجميده)
ثم ارفع أصابعك <- تحديثات الشاشة.

آسف للتعليق المزدوج ، لكنني وجدت أن استخدام "--disable-gpu" يجعل التمرير سلسًا للغاية مرة أخرى بالنسبة لي.

بفضل https://github.com/Microsoft/vscode/issues/14716#issuecomment -293120446 للنصيحة.

هل هناك أي طريقة لجعل هذه العلامة قيد التشغيل دائمًا ، حتى عند تشغيل الكود من قائمة السياق؟
تحرير: لا يبدو

سيكون وجود طريقة لتشغيل التعليمات البرمجية مع معلمات محددة فكرة جيدة (ماذا عن startup.json في ~ التي سيتم استخدامها لمعلمات سطر الأوامر؟) ولكنني أفضل رؤية المشكلة المتعلقة بوحدة معالجة الرسومات ثابتة.

ما هو الخطأ في إنشاء نص برمجي شل عمومي يتم تشغيله code --disable-gpu ؟

لا حرج في وجود اختصار عالمي. لكن تعطيل وحدة معالجة الرسومات لإيجاد حل بديل للخلل ليس جيدًا جدًا إذا سألتني. يمكن أن يكون لاستخدام وحدة معالجة الرسومات بدلاً من وحدة المعالجة المركزية للعرض / التمرير تأثير كبير على البطارية والأداء وما إلى ذلك.

تم اختباره للتو على xps ، ويبدو واعدًا جدًا! عند التثبيت النظيف ، يكون الانطباع الأول سلسًا جدًا. سوف أحتاج إلى رؤية كيف يكون الأمر مع جميع الإضافات ولكن هناك أمل الآن.

يمكن التأكيد ، Dell XPS 15 9560 + Windows 10 Creators Update ، --disable-gpu يعمل كحل بديل.

لا يزال غير سلس على سطح الكتاب ، حتى تشغيل --disable-gpu

أؤكد أنه ليس سلسًا على Surface Book (تحديث المبدعين): لم يعد يقفز كثيرًا ، لكنه بطيء جدًا.

هل حصل أي شخص في فريق Code الأساسي على مثل هذا الجهاز أم أن الجميع يعمل على Mac؟ :)

warpdesign أنا على Surface Book. الحل البديل الخاص بي هو "استعادة" و "تكبير" نافذة VS Code مرة واحدة بعد أن أفتحها. يصبح التمرير بإصبعين على لوحة التتبع سلسًا بالنسبة لي.

لقد بدأت صفحة wiki لجمع / تلخيص المعلومات المبلغ عنها حول هذه المشكلة - https://github.com/Microsoft/vscode/wiki/Known-issues

تعطيل gpu لا يعمل على xps 15 "، تقليل / تكبير الأعمال ولكن لفترة قصيرة فقط ، يجب الاستمرار في القيام بذلك. لا تزال نفس المشكلة في الإصدار الأخير.

يعمل vladkosarev معي ، هل حاولت التحديث إلى أحدث برنامج تشغيل رسومات Intel من موقعه على الويب؟

لست متأكدًا مما إذا كان قد تم ذكره ، لكن هذه مشكلة تتعلق بالإلكترون. نفس الشيء يحدث لي في عميل سطح المكتب Slack.

لدي مشكلة أيضًا ، على كمبيوتر محمول ASUS Zenbook. يبدو أن إلغاء التصغير (وإعادة التكبير) يؤدي إلى حل المشكلة مؤقتًا.

• إصدار VSCode: الكود 1.12.1 (f6868fce3eeb16663840eb82123369dec6077a9b، 2017-05-04T21: 26: 50.689Z)
• إصدار نظام التشغيل: Windows_NT ia32 10.0.14393
• ملحقات:

| ملحق | المؤلف | الإصدار |
| --- | --- | --- |
| EditorConfig | EditorConfig | 0.9.3 |
| CppSnippets | hars | 0.0.9 |
| التبانة | جيدماو | 0.0.9 |
| المضاعفة السياقية | lafe | 0.2.0 |
| cpptools | ms-vscode | 0.11.0 |
| مسافات زائدة | shardulm94 | 0.2.11 |
| vscode-fileutils | sleistner | 2.5.1 |
| نينجا | surajbarkale | 0.0.1 | ؛

لدي نفس المشكلة على جهاز Dell XPS 9560. لقد وجدت حلاً غريبًا

انقر بزر الماوس الأيمن على شريط المهام وحدد إعدادات شريط المهام
قم بتغيير اتجاه شريط المهام إلى عكس ما هو عليه في الوقت الحالي ، على سبيل المثال ، إذا كان الجزء السفلي ، قم بتعيينه إلى أعلى أو العكس. إذا كان اليسار ثم اليمين وما إلى ذلك
قم بتغيير شريط المهام إلى الاتجاه الأصلي أو اتركه كما هو ، لا يهم.
التمرير بسلاسة مرة أخرى
لا بد لي من القيام بذلك في كل مرة أبدأ فيها VS Code لكنه يعمل.

أيضا تواجه المشكلة. تصغير / تعظيم الحيلة تساعد ولكن من المؤكد أنها مزعجة. لسوء الحظ ، لا توجد معلومات حديثة بخصوص هذه المشكلة في ريبو إلكترون .

الكمبيوتر المحمول: Dell XPS 9560
نظام التشغيل: Win 10 Pro 10.0.15063
كود VS: 1.12.2

نفس المشكلة هنا مع Acer Nitro 15.

الكمبيوتر المحمول: Acer V Nitro 15
نظام التشغيل: Win 10 Pro
كود VS: 1.14.0-insider

نفس المشكلة هنا على أيسر. نافذة الاستعادة / الحد الأقصى للرمز والتمرير بإصبعين يعملان مرة أخرى.

الكمبيوتر المحمول: Acer Aspire F5-573
نظام التشغيل: Win 10 Home 1703
كود VS: 1.13.0

تمت ترقية كود VS إلى المطلعين بناء 1.14.0 ولا تزال المشكلة.

يمكن حله إما عن طريق استعادة / تكبير النافذة أو تشغيل التعليمات البرمجية باستخدام --disable-gpu.

نفس المشكلة على Surface pro 4. (I5 ، 8 جيجابايت ، 256 جيجابايت).
نظام التشغيل: Win 10 Home 1703
كود VS: 1.13.0
يمكن حلها عن طريق تغيير حجم النافذة.

لست متأكدًا مما إذا كان سيساعد أم لا ولكني وجدت هذه المقالة المفصلة بشكل يبعث على السخرية عند التمرير :) https://pavelfatin.com/scrolling-with-pleasure/

نفس المشكلة هنا.
نظام التشغيل: Win 10 pro build 14393
كود VS: 1.13.1

أعتقد أنه مرتبط بنظام التشغيل. لا تدعم التطبيقات المدمجة في Win 10 تمرير TrackPoint بشكل جيد ، وقد يستخدم الرمز بعض lib داخل نظام التشغيل.

حل مؤقت سريع: Win + DOWN ، Win + UP

أنا على المطلعين ، Surface Book (طراز i5 8 جيجابايت) ، التمرير بطيء للغاية.

ماذا عن حصول شخص من فريق VSCode على جهاز Surface Book (أو أي لوحة لمس دقيقة) ويرى بالتأكيد ما هو الخطأ ويتم تقديم الإصلاح المناسب (أو الحل البديل)؟

تعد أجهزة Surface هي الأجهزة الرئيسية لشركة Microsoft لنظام التشغيل Windows 10: لقد أغضبني أن أداء VSCode سيء جدًا على مثل هذا الجهاز الجميل (بالإضافة إلى منعني من القيام بأي عمل جاد عليه باستخدام VSCode).

warpdesign يمتلك بعض أعضاء فريق VSCode أجهزة Surface وهم على دراية بالمشكلة ( راجع مؤشر الترابط ). على الرغم من أنها مزعجة للغاية ، إلا أنها مشكلة أولية لا يمكن لأحد حلها بعد.

لست متأكدًا جدًا من أن بعض الأشخاص يعملون على ذلك بالفعل .. أعتقد أن Electron تقول فقط إنها مشكلة في Chrome ، لكنني لم أتمكن من العثور على خطأ في أداة تعقب المشكلات ، باستثناء هذا الخطأ ، الذي ليس له نشاط على الإطلاق يحدث .. هل يعرف أحد ما إذا كان هناك من يعمل على هذا؟

إنه يحدث بالنسبة لي أيضًا على جهاز 4K XPS 9550 الخاص بي وهو يقودني إلى الجنون. أنا أحب VS Code كثيرًا ، لكن الاضطرار إلى تصغيرها / تكبيرها كل 5 دقائق أمر مزعج للغاية ...

https://bugs.chromium.org/p/chromium/issues/detail؟id=713907

tobiasviehweger ليس من المستغرب أنه لا يزال هناك :(

هل يمكن إعادة ظهور المشكلة على Chrome مع Monaco؟ أم أنها خاصة بـ VSCode + Electron؟

التمرير متقطع وغير مجدية بشكل أساسي على Dell XPS13 / Windows 10 حتى جربت خدعة gpu -disable-gpu. ليست مثالية. أي علامة على انتقال الإلكترون إلى Chromium أحدث؟

+1 يعاني من مشكلة هنا.
لقد اشتريت بالفعل Surface Book بسبب لوحة اللمس الرائعة ولوحة المفاتيح ، ومعظمها للعمل ، لذا فهي مشكلة حرجة بالنسبة لي ، وأنا أفكر في إعادة Surface Book وشراء mac مرة أخرى :(
إصدار VSCode الخاص بي:

جزء آخر من البيانات:
تعمل لوحة اللمس على جهاز Mac Air 11 القديم (مع تثبيت Win 10 ، وليس macosx) بشكل رائع في VSCode.
الإصدار:

إصلاح الثابتة والمتنقلة؟

بعض التفاصيل.

ما يحدث بالضبط على جهاز Surface Book هو أنه عندما أسحب لأعلى / لأسفل بإصبعين:

• في معظم الأحيان ، يتم تمريره ، ولكن after a 1 second lag
• أحيانًا لا يحدث شيء على الإطلاق ، كما لو أن الحدث لم يصل إلى VSCode
• في بعض الأوقات النادرة ، يحدث التمرير في الوقت المناسب

كما ترى ، هذا غير موثوق به للغاية ويجعل VSCode غير قابل للاستخدام على هذه الأجهزة.

أردت أن أرى ما حدث لأحداث DOM ولكن في المرة الثانية التي فتحت فيها أدوات التطوير ، بدأ التمرير في العمل كما هو متوقع ، أي بدون تأخير لمدة ثانية واحدة وفي كل تمريرة. هذا يجعل من الصعب المساعدة في تتبع المشكلة.

kokajambo @ Deiru2k هل هذا ما تعاني منه أيضًا؟

لقد اكتشفت أن: مجرد إظهار أو إخفاء القائمة الرئيسية يعمل بنفس طريقة تغيير حجم النافذة. لذلك ، إذا كانت القائمة مخفية عادةً ، فإن الضغط مرتين على مفتاح alt عندما يصبح التمرير صعبًا سيجعل الأمر سلسًا مرة أخرى لفترة من الوقت ..

هل تم تحديث الإلكترون؟

نعم ، لقد قمنا بتحديث Electron عدة مرات منذ الإبلاغ عن هذه المشكلة لأول مرة. في الوقت الذي تم الإبلاغ فيه عن المشكلة ، كنا نستخدم إصدار Electron المبني على Chromium 52. نحن الآن على Chromium 56 ، بينما متصفح Chrome موجود على Chromium 60.

قضايا المنبع:
الإلكترون: https://github.com/electron/electron/issues/8960 (مغلق لصالح قضية Chromium)
Chromium: https://bugs.chromium.org/p/chromium/issues/detail؟id=713907 (لم يتمكن مالك إصدار Chromium من إعادة الإنتاج باستخدام Chromium 58)

إذا أردنا أن نكون متفائلين ، فبمجرد التحديث إلى إصدار Electron المبني على Chromium> = 58 ، يجب إصلاح هذه المشكلة.

إذا لم يتم إصلاح المشكلة ، فسنحتاج إلى طلب المزيد من المساعدة من أصدقائنا في Electron ، حيث قد يكون ذلك مؤشرًا على أن هذه مشكلة خاصة بالإلكترون.

في غضون ذلك ، يستمر الحل البديل في العمل (قم بتغيير حجم النافذة مرة واحدة بعد فتحها).

لدي هذه المشكلة أيضا.
إصدار VSCode: كود 1.14.2 (cb82feb، 2017-07-19T23: 34: 09.706Z)
إصدار نظام التشغيل: Windows_NT ia32 10.0.15063

باستخدام رمز - تعطيل gpu حل المشكلة

يمكنني تأكيد هذه المشكلة على جهاز razer stealth ، مما يقلل / يزيد من إصلاحاته لبعض الوقت.

@ IanNS333 كذلك هنا ، مع Dell XPS 13 (9350).

يبدو هذا أسوأ بعد التحديث الأخير.

لقد كانت متقطعة ولكنها ستختفي إذا قمت بتغيير حجم النافذة وقمت بتكبيرها مرة أخرى كما ذكر الآخرون الآن. الآن لا يتم التمرير على الإطلاق. تبدو النافذة نفسها وكأنها "ترتد" قليلاً عند قيام اثنين من أداة البحث بالتمرير.

استخدام Samsung Notebook 9

لقد اصطدمت للتو بهذه المشكلة على ASUS UX501JW وقمت ببعض الأبحاث.

وصف المشكلة: يعمل التمرير على كل إصدار عندما أقوم بتشغيل Chrome أو Electron بشكل طبيعي ، إذا قمت بتشغيل كمسؤول ، فلن يعمل أي من الإصدارات المختبرة.

تم اختبار الإصدارات:
- Chrome 62 (متصفح مستقل ، كناري)
- كروم 60 (متصفح مستقل)
- كروم 58 (الكترون 1.7.5)
- كروم 56 (إلكترون 1.6.6)
- كروم 54 (متصفح مستقل)
- كروم 51 (متصفح مستقل)

نظام التشغيل: Windows 10

هذا الخطأ ليس في VS-code أو Electron ، بل في Chrome أو في كيفية كتابة أدوات اللمس. أردت فقط إضافة بعض المعلومات المتعلقة بالنتائج التي توصلت إليها أنه لا يوجد ضوء في النفق لأجهزة الكمبيوتر المحمولة من ASUS.

عند الحديث عن أجهزة الكمبيوتر المحمولة ASUS (UX360CAK هنا) و Windows 10 ، كان التمرير على مستوى النظام شديد الصعوبة بالنسبة لي في الشهر الماضي أو نحو ذلك. على سبيل المثال ، عندما أقوم بتمرير الزخم لأسفل صفحة (Chrome) أو قائمة بالعناصر (Thunderbird ، ولكن ليس File Explorer) ، سيتم إعادة تعيين موضع التمرير إلى أعلى القائمة بشكل عشوائي.

شيء آخر هو أنني اضطررت إلى إيقاف التكبير / التصغير لأن مقدار الاكتشافات الخاطئة كان لا يطاق - ومع ذلك لم أواجه أي مشاكل مع هذا من قبل. كانت العودة إلى لوحة تعقب Macbook Pro بمثابة نوع من الوحي الديني.

(تحرير: حذف المنشور الخاص بي حول إلغاء تثبيت الأداة المساعدة asus والتراجع عن برنامج تشغيل لوحة اللمس لنظام التشغيل Windows الأصلي حيث لا يبدو أن أيًا منهما قد حل المشكلات المتعلقة بالغرابة وربما (tbd) vscode)

youurayy Yep ، Dell XPS 13

youurayy لقد اكتشفت حلاً

يعمل حول:

• اقتل تطبيقات ASUS Smart Gesture في مدير المهام ،
• أعد تشغيل تطبيقات Smart Gesture مع التشغيل كمسؤول (AsusTPCenter.exe ، AsusTPHelper.exe ، AsusTPLoader.exe)

التخمين المتعلم هو أن هذه المشكلة لها جذور في شيئين:

• من المحتمل أن ترسل ASUS Smart Gestures أحداث اللمس الخاصة بهم بطريقة غريبة إلى نوافذ أخرى ، لقد رأيت مناقشات أنها لا تتبع معيار لوحة اللمس من Microsoft
• يحظر Chrome الأحداث من العمليات التي لا تعمل بشكل مرتفع إذا كان Chrome يعمل بشكل مرتفع

لا توجد طريقة للتخلص من Smart Gesture ولا يزال بإمكانك التمرير على طراز ASUS الجديد ، ولكن هذا يعطي شيئًا يمكنني العمل معه.

نجاح باهر تم نشر هذا أكتوبر 2016؟ آمل حقًا أن يتم إصلاح هذا عاجلاً. لقد نشرت إصدارًا جديدًا رقم 35844 والذي كان خداعًا وأغلق. لقد اكتشفت أنه عند تعطيل كافة المكونات الإضافية ، كان ذلك أفضل ، ولكن ليس سلسًا تمامًا. لكن هذا أيضًا ليس بالحل الأمثل أيضًا. التأخر بالنسبة لي هو ما يقرب من 1/2 ثانية على i7 Surface Book. لقد جربت الخيار code --disable-gpu وهو أيضًا ليس سلسًا تمامًا ، ولكنه أفضل ، لذا فهو حل بديل.

ثبت أن ربط الماوس يعمل كحل بديل بنسبة 100٪. وهو نوع من السخرية.

@ Deiru2k نعم ، تمرير عجلة الفأرة على ما يرام ، لكن الماوس لا يتم

لا يزال هذا يحدث بالنسبة لي على Dell XPS15 الخاص بي مع أحدث VSCode (تم التحديث اليوم). عملي هو النقر فوق win + down-arrow و win + up-arrow. يؤدي هذا إلى تغيير نافذة VS Code بحيث لا يتم تكبيرها ثم إعادة تكبيرها مرة أخرى. هذا يعمل ، لكنه مزعج حقًا.

راجع للشغل ، معلومة أخرى. إذا اختبرت التمرير السلس بإصبعين في Visual Code 1.17.0 على سطح المكتب الذي يحتوي على لوحة اللمس من Logitech ، فيبدو أنه يعمل بشكل جيد. ربما هذا شيء متعلق ببرامج تشغيل لوحة اللمس المحددة؟ على Surface Book ، يكون متشنجًا ولا يستجيب. لكن Chrome و Edge سلسان تمامًا. ربما لا يتعلق الأمر تمامًا بالتطبيق ، أو ربما السائقين ، أو ربما هو المعدل الذي تختبره إلكترون؟ لا اعرف حقا.

أواجه هذه المشكلة على Surface Pro 4 ، vscode 1.17.0.
تعظيم / تصغير المساعدة مؤقتًا كما ذكر البعض الآخر.

المشكلة خاصة بأجهزة معينة. يتصرف جهازي الشخصي (كمبيوتر محمول من نوع asus rog) تمامًا كما تتوقع أن يتصرف التمرير بإصبعين ، بينما أبلغت آلة العمل الخاصة بي (كمبيوتر محمول دقيق من Dell) هنا.

أيضًا ، لتكرار ما ذكره الآخرون من فريق vscode بالفعل ، يبدو أن هذه مشكلة في الإلكترون (والتي يمكنني تأكيدها ، حيث يمكنني إعادة إنتاج المشكلة في تطبيقات إلكترونية أخرى) ، وعلى الأرجح غير قابل للإصلاح بواسطة فريق vscode ، لسوء الحظ.

وفقًا لمؤشر إصدار الإلكترون هذا ، فإن المشكلة تتعلق بالكروم نفسه.

هذا ما وجدته في متتبع أخطاء الكروم: (رابط)

EthanRutherford هل جربت الحل البديل لـ ASUS المذكور في https://github.com/Microsoft/vscode/issues/13612#issuecomment -324351903؟

تؤدي إعادة تشغيل AsusTPLoader.exe كمسؤول إلى حل مشكلة أجهزة الكمبيوتر المحمولة من ASUS التي اختبرناها. لقد قمنا حتى ببناء وحدة عقدة في تطبيق Electron الخاص بنا والتي تقوم بذلك تلقائيًا لأننا لا نستطيع أن نتوقع أن يقوم المستخدمون النهائيون لدينا بهذا العمل.

EthanRutherford لست متأكدًا من أن هذه هي نفس المشكلة مثل الإلكترون / # 8960 في تقرير خطأ الكروم ، يقول المستخدم إن تعطيل تسريع الأجهزة لا يحل المشكلة.

بالإضافة إلى أنني لم أواجه المشكلة في Chrome.

لقد واجهت بالفعل شيئًا مشابهًا مع Chrome في وقت ما. وفي ذلك الوقت ، ساعدت خدعة تقليل الاستعادة أيضًا. ربما يستخدم Chrome Electron أيضًا.

mogemimi في الواقع الصحيح : يعتمد Electron على Chrome.

وجود هذه المشكلة أيضًا على Dell XPS 13.

robinwassen الكمبيوتر المحمول asus هو في الواقع الذي يتصرف بشكل صحيح. لوحة التتبع من Dell هي التي تواجه المشكلة. عادةً ما أعمل باستخدام ماوس USB ، لذلك لا أواجه المشكلة كثيرًا.

ذكرت dopare أن تغيير حجم الرمز المرئي يصحح المشكلة. انه علي حق. من المحتمل أن تكون المشكلة مع الحاوية (الإلكترون).

بالمناسبة لدي نفس المشكلة في Chrome نفسه.
تم العثور على مشكلة ذات صلة محتملة https://bugs.chromium.org/p/chromium/issues/detail؟id=765311

مع dell xps لدي نفس المشكلة ، تغيير الحجم يساعد لفترة من الوقت ، وليس لدي هذه المشكلة مع الكروم ، فقط vscode.

نفس المشكلة على Schenker XMG P507 (Win 10 ، CPU / GPU: i7-7700HQ ، Touchpad: Synaptics SMBus). أسوأ بما يكفي لجعل التمرير باستخدام لوحة اللمس غير قابل للاستخدام. لا مشاكل في جوجل كروم.

نفس المشكلة على كتاب السطح مع قاعدة الأداء ، نظامي أدناه

ليس لدي مشكلة في أحدث الكروم

version 1.17.1
shell 1.7.7
chrome 58.0.3029.110
node 7.9.0
arch ia32

saedrna لدي تمرير بطيء على Surface Book أيضًا ، ولكن فقط عند استخدام الشاشة الداخلية عالية الدقة. هل توصيل شاشة خارجية (شاشة عادية وليست بدقة 4K) يجعل التمرير أسرع؟

يجعل ملف الشارب 40 (نعم ، أربعون) سطرًا من التمرير vscode فوضى بطيئة ، لذا اشتبه في وجوده في الإلكترون أيضًا.

بعد الانتقال من 1.17.2 إلى 1.18.0 ، تم إصلاح أداء التمرير الداخلي.

هل يريد أي شخص آخر تجربة الإصدار الحالي من الداخل والإبلاغ عن نتائجه؟

لقد جربته للتو على جهاز Surface Book (أحدث إصدار لمعاينة الرمز المرئي) وهو أفضل بكثير. إنها ليست لفيفة زبدانية كما يتوقع المرء ، لكنها أفضل بكثير من ذي قبل.

لا يزال مكسورًا بالنسبة لي - إصدار VSCode: Code - Insider 1.18.0-insider (e6a76e4bd3f52ab07452bb181e861f5a9bfb6596، 2017-10-27T04: 19: 22.491Z)

(لوحة اللمس الدقيقة طراز XPS 13 من Dell)

1. قائمة ابدأ في Windows -> Code Insiders
2. يفتح Code Insiders مكبراً إلى مشروعي السابق
3. لا يزال التمرير غير قابل للاستخدام (لا يتحرك أثناء التمرير ، ثم يقوم فجأة بقفزة هائلة بعد مرور بعض الوقت)

أخبار جيدة!

تم التقاط هذا من قبل فريق Chrome: https://bugs.chromium.org/p/chromium/issues/detail ؟id=779372

عظيم. رمز Vs ليس سيئًا على الإطلاق ، لكن هذه المشكلة دفعتني إلى الجنون لدرجة أنني توقفت تمامًا عن استخدامه.

CoenraadS التي ذكرتها من قبل:

إذا بدأ VSCode فارغًا ثم فتحت مجلدًا يعمل بشكل جيد.

قد يكون من المفيد حفظ ذلك كمسألة منفصلة عن أداء التمرير العام ، حيث من المحتمل أن يكون لها سبب مختلف.

كنت أستخدم VSC في Windows 10 و Ubuntu 17.10 (Gnome 3.26 على ما أعتقد) وكنت أعمل بشكل مثالي ، وأرى الآن هذه المشكلة في Fedora 27 أيضًا مع Gnome 3.26.2.
أنا أقوم بتشغيل VSCode 1.19
يحدث هذا أيضًا على تطبيقات Electron الأخرى ، مثل Atom.
تغيير حجم النافذة لا يناسبني: [

فهل كل شخص هنا لديه مشاكل فقط في VS؟ لديّ Dell Inspiron 7577 Gaming وهذه مشكلة التمرير موجودة في كل شيء تقريبًا. الكسوف والكروم هو الأسوأ. إنه أيضًا على Discord و Slack ومحرر نص Atom وشجرة المصدر. إنه يقودني إلى الجنون لدرجة أنني على وشك إعادة هذا الكمبيوتر المحمول.

@ RJ-Fynydd لدي نفس المشكلة في Sublime أيضًا ، على HP Specter x360. إذا كنت أتذكر بشكل صحيح ، فقد كان لدي في Chrome ولكن "أصلحته" عن طريق تعطيل التمرير السلس في chrome: // flags /.

كان هذا يحدث على جهاز Surface Book بشكل سيء للغاية وكان ملحوظًا للغاية. لقد أدى شيء ما خلال الإصدارين الأخيرين إلى تحسينه (أنا على 1.18) ، ومع ذلك ما زلت ألاحظ أنه أصبح سريعًا بعض الشيء بعد الاستخدام. في الاستخدام ، أعني فتح ملف كود كبير ، والتمرير ، والعمل على الملف ، والحفظ ، والتبديل إلى ملفات أخرى ، والعودة. يبدو أن تغيير حجم النافذة لا يزال يصححها ، لذا لا يزال هناك شيء غريب مع توقيت دورات المسح باللمس / التمرير.

ما زلت غير ملساء على كتابي السطحي ، لا أستطيع أن أصدق أنني أقف عليه لمدة عام تقريبًا

ivyhaswell هل لديك أحدث نسخة من الكود المرئي؟ ماذا يحدث عند تغيير حجم IDE؟ هل تذهب بعيدا؟

إذا كنت تستخدم Gnome ، فيمكنك إصلاح ذلك باستخدام Xorg بدلاً من Wayland.
يمكنك تغييره قبل تسجيل الدخول.
الحياة رائعة مرة أخرى.

alanosman الإصدار 1.8.1 ، سيأتي التمرير بشكل طبيعي لعدة دقائق بعد تغيير الحجم.

ivyhaswell حسنًا - هذا يؤكد أن لدينا نفس المشكلة على Surface Book. آمل أن يتولى شخص أكثر مهارة مني هذه المشكلة. :-)

يبدو أن هذا يحدث على Macbook Pro (2015 ، Retina) أيضًا. كانت تعمل بسلاسة فائقة ، والآن مع فتح مشروع صغير جدًا ، Chrome و Slack وعدد قليل من الآخرين (لا تتجاوز وحدة المعالجة المركزية 1-3 ٪ ، ذاكرة الوصول العشوائي 9.4 / 16 جيجابايت المستخدمة) تتأخر عند التمرير.

المشكلة لا تزال قائمة. لدي Dell XPS 13 2017 ، win10. لحسن الحظ ، تم إصلاح تغيير حجم النافذة ، كما أشار بعضكم هنا. شكر

لقد جئت للتو إلى هنا بحثًا عن حل لهذه المشكلة.
وأرى أن المشكلة مستمرة منذ أكثر من عام .....
أنا أستخدم Asus Strix ROG GL753.

هو ، اعتقدت أنه سيكون خطأي ولكن من الجيد أن أرى وجود عمل (نافذة تغيير الحجم). أنا أستخدم لوحة التتبع الدقيقة من Asus.

وجود نفس المشكلة (Lenovo Ideapad 720s / 8th gen i7 / 8 gb ram / nvidia geforce mx150)

نفس الشيء هنا ، التمرير غير المستقر للغاية باستخدام لوحة اللمس الخاصة بي مع Windows Precision Drivers. احيانا تعمل و احيانا لا. الإصدار VS Code: 1.18.1 x64

الحصول على نفس المشكلة أثناء التمرير على جهاز Surface Pro (2017)

هذه القضية لا تزال موجودة في الليل. أنا أستخدم الجيل الأول من Surface Book i7. لست متأكدًا مما إذا كانت هذه مصادفة توقيت ، لكنني بدأت فقط في ملاحظة هذه المشكلة بعد الترقية إلى Fall Creators Update.

أعتقد أن هذه المشكلة تتطور ببطء إلى ميزة 😄

تم حلها في chormium منذ 11 ساعة: https://chromium-review.googlesource.com/c/chromium/src/+/809829#message -85e8d8e27337bf85caecffcd4978f979a67f1378.
لا يزالون يراقبون ، حيث أن رمز عربات التي تجرها الدواب المضافة يتعلق بسلاسل gpu.
خطأ الإلكترون المتعلق بهذه المشكلة: https://github.com/electron/electron/issues/8960

آمل أن يظهر التصحيح قريبًا لشفرة vscode :)

نفس المشكلة مع جهاز skylake XPS13

المشكلة نفسها. آمل أن يتم إصلاحه قريبًا

يبدو أن Chrome يختبر إصلاحًا لهذه المشكلة (عبر https://bugs.chromium.org/p/chromium/issues/detail؟id=713907#c28) وقمت بإصدار نسخة مطلعة من VS Code مع هذا التصحيح الخلفي. لقد أجريت بعض الاختبارات على جهاز Surface Book حيث يبدو أن المشكلة قد ولت.

إذا كان بإمكان الأشخاص تجربته والإبلاغ عنه: قم بتنزيل VS Code Insiders 64 بت

bpasero يبدو أنه يعمل.

bpasero تم إصلاحه هنا أيضًا لـ XPS 13

bpasero تعمل بشكل رائع هنا. باستخدام Asus ROG Strix. شكر!

تضمين التغريدة شكر!

bpasero هل هذا يعني أنه يمكننا تطبيق الإصلاح في

warpdesign يمكننا الحصول عليها مسبقًا في

شكرا جزيلا bpasero 🙂

مرحبًا ، أنا أستخدم الكمبيوتر المحمول ASUS R500VD ، مع Windows 8.1 x64 Pro.

عندما أبدأ VSCode من git-bash باستخدام code . ، لا يمكنني استخدام النقر بإصبعين أو التمرير بإصبعين في لوحة اللمس. لكنه يعمل ، إذا قمت بتشغيل VSCode من قائمة البداية مباشرة.

تم إغلاق 23062 كنسخة مكررة ولكنها تبدو مميزة تمامًا ، ولا تزال دون حل بأي شيء هنا.

ما لم يكن هذا في إصدار مستقر حتى الآن ، لا يزال التمرير فعالاً بالنسبة لي.
جهاز Surface Book i5 8GB.

bpasero هل يمكنك تأكيد ما إذا كان الإصلاح في

Version 1.20.0-insider
Commit 8697a5e4ec152832a2612929c87d56302dbb2e79
Date 2018-01-03T05:14:21.686Z
Shell 1.7.9
Renderer 58.0.3029.110
Node 7.9.0
Architecture x64

ينطبق الحل المذكور في # 40319 هنا. تغيير حجم النافذة يجعلها سريعة مرة أخرى.

الإصلاح ليس مستقرًا وليس في المطلعين.

شكرا bpasero. من فضلك أعطنا صيحة عندما يكون الأمر كذلك ، لقد قمت بتثبيت اختبار البناء أعلاه ولكن تم طمسه عندما ظهر تحديث (اعتقدت أنه يحتوي على الإصلاح).

مرحبا
يعاني أيضًا من هذه المشكلة في VSC 1.19.1 على علامة تجارية جديدة من Dell XPS 15 9560. متقطع مزعج أيضًا.

يعمل تغيير حجم الجزء على ما يرام ، ولكنه مزعج جدًا للكلمات. لقد قمت بتنزيل الإصدار 1.20 ولكن لم أتمكن من فتح أي ملفات (.ps1 ، .py ، .rb ، .go all يتعطل).

نأمل حقًا أن يصل هذا الإصلاح إلى مستقر و GA قريبًا! كان السبب الرئيسي في شرائي لهذا الجهاز هو الحصول على تجربة VSC أكثر ثراءً.

شكرا جميعا على جهودكم.

مع أحدث إصدار قياسي لنظام التشغيل Windows 10 و Dell XPS 13 ، لا يزال يتعين علي استخدام وسيطة "--disable-gpu" للحصول على تمرير سلس.

لا أصدق أنه لم يتم حلها بعد ... معاناة هذا من كتابي Surface 2

لا يزال يتعين عليك استخدام الحل لهذا

bpasero ما هي حالة هذا الخطأ؟

أضافت bpasero هذا إلى معلم ديسمبر 2017 / يناير 2018 في 15 ديسمبر 2017

هل هذا يعني أنه مخطط للإصدار التالي (المستقر)؟

اعتقدت أنه تم إصلاحه ، لكنه كان خاطئًا. لقد اختبرت على بناء معاينة الرمز المرئي. إنه يعمل بشكل جيد عندما تفتح المحرر ويكون في وضع الإطارات (أي أصغر من سطح المكتب) ، ولكن التمرير يصبح لزجًا عند الانتقال إلى وضع ملء الشاشة. يبدو أن المشكلة تتعلق حقًا بملء الشاشة. كما أن إعداد المحرر editor.smoothScrolling لا يعمل (أعتقد أنه يزيد الأمر سوءًا عند التمكين).

أواجه نفس المشكلة على جهاز Surface Book 2.

تذكير ، بالنسبة لأولئك الذين لم يروه ، المشكلة هي المنبع في الكروم. مما يمكنني قوله ، سيكون الإصلاح في الإلكترون 2.0 ، والذي لم يتم تحديد تاريخ إصداره بعد. فريق vscode لديه "تحديث للإلكترون 2.0" في تكرار الشهر الحالي ، ولكن بالطبع لا يمكنه أن يستمر حتى إصدار 2.0 بالفعل.

حتى هذه النقطة ، لا يوجد أي شيء يمكن لفريق vscode فعله بشأن المشكلة ، ولكن كن مطمئنًا أن الإصلاح سيجعله في vscode بمجرد توفره.

EthanRutherford مما قاله @ bpasero ، يستخدم VScode الإلكترون الخاص به مع بعض التغييرات المخصصة ، لذلك ربما يمكن دمج هذا في VSCode دون الحاجة إلى الانتظار حتى يتم إصدار Electron 2.0؟

@ nico-onmap لست متأكدًا بنسبة 100٪ ، لكنني أعتقد أنه كان يتحدث عن المطلعين بشكل خاص. من المحتمل أن يبني المستقر بإلكترون غير معدل.

لدينا طريقة لإصلاحات backport لإصدار Electron الخاص بنا ولكن لم يكن لدي الوقت للنظر في هذا بعد. أيضًا ، الإصلاح في Chrome مخصص لـ Chrome Canary (Chrome 66؟) ونستخدم Chrome 58 ...

وجود هذه المشكلة على جهاز Dell XPS 15. هل هناك وقت متوقع للوصول إلى الإصلاح؟ أم أن الناس ينتقلون إلى Atom بالفعل؟

تحدث مشكلة التمرير هذه على جهاز Lenovo Yoga 920 ... يدفعني إلى الجنون. التبديل إلى IDE مختلف
هل هناك حل بديل لتصغير الشاشة وتكبيرها كل بضع دقائق ؟؟

navotgil @ أنا أخفض ، إذا كنت تعتبر ذلك بديلاً. ربما تظل إمكانية التمرير أطول في الشكل المصغر ، حيث لا يتعين علي القيام بذلك لمدة 20-30 دقيقة في بعض الأحيان ، على ما أعتقد.

أقوم بتمديد النموذج المصغر ليناسب الشاشة ، لذلك أستخدمه كما لو تم تكبيره تقريبًا. أقوم بتمديده من الزوايا لمنع العمود المفاجئ. أنا أستخدمه مصغرًا ، لأن لدي هذه الخرافة بأن الشكل المكبر أكثر عرضة لإثارة المشكلة.

افتح مع code --disable-gpu في المحطة. يعمل لدي.

فتح مع رمز - تعطيل - gpu في المحطة يعمل بالنسبة لي.

frenic إنه يعمل حقًا! شكرا لك!

نعم نفسه هنا؛ يعمل لي أيضا! واو ، بسيط جدا. لماذا لم أنا هيك
فكر في ذلك ؛-)

في 20 فبراير 2018 الساعة 16:04 ، كتب 张义飞[email protected] :

فتح مع رمز - تعطيل - gpu في المحطة يعمل بالنسبة لي.

frenic https://github.com/frenic إنه يعمل حقًا! شكرا لك!

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/Microsoft/vscode/issues/13612#issuecomment-367025826 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AI1HDgJ399foRiWQN2ZViILXKVDSLsx1ks5tWu0BgaJpZM4KU8A9
.

فتح مع رمز - تعطيل - gpu في المحطة يعمل بالنسبة لي.

frenic رائع ، شكرا.
لا أحد يعرف الآثار المترتبة على ذلك على الأداء؟

يتم نقل التصحيح الخلفي بفضل chaopeng: https://github.com/electron/libchromiumcontent/pull/453

لا تفقد الأمل

هذه المشكلة موجودة منذ ظهور vs code ، وجعلت vs code غير قابل للاستخدام في Windows 10. يمكنني أن أفهم أن شركة صغيرة تستخدم الإلكترون لاستهداف منصات متعددة في وقت واحد ، ولكن بالنسبة لشركة مثل MSFT ، أعتقد حقًا أن ينبغي النظر في النهج. Sublime عبارة عن منصة متعددة ، والأداء / السيولة على قدم المساواة مع المفكرة. لا ينبغي على Microsoft حقًا أن تجعل IDE الأسرع نموًا يعتمد على منتج Google وقدرة الشركات الأخرى على إصلاح الأخطاء في نظام أساسي معين.

محرر Xi في Fuchsia repo هو مستقبل المحرر. لا يزال قيد العمل ، لكن الوصف واعد. إنها منصة متعددة ، ولكنها تستخدم كل مكتبة أصلية للمنصات لتحقيق الشكل والمظهر الأصلي وتقديم أفضل أداء. إنه ذو مظهر ضئيل ، وسوف يدعم المكونات الإضافية. لقد قفزت بالفعل من السفينة إلى السمو بسبب السيولة والنعومة. سيكون شي خياري التالي بمجرد أن يخرج. كود VS رائع ، لكن كونه قائمًا على الإلكترون يجعلني لا أريد أن ألمسه مرة أخرى.

لقد اشتريت جهاز Surface Pro 4 هذا في أوائل عام 2016. لقد جربت vscode بمجرد أن سمعت عنه ، لكنني كنت أتجنبه بسبب مشكلات التمرير منذ ذلك الحين.

لقد بدأت مؤخرًا في استخدامه مرة أخرى بعد كل تلك السنوات عندما اكتشفت أن المشكلة يتم تعقبها أخيرًا ولديها أيضًا بعض الحلول الآن. لا يمكنني إلا أن أتمنى أن تكون أدوات مطور Microsoft (VS Community and Code) سهلة الإدخال (تعمل باللمس أو لوحة التتبع أو القلم) مثل Edge أو Groove. ثم مرة أخرى ، لا يمكن فعل الكثير من خلال تطبيق Electron / Chromium. مشكلتي هي جوهر vscode.

أعتقد أنه تم إصلاحه في بناء المطلعين

تم دمج razielidog Patch بالأمس فقط على Electron 1.7.x: أشك في أنه موجود بالفعل في بناء المطلعين.

آمل أن يصلحوها

هذا مروع. التمرير على لوحة اللمس لديه تأخر فظيع في vscode. Surface pro 5 + محرف الكتابة.

نعم razielidog أعتقد أنك قمت للتو بتحريك النافذة (وهو حل بديل). سوف يتباطأ مرة أخرى حتى يتم تضمين Electron 1.7 كما يقول @ nico-onmap.

كنت أتابع هذا لمدة 8 أشهر. أنا أحب منتجات Microsoft ولكن من الواضح أن لوحة اللمس الدقيقة الخاصة بـ Microsost لا تعمل بشكل جيد مع منتج Microsoft الخاص. أعلم أنها مشكلة في Chromium ولكن لا تزال. إن Electron مثير للشفقة حقًا وقد جربت عددًا لا يحصى من منتجات Electron وليس منتجًا واحدًا مثاليًا.

كيف هذا حتى مشكلة؟

هل يستطيع الأشخاص الذين يرون هذه المشكلة منح هؤلاء المطلعين تجربة: تنزيل

يتضمن منفذًا خلفيًا لإصلاح Chrome التالي لمعالجة المشكلة: https://crrev.com/c/867070

bpasero لا ، لا يحل المشكلة ولكن ملاحظة واحدة مثيرة للاهتمام. لا يوجد تأخير في بدء التشغيل ولكن بعد التقليل ، يتصرف مثل بناء المطلعين.

gurpreetshanky هل يمكنك فتح devtools (من قائمة المساعدة) وفي وحدة التحكم اكتب " process.versions " وأرسل إليّ ناتج القيام بذلك؟

bpasero هذا هو الإخراج
الكائن {http_parser: "2.7.0" ، العقدة: "7.9.0" ، v8: "5.8.283.38" ، uv: "1.11.0" ، zlib: "1.2.11"…}

gurpreetshanky قصدت أن أقول ، اكتب هذا: process.versions["atom-shell"]

bpasero "1.7.12"

gurpreetshanky سيء للغاية ، دعنا نرى ما إذا كان الآخرون يبلغون عن شيء آخر. سوف أتحقق مرة أخرى من أن المنفذ الخلفي قد تم تضمينه في الإنشاء ... (الإصدار 1.7.12 صحيح على الأقل).

bpasero نعم ولكن بالتأكيد تحسن عند بدء التشغيل. أيضًا ، متى سيتم تحديث الكود مقابل الإلكترون 2.0. في Atom touchpad يعمل بشكل جيد. لماذا يؤثر هذا فقط على الكود؟

bpasero لقد جربت البناء على Surface Book الخاص بي ولدي نفس السلوك من @ gurpreetshanky : يعمل

هل اختبر شخص ما إصدارات Chrome مع الإصلاح: ربما لم يتم إصلاحها بشكل صحيح؟ لقد كانت عربات التي تجرها الدواب لسنوات ، لن أكون مفاجأة: /

تصحيح: لقد أساءت فهم المصطلح " تصغير" على أنه الخروج من الحد الأقصى. يؤدي تصغير شريط المهام إلى إعادة المشكلة هنا أيضًا.

bpasero لقد التعليق ، ولم تعد لدي المشكلة بعد الآن. كان التقليل / الاستعادة هو الحل البديل الذي كنت أفعله لإصلاح المشكلة مؤقتًا في بنية الإصدار ، لذلك لا أفهم كيف لن يتم حل المشكلة هذه المرة ولكن إعادة المشكلة ، حقًا ...

يجب أن يكون تحقق واحد من استمرار المشكلة كافيًا للقول إنه لم يتم إصلاحه حقًا ، ومع ذلك ، لدينا اثنان. ربما لا أثير ذلك بطريقة ما.

bpasero يجب أن أتفق مع ThoAppelsin ، يبدو أنه تم إصلاحه في هذا البناء.
حاولت التكاثر ولم تستطع

bpasero نعم ولكن بالتأكيد تحسن عند بدء التشغيل. أيضًا ، متى سيتم تحديث الكود مقابل الإلكترون 2.0. في Atom touchpad يعمل بشكل جيد. لماذا يؤثر هذا فقط على الكود؟

نحن نتطلع إلى التحديث إلى Electron 2.0.0 ، ولكن من المحتمل أن يستغرق الأمر مزيدًا من الوقت. إذا كنت تريد التحقق مما إذا كانت المشكلة تتكرر في الإصدار 2.0 ، فيمكنك المحاولة باستخدام بنية الاختبار هذه ( الرابط ) ، ولكنها لا تتضمن الإصلاح حتى الآن.

لا يمكنني شرح سبب عدم تكاثرها في Atom ...

هل اختبر شخص ما إصدارات Chrome مع الإصلاح: ربما لم يتم إصلاحها بشكل صحيح؟ لقد كانت عربات التي تجرها الدواب لسنوات ، لن أكون مفاجأة: /

يمكنني القيام بذلك الأسبوع المقبل ، لدينا حالة قابلة للتكرار مع Chrome أيضًا. إذا قمت بتشغيل chrome من سطر الأوامر وتوجيهه إلى بعض مواقع الويب التي يتم تمريرها ، فيمكننا جعل التأخر يظهر مباشرة. يبدو أن المفتاح هو عدم كتابة عنوان URL في علامة تبويب ، ولكن دع Chrome يبدأ بعنوان URL مباشرةً.

bpasero لقد

ThoAppelsin هل تقول أن هذه المشكلة قد تم إصلاحها لك حتى عند تصغير / استعادة النافذة؟

bpasero يجب أن أتفق مع ThoAppelsin ، يبدو أنه تم إصلاحه في هذا البناء.
حاولت التكاثر ولم تستطع

razielidog ويظل ثابتًا حتى عند تصغير النافذة واستعادتها؟

مثل gurpreetshanky. لا يوجد تأخير عند بدء التشغيل ولكن min / max يعيدها.

تضمين التغريدة لقد أسأت فهم المصطلحات ، وربما أربكت أيضًا razielidog . هناك بالفعل هذه المصطلحات الثلاثة ، تعظيم / استعادة / تصغير ، وقد أسأت فهم التقليل على أنه

يؤدي تصغير النافذة إلى شريط المهام واستعادتها مرة أخرى إلى إعادة المشكلة أيضًا.

bpasero هل تم تضمين إصلاح الأخطاء في إصدارات Chrome العامة؟ يعرض Chrome Version 65.0.3325.146 (Build officiel) (64 bits) المشكلة عند بدء تشغيله من سطر الأوامر مع موقع ويب كمعامل (ويختفي عند فتح علامة تبويب جديدة ، ولكن أعتقد أن هذا كان معروفًا).

تحرير تم إصلاح المشكلة في إصدارات Canary ( Version 67.0.3367.0 (Build officiel) canary (64 bits) ) ، وتم إصلاحها بالتأكيد: التقليل / الاستعادة لا يعيد المشكلة. لذلك لم يجعلها مستقرة حتى الآن.

ThoAppelsin على الأقل لدينا جميعًا نفس السلوك.

warpdesign أعتقد أنه موجود فقط في Chrome 66 ، هل يمكنك تجربة الإصدار التجريبي الخاص بهم لمعرفة السلوك؟ شكرا لإعطائك هذه المحاولة 👍

جرب bpasero كلاً من Chrome Beta و Canary ، وإليك النتائج:

• Beta (65.0.3325.125): خطأ موجود ، نفس سلوك VSCode مستقر (تأخر التمرير ، التقليل / الاستعادة يصلحه مؤقتًا)
  
  
  
  • Canary (67.0.3367.0): تم إصلاح الخطأ بالتأكيد: التصغير / الاستعادة لا يعيده
  
  

لذلك يبدو أن التصحيح الذي قمت بتطبيقه قد عكس المشكلة ، أي: تم إصلاحه افتراضيًا ، واستعادته / تصغيره يعيده.

أستطيع أن أؤكد أن Atom ( 1.24.1 ) لا تظهر عليه مشكلة استخدام Electron 1.6.16 .

ماذا عن التعاون مع Atom لأنهم لا يواجهون المشكلة؟ هل كان لديهم؟ إذا كان الأمر كذلك ، فكيف قاموا بإصلاحه؟ إذا لم يكن كذلك ، فلماذا؟

warpdesign ، سيتعين عليك اختبار Atom Beta ( 1.25.x مع Electron 1.7.11 ) على الرغم من مطابقة إصدار Chrome نفسه الذي نستخدمه. من المحتمل أن Electron 1.6.x ليس لديه هذه المشكلة بعد كل شيء لأنه يستخدم إصدار Chrome أقدم.

أحاول المتابعة مع Electron إذا لم يكن backport الخاص بهم مكتملًا (المناقشة في https://github.com/electron/libchromiumcontent/pull/472).

شكرا لك على العمل على هذا!

bpasero لقد جربت للتو مع Atom Beta ( 1.25.0-beta3 ، Electron 1.7.11 ) والتمرير يعمل بشكل مثالي: لا تأخيرات ، لا مشكلة عند التصغير / الاستعادة.

warpdesign hmm إذن الخطأ موجود في قاعدة رمز vscode؟

gurpreetshanky ، لا يمكنك حقًا قول ذلك لأن هذا الخطأ

bpasero ربما يعتمد إصلاح الخطأ على بعض الإصلاحات / التغييرات الأخرى التي لم يتم تطبيقها؟ ماذا عن التواصل مع الشخص الذي أرسل تصحيحات Chrome لهذا الخطأ؟

لكي نكون منصفين warpdesign ، تم تطبيق هذا التصحيح فوق Chrome 66

هل يستطيع الأشخاص الذين يرون هذا في الوضع الثابت تأكيد عودة المشكلة بمجرد تصغيرها واستعادتها؟ أحاول أن أفهم ما إذا كانت لدينا دائمًا هذه المشكلة مع التقليل / الاستعادة إلى إعادة المشكلة.

يبدو أن الاختبار الذي أجريته باستخدام Surfacebook يشير إلى وجود هذه المشكلة من قبل. مما يعني أن المنفذ الخلفي يعمل على إصلاحه عند بدء التشغيل ولكنه ليس أسوأ من ذي قبل فيما يتعلق بالمشكلة التي تعود عند التصغير / الاستعادة.

نعم إنه موجود في البنية الثابتة الحالية (التصغير + الاستعادة يجعل التمرير بطيئًا):

الإصدار 1.21.0
قم بتنفيذ 9a199d77c82fcb82f39c68bb33c614af01c111ba
التاريخ 2018-03-07T11: 04: 09.969Z
شل 1.7.9
العارض 58.0.3029.110
العقدة 7.9.0
العمارة x64

(على الأقل على Dell XPS 15 9560)

في رأيي ، حتى هذا الإصلاح الجزئي سيكون جيدًا ليتم دمجه في المطلعين حتى يتم فرز الحد الأدنى من الأخطاء. من وجهة نظر قابلية الاستخدام على الأقل.

هل تعودynotzort أيضًا بإيماءات أخرى على النافذة؟ مثل التبديل بين نوافذ التطبيق؟ أنا أسأل لأن التصغير / الاستعادة يبدو وكأنه مهمة يتم تنفيذها بشكل أقل تكرارًا مقارنة بتبديل Windows.

bpasero لا يبدو الأمر كذلك ، على الأقل alt + tab و windows + tab لا يجعل المشكلة تظهر بالنسبة لي.
ومع ذلك ، فإن استخدام windows + d (تصغير / استعادة جميع النوافذ) يجعلها تظهر ، وهو أمر مزعج للغاية ...

لقد حصلت على هذه المشكلة في أحدث إصدار 1.21.0 حتى قبل التصغير / الاستعادة. إذا فتحت ملفًا في VS Code ، فسيكون التمرير متقطعًا باستخدام لوحة اللمس. لقد وضع:
"window.menuBarVisibility": "toggle"
لذا فإن الحل السريع الخاص بي هو الضغط على ALT ، مما يجعل شريط القائمة يظهر ويختفي المشكلة. هذا حتى تصغير / استعادة الدورة عندما تعود.

marchom شكرًا على النصيحة ، أفضل ذلك لتغيير الحجم كحل بديل.

يبدو أن سلوك الخطأ يتبع هذا النمط على 1.21.0 (Windows):

• يبدو
  
  
  
  • بطريق الانطلاق
  
  
  • بعد التصغير / الاستعادة عند التكبير (إما باستخدام الأزرار أو Win + D )
  
  
• يختفي
  
  
  
  • عند بدء تشغيل vscode بعلم --disable-gpu
  
  
  • عند تغيير الحجم
  
  
  • أثناء الاحتفاظ بـ CTRL أو ALT
  
  
  • بعد النقر على ALT (فقط إذا كان لديك شريط القائمة مخفيًا)
  
  
  • بعد تبديل وضع ملء الشاشة ( F11 )
  
  
  • إذا كانت أدوات المطور مفتوحة Help -> Toggle Developer Tools
  
  
• بدون تأثير
  
  
  
  • بعد التصغير / الاستعادة عند تركيز vscode ، ولكن لا يتم تكبيره
  
  
  • ALT + TAB
  
  
  • Win + TAB
  
  

يؤدي النقر المزدوج على F11 (تبديل ملء الشاشة) أيضًا إلى إزالة المشكلة بالنسبة لي. تشغيل code --disable-gpu يعمل أيضًا ...

الغريب هو أنه إذا لم يتم تكبير VSCode ، فإن التصغير والاستعادة لا يؤديان إلى حدوث المشكلة بالنسبة لي ...

واجهت مشكلة مع Discord التي تستخدم أيضًا Electron .
(لا يمكنني الارتباط أكثر لأنني أعمل 80٪ من وقتي على Linux)

الغريب هو أنه إذا لم يتم تكبير VSCode ، فإن التصغير والاستعادة لا يؤديان إلى حدوث المشكلة بالنسبة لي ...

ynotzort يمكن تأكيد هذا السلوك. تم تحديث قائمتي

أستخدم التكبير / الاستعادة أو الاستعادة / التكبير كحل بديل ، وهو يعمل (بقدر ما أذكر) طوال الوقت. ربما يمكن إصدار هذا الحل برمجيًا عندما يتم إحضار vscode من شريط المهام بعد تصغيره؟

لست على دراية كافية بهذه الموضوعات ، ولكن ربما يمكن القيام بذلك بشكل ذري بما فيه الكفاية ، دون إعادة رسم النافذة على الإطلاق. حتى يأتي الإصلاح وينتشر على طول الطريق من الكروم / الإلكترون إلى vscode ، يمكن لـ vscode تصحيحه مثل هذا كإجراء مؤقت.

@ pd93 لقد لاحظت أيضًا أن Help -> Toggle Developer Tools يخفف أيضًا من المشكلة. لبعض الأسباب ، إذا كانت أدوات المطورين مرئية ، لا يحدث أي تأخير

@ Karasq شكرا ، يمكنني تأكيد ذلك. لا يمكنني إلا أن أفترض أن فتح أدوات dev يؤدي إلى تغيير الحجم عند تركيز vscode؟ رغم أنه ليس لدي ما يدعم هذه النظرية.
لقد أضفته إلى قائمتي ^ ^ ^

karasq شكرًا لك ، مساعدة -> عملت
ورمز - تعطيل-gpu عملت كذلك

bpasero لقد رأيت للتو أنه في ملاحظات إصدار الإلكترون 1.7.13 "دعم ثابت للتمرير الدقيق للوحة التتبع / الماوس." يتم تمييز. ربما يمكن استخدام هذا الإصدار بدلاً من 1.7.12؟

razielidog نحن نستخدم 1.7.12 ولكن مع هذا التصحيح الدقيق خلفي ...

باستخدام الإصدار الحالي من الداخل ( 3a70cdfd8f84136e858b3d39e5a709e637fc35e7 ) ، يمكنك تعيين "window.smoothScrollingWorkaround": true لاستعادة التمرير السلس عند استعادة النافذة. يتضمن هذا الإصدار أيضًا إصدار Electron الذي سيصلح هذه المشكلة عند بدء التشغيل الأولي.

دعونا نعرف كيف ستسير الامور. السبب وراء عدم تمكين هذا الإعداد الجديد افتراضيًا هو أ) إنه مجرد حل بديل وليس الإصلاح الحقيقي حتى الآن ب) ينتج عنه بعض الخفقان في النافذة عند استعادتها.

bpesaro أخبار رائعة! لا يمكنني الوصول إلى كتابي السطحي الآن ، وسأحاول ذلك في غضون أيام قليلة. هل يعني الوميض أن التصحيح يُعاد تطبيقه في كل مرة يتم فيها استعادة النافذة؟

warpdesign ، يأتي الوميض حرفيًا من حقيقة أنه من خلال تمكين هذا الخيار ، أقوم

يعمل bpasero الحل البديل كما هو متوقع على جهاز Surface Book ، ولا مزيد من التأخير بعد

يبدو أن المشكلة لها علاقة بإصدار Windows (خاصة لوحة اللمس الدقيقة). في حالة تشغيل كود VS في الوضع المتوافق لنظام التشغيل windows 7 ، يختفي تأخر التمرير ولن يظهر مرة أخرى.

@ TXH1997 شكرًا على فكرة وضع التوافق. يبدو أن وضع Windows 7 comp.mode يعمل على إصلاح مشكلات تأخر التمرير (على Surface Pro 4) بشكل دائم.

@ TXH1997 لأن تشغيله في وضع التوافق يعني التشغيل بدون GPU. لذلك لن تعمل وظائف مثل المحطة المتكاملة.

نعم ، إنه مجرد حل مؤقت. لا يزال الخلل ليتم إصلاحه ...

على أمل إصلاح هذا منذ وقت طويل ، لا تفهم سبب عدم قدرة MS على تقديم الإصلاح المناسب.

مشاهدة هذا حاليًا على Surface Book في الإصدار 1.21.1

سأقفل هذه المشكلة حتى يتمكن الأشخاص من رؤية الحل الحالي الذي نشحنه بـ 1.22:

أقوم بإلغاء قفل هذه المشكلة للحصول على بعض التعليقات حول حقيقة أن Windows 10 كان يعمل على إصلاح ويبدو أنه مدرج في Windows 10 Insider Preview Build 17751 وسيتم تضمينه في تحديث أكتوبر (RS5).

إذا تمكن أي شخص من التحقق من أن المشكلة قد تم إصلاحها بالفعل من خلال بناء المطلعين على Windows 10 ، فسيكون ذلك رائعًا. حتى الآن سمعت من Drae في https://github.com/Microsoft/vscode/issues/53793#issuecomment -417922382 أنه تم حل المشكلة.

للتحقق:

• التحديث إلى Windows 10 Insider Preview Build 17751
• إزالة الإعداد window.smoothScrollingWorkaround (إذا تم تكوينه)

bpasero لا توجد مشاكل بعد الآن مع 17751 على Surface Book.

bpasero نعم تم حل المشكلة باستخدام 17751.1 على Dell XPS 15 مع لوحة لمس دقيقة.

من باب الفضول: هل واجه أي شخص هذه المشكلة على نظام التشغيل Windows 7 أو Windows 8؟ أسأل لأنه من المحتمل أن يتم الإصلاح على نظام التشغيل Windows 10 فقط.

bpasero لا أعتقد أن ذلك سيحدث في الإصدارات السابقة من Windows لأنها لا تدعم لوحات اللمس الدقيقة ، إذا كنت أتذكر جيدًا.

هل سيكون هذا التغيير موجودًا في تحديث أكتوبر 2018 لنظام التشغيل Windows 10 عند إصداره؟

تعمل طاقة جهاز كمبيوتر سطح المكتب من HP لمدة دقيقة واحدة ولكن الشاشات ليست مفتوحة والماوس أو لوحة المفاتيح لا تعمل عند تحديث نظام التشغيل windows 10 الخاص بي قبل عامين

@ bdr99 نعم ، سيكون متاحًا كجزء من تحديث أكتوبر.

إغلاق هذا مع طرح تحديث Windows 10 October للناس. تم إصلاح هذا الخطأ كجزء من تحديث Windows 10 RS5.

رائع ، الآن علينا انتظار RS5 - ونأمل غدًا.

قررنا الاحتفاظ بـ "window.smoothScrollingWorkaround": true لهذا الإصدار ونخطط لإزالته في المستقبل عندما يقوم المزيد من المستخدمين بالتحديث إلى أحدث إصدار من Windows.
هل يمكن لشخص ليس لديه أحدث إصدار من Windows 10 أن يأخذ هذا الإصدار الداخلي ويتحقق من أن window.smoothScrollingWorkaround يعمل كما كان من قبل وأن التمرير سلس؟ وسأكون ممتنا حقا.

https://az764295.vo.msecnd.net/insider/1d0e4299c6ccfe9210252c811b4247cfdc8a6a44/VSCodeSetup-ia32-1.29.0-insider.exe
https://az764295.vo.msecnd.net/insider/340133accd0b66202bde342f995f00b02f63c0d4/VSCodeSetup-x64-1.30.0-insider.exe

isidorn ليس لدي تحديث أكتوبر مثبتًا بعد ، لذلك قمت بتثبيت الإصدار الداخلي للاختبار.

ولكن الشيء هو أن تحديث KB4462933 قد أصلح المشكلة بالنسبة لي. الآن لا يوجد فرق بين الإنشاءات المستقرة / الداخلية ، ومع / بدون window.smoothScrollingWorkaround بعد التحديث.

إليك المزيد من الشهادات: https://github.com/Microsoft/vscode/issues/62327#issuecomment -436597428 ، https://github.com/Microsoft/vscode/issues/61824#issuecomment -433785824.

HazemAM شكرا للقفز عليه!
هذا هو السبب في أنني بحاجة إلى شخص ليس لديه آخر تحديث لنظام Windows لتجربته حتى نتمكن من التحقق من أن الإعداد لا يزال يعمل.

isidorn أوه ، إذن هل قصدت آخر تحديث تزايدي ، وليس تحديث أكتوبر؟

نعم أعتقد أنني بحاجة إلى شخص ليس لديه https://support.microsoft.com/en-us/help/4462933/windows-10-update-kb4462933

ضع في اعتبارك أنه لا يكفي فقط تكوين window.smoothScrollingWorkaround: true ، سيكون عليك أيضًا تعطيل العنوان المخصص عبر window.titleBarStyle: native .

ليس لدي تحديثات Windows متاحة للتثبيت (أنا محدث) ، أحدث vscode وأنا أقوم بتشغيل windows bootcamp.

عند استخدام لوحة التتبع ، لا توجد أي طريقة على الإطلاق (مع أي مجموعة من الاقتراحات في هذا الموضوع) للحصول على عمل تمرير سلس. يتجاهل Vscode إعدادات عجلة الماوس الخاصة بلوحة التحكم. الطريقة الوحيدة التي يمكنني من خلالها الحصول على vscode للتصرف هي عن طريق تعيين "editor.mouseWheelScrollSensitivity": 0.2 ومع ذلك أقوم بالتبديل بين استخدام لوحة التتبع والماوس ، لذلك لا بد لي من تغيير هذا الإعداد في كل مرة أقوم فيها بتبديل الجهاز!

في الوقت الحالي ، لا يُحتمل استخدام vscode بسبب هذا!