ShellIconOverlayIdentifiers - почему так мало?
На данный момент все знают, что существует ограничение на количество ShellIconOverlayIdentifiers (из MSDN):
Количество различных обработчиков наложения значков, которые может поддерживать система, ограничено объемом пространства, доступного для наложений значков в списке образов системы. В настоящее время для наложения значков выделено пятнадцать слотов, некоторые из которых зарезервированы системой. По этой причине обработчики наложения значков должны быть реализованы, только если нет удовлетворительных альтернатив.
Я могу понять предел 15 оверлеев в Windows 95. Но в среде, где есть гигабайты оперативной памяти, многочисленные ядра и графические процессоры, есть ли какая-то техническая причина такого низкого числа в современной операционной системе?
И почему это значение не настраивается?
Перед тем, как дать ответ "производительность", подумайте: в Windows предусмотрена конфигурация, позволяющая снизить производительность... зачем специально выбирать этот вопрос?
4 ответа
Если кто-то здесь не работает в команде Windows Shell, я сомневаюсь, что вы получите ответ, который действительно касается технических ограничений и того, как они влияют на выбор дизайна. Но я попытаюсь...
Я предполагаю, что нет никаких технических ограничений, или, по крайней мере, сейчас их нет. Реальная причина, по-видимому, в том, что никто никогда не занимал время, чтобы сесть и обновить код, дизайн и спецификацию, чтобы снять это ограничение. Функции не реализованы по умолчанию, и только потому, что вычислительная среда изменилась за последние несколько лет, не означает, что кто-то сел и переписал Windows, чтобы в полной мере воспользоваться всеми этими изменениями.
Вам также следует учитывать, что это более чем сознательный выбор дизайна, а не наложенное ограничение. Рэймонд Чен (который на самом деле работает в команде оболочки) опубликовал запись в блоге в ответ на возмущение по поводу Windows 7, удаляющее наложение "совместного использования". Он приводит убедительный аргумент, что наложение значков на самом деле не является желательным способом отображения информации (помимо того факта, что система ограничена 15) [выделение добавлено]:
Вообще говоря, оверлеи не являются хорошим способом представления информации, потому что может быть только один оверлей на значок, и существует ограничение в 15 оверлеев на ImageList. Если есть два или более наложений, которые применяются к элементу, то один выиграет, а другие проиграют, и в этот момент значение наложения как способа определения того, какие свойства применяются к элементу, уменьшается, так как единственный способ быть уверенным что свойство отсутствует, это когда вы вообще не видите оверлея. (Если вы видите какое-то другое наложение, вы не можете определить, связано ли это с отсутствием вашего свойства или с тем, что вместо вашего отображается другое наложение.)
Мне кажется разумным, что дополнительный беспорядок, добавленный в оболочку, просто не стоит этого в большинстве реальных случаев. Команда Windows Shell, очевидно, пришла к такому же выводу и сократила оверлей "Совместная рука". Прямое объяснение Раймонда:
Учитывая изменения в том, как люди используют компьютеры, обмен информацией становится все более и более стандартным состоянием. Когда вы настраиваете HomeGroup, почти все будет доступно всем. Чтобы удалить визуальный беспорядок, информация была перемещена на панель "Подробности".
И я знаю, что вы специально просили не упоминать о производительности, но Windows действительно старается не дать вам выстрелить себе в ногу. Пользователи требуют отзывчивости в оболочке, и наложенные значки могут мешать этому. Еще одно доказательство того, что они не являются приоритетом, - это еще одно сообщение в блоге того же Раймонда Чена:
Еще один пример того, как приложения имеют эгоистичное представление о производительности, - компания, разрабатывающая обработчик наложения значков. Оболочка рассматривает вычисления с наложением как элемент с низким приоритетом, поскольку более важно выводить значки на экран, чтобы пользователь мог начать делать то, что он хотел. Украшения могут прийти позже. Эта компания хотела узнать, можно ли каким-то образом улучшить свою производительность и наложить их на экран еще до того, как появится значок, демонстрируя феноменально эгоистичную интерпретацию "производительности".
Отличный ответ на практические вопросы Коди. Что касается 15, а не какого-либо другого числа, ограничение запекается в самом элементе управления ImageList.
Это все очень хорошо и хорошо, как объяснил Коди Грей, но, честно говоря, это довольно невообразимо, и, как сообщается за кадром, звучит немного разочарованно
В 2015 году и с Windows 10, безусловно, могут и должны быть лучшие возможности, поскольку я отметил около тридцати присутствующих наложений и должен был расставить приоритеты среди тех, которые я хотел больше всего увидеть, а это совсем не то, о чем большинство людей беспокоится. Также я вижу агрессивных вендоров, таких как Box, которые чрезмерно конкурируют, пытаясь расставить приоритеты, и это никогда не пойдет на пользу.
Вот такая возможность. Что, если у значков с многократным наложением есть общий индикатор наложения; маленькая прямоугольная матрица из нескольких цветов, например кнопка Google Chrome Apps? Одиночное наложение просто показало бы наложение из длинного списка.
Затем, когда указатель мыши встречает значок, небольшое всплывающее окно собирает все варианты значков для просмотра (при небольшом размере значка или немного больше). Каждый наложенный значок в свою очередь объявляет всплывающей подсказкой, что это такое, когда вы наводите курсор мыши.
Теперь вы можете иметь все необходимые наложения значков для состояния в различных облаках, для указаний хранилища, как для инструментов Черепаха, и так далее.
Я цитирую отрывок из окончательного ответа здесь: Почему существует ограничение в 15 наложений значков оболочки?Рэймонд Чен, пост в 2019 году
Значение 15 взято из соответствующего ограничения для списков изображений. Функция ImageList_SetOverlayImage поддерживает до 15 наложений списков изображений для каждого списка изображений. (Эй, раньше было хуже. Раньше было всего 3!)
Хорошо, но почему только 15? Почему не больше?
Наложенное изображение - это одна из частей информации, используемая при рисовании изображения из списка изображений. Параметры закодированы в параметре fStyle, и когда биты были разделены для различных целей, было доступно четыре бита, которые можно было использовать для определения наложенного изображения. (Вы получаете 15 наложенных изображений вместо 16, потому что вы теряете одно из значений, чтобы указать «без наложения».)
Хорошо, но значения в параметре fStyle используют только нижние 16 бит. А как насчет старших 16 бит? Там много места.
16-разрядный предел был перенесен из 16-разрядной версии общих элементов управления (которые все еще нуждались в поддержке в Windows 95). Конечно, в настоящее время никого не волнует 16-битная версия общих элементов управления, так почему бы не начать использовать старшие биты?
Есть неудовлетворительное объяснение: внутренний код, который управляет fStyle, все еще использует WORD в некоторых местах, поэтому весь код, который управляет fStyle, придется пересмотреть. Это происходит в нескольких модулях в Windows, поэтому синхронизированное изменение должно быть выполнено в нескольких компонентах. Это критическое изменение на двоичном уровне, потому что интерфейсы больше не совместимы. Критические изменения процедурно сложно координировать: затронутый код может быть не виден команде оболочки, потому что они находятся в удаленной конечной ветви, которая еще не была перенесена в магистраль. Возможно, расширение fStyle из WORD в DWORD имеет далеко идущие последствия для некоторых компонентов.
Как я уже сказал, это неудовлетворительно. В основном это сводится к следующему: «Было бы много работы, а мы ленивы».