Скорее всего имелось ввиду что не пытается вернуться в тот SynchronizationContext к-рый был на момент вызова асинхронного метода. Само собой по окончанию выполнения вызываемого метода будет вызван «continuation» делегат
Наиболее правильным вариантом тут будет использовать generic типы с необходимыми вам constraint-ами. В этом случае runtime проводит дополнительные оптимизaции используя информацию о типе (например переданные тип может быть struct … или же sealed … или идин из немногих типов от которых наследование возможно, но наследников фактически нет (на счет этой оптимизации не уверен)). Такой код будет значительно быстрее, но к сожалению «duck typing» к-рый используется в foreach конструкциях не будет задействован (а ведь именно он даёт такой прирост производительности в сравнении с for циклами)
В вашем Lenovo скорее всего установлен WiFi+BT комбинированный модуль …
Просто купите за 20$ посвежее и радуйтесь (например Intel8265). Так уж вышло, что производитель модуля решил более не поддерживать эту «железку»… в пользу более нового оборудования.
У меня установлен Core i7-8550U (TDP 15 Вт), это первый мобильный четырехъядерник от Intel.
Может огорчу вас … но это далеко не первый мобильный четырехядерник. (4 + 4HT было еще в стареньком i7-720QM которому уже 100 лет в обед, а до этого мобильные 4ядерные процы были просто 2x2 Core 2 Duo, что в принципе можно считать 4хядерным с натяжкой… но тем не менее...)
Очевидно это Windows! Новое API Windows (universal windows apps) работает именно так. Для получения доступа к пользовательским файлам необходимо вызывать File/Folder Picker и только после этого будет доступ к файлу/ветви файловой системы. До того момента приложение может работать, как вы выразились, в песочнице, не имея представления не только о пользовательских данных, но и приложениях, установленных на устройстве.
Интересно мнение сообщества по такому вопросу: Возможна ли ситуация когда 2 одинаковые ЧД расходятся друг с другом на расстоянии 99% диаметра горизонта событий? (иными словами в определенный момент горизонты событий сливаются, но само «ядро ЧД» проходит на существенном расстоянии от горизонта событий встречной ЧД и затем горизонты событий снова разделяются). Если такое возможно — как это повлияет на общую площадь горизонтов событий системы 2х ЧД? И не приведет ли данная ситуация к «побегу» материи?
Не потеряют. Попробуйте на черном фоне провести белую вертикальную линию толщиной в 1пх (в этом случае вообще никакого сглаживания не понадобится). Тем не менее цветные разводы слева и справа от линии будут отчетливо видны.
А какой смысл доводить размер пиксела до размеров субпиксела? В итоге же просто получим по видимой картинке аналог антиалисинга на в разы меньшем разрешении, но при большей нагрузке на отрисовку.
Задача не довести размер пикселя до размера субпикселя, а в принципе сделать так, чтобы субпиксели были неразличимы. На текущий момент технологии изготовления дисплеев подразумевают что пиксель состоит из 3х(иногда 4х) субпикселей к-рые к сожалению всё еще весьма заметны как отдельные элементы экрана. Вертикальная белая линия на современном RGB дисплее будет слегка отдавать красным слева и голубым справа и только в центре будет белой. При большом кол-ве физических субпикселей в одном логическом пикселе таких проблем не будет наблюдаться.
Любое сглаживание границ визуальных примитивов будь то границы 3хмерных объектов, просто прямые или кривые линии — это и есть antialiasing. Сглаживание границ символов в том числе методом cleartype — тоже является частным случаем всевозможных методов antialiasing-а. В этом плане я ничуть не ошибся.
По моему мнению учет физических параметров матрицы просто must-have для получения качественного результата сглаживания (что мы и наблюдаем при использование cleartype сглаживания правильно настроенного под конкретный дисплей). С увеличением разрешающей способности дисплеев данный подход становится все менее актуальным т.к. мы перестаём видеть столь незначительные артефакты. А при дальнейшем увеличении разрешающей способности вообще отпадёт надобность в сглаживании.
С уменьшением физического размера пикселя можно будет отойти от использования clear-type антиалиасинга (тот-самый, к-рый не поддерживается устройствами Apple и производит антиалисинг на «субпиксельном» уровне). Т.е. теперь (логический) пиксель будет состоять не из 3х(RGB) или 4х(RGBW), а из гораздо большего кол-ва субпикселей. Это принципиально упростит используемые алгоритмы антиалиасинга и улучшит итоговую картинку не создавая дополнительную нагрузку на ЦП и/или ГП
Знание программирования в классическом понимании этого слова отнюдь не мешает работать с квантовым компьютером. Как уже было отмечено выше — это всего-лишь квантовый сопроцессор к-рый может выполнять довольно ограниченный набор задач (в сравнении с всеми задачами к-рые приходится решать программистам). Ко всему прочему из этого ограниченного набора стоит убрать те задачи, к-рые решаются (или будут решаться) классическими алгоритмами быстрее или эффективнее.
Просто купите за 20$ посвежее и радуйтесь (например Intel8265). Так уж вышло, что производитель модуля решил более не поддерживать эту «железку»… в пользу более нового оборудования.
Может огорчу вас … но это далеко не первый мобильный четырехядерник. (4 + 4HT было еще в стареньком i7-720QM которому уже 100 лет в обед, а до этого мобильные 4ядерные процы были просто 2x2 Core 2 Duo, что в принципе можно считать 4хядерным с натяжкой… но тем не менее...)
А вот «ватт*час» — это эквивалент «джоуля».
Задача не довести размер пикселя до размера субпикселя, а в принципе сделать так, чтобы субпиксели были неразличимы. На текущий момент технологии изготовления дисплеев подразумевают что пиксель состоит из 3х(иногда 4х) субпикселей к-рые к сожалению всё еще весьма заметны как отдельные элементы экрана. Вертикальная белая линия на современном RGB дисплее будет слегка отдавать красным слева и голубым справа и только в центре будет белой. При большом кол-ве физических субпикселей в одном логическом пикселе таких проблем не будет наблюдаться.
По моему мнению учет физических параметров матрицы просто must-have для получения качественного результата сглаживания (что мы и наблюдаем при использование cleartype сглаживания правильно настроенного под конкретный дисплей). С увеличением разрешающей способности дисплеев данный подход становится все менее актуальным т.к. мы перестаём видеть столь незначительные артефакты. А при дальнейшем увеличении разрешающей способности вообще отпадёт надобность в сглаживании.