Grid что это за программа

Обновлено: 25.01.2025

Графические ускорители NVIDIA GRID K1 и K2

Основная задача графических ускорителей NVIDIA GRID заключается в предоставлении высокой производительности графики в работе с ресурсоемкими приложениями требовательными к графическим вычислениям напрямую в виртуальной среде. Компания NVIDIA предлагает две модели графических процессоров линейки GRID, – K1 и K2. В ряде случаев могут быть использованы графические ускорители линейки NVIDIA Quadro, но решения Quadro не предназначены для установки в сервера и не позволяют обеспечить необходимую для задач виртуализации плотность, а также существует необходимость в большом количестве таких ускорителей.

Рассмотрим основные характеристики решений K1 и K2. Так как графические ускорители линейки GRID должны быть установлены в сервера их корпус, и система охлаждения значительно оптимизированы, обеспечивая хорошее охлаждение графическим чипам и памяти при интенсивной нагрузке. В моделях K1 и K2 лежат графические чипы на основе архитектуры NVIDIA Kepler. Чип GK107 используется в модели K1, а чип GK104 в модели K2. Модель K1 ориентирована на применение в виртуализации рабочих столов и приложений, не требующих высокой производительности от графической подсистемы, но в то же время, когда необходимо развернуть виртуальные машины для множества пользователей, в данной модели используется 4Гб графической памяти на каждый из четырех GPU. В то же время модель K2 ориентирована на более требовательные к графическим вычислениям приложения, такие как пакеты DCC. В данной модели используются более производительные GPU и быстрая память, для каждого из них также выделено по 4Гб графической памяти стандарта GDDR5.

В таблице 1.1 приведены основные технические характеристики GPU NVIDIA GRID K1 и K2.

1x 6-pin PCI Express power connector

Citrix XenServer с NVIDIA GRID Hypervisor

+ XenDesktop с HDX

Windows Server 2012 + RemoteFX

Windows Server 2008 R2 + RemoteFX

VMware ESXi + View с vSGA

Citrix XenServer + XenDesktop с HDX 3D Pro

Citrix XenServer с NVIDIA NVIDIA GRID

Hypervisor + XenDesktop с HDX

Windows Server 2012 + RemoteFX

Windows Server 2008 R2 + RemoteFX

VMware ESXi + View с vSGA

Таблица 1.1. Конфигурация плат NVIDIA GRID K1 и K2.

Если принимать во внимание фактор потребления энергии, то графический ускоритель K1 будет выгоднее по сравнению с более производительным ускорителем K2. При том же на модели K1 можно развернуть больше виртуальных машин и предоставить возможности использования производительной графики большему количеству пользователей. Но для решения более сложных задач (проектирование, 3D анимация, визуализация) все же необходимо прибегнуть к применению производительной модели K2 и разработать надежное питание энергией между всеми элементами системы.

Виртуализация рабочих столов и vGPU

Перед тем как мы перейдем к практическим экспериментам и демонстрации работы технологии в реальных приложениях, необходимо разобраться с теоретическими аспектами виртуализации рабочих столов и GPU, а так же в том, как организован сервер с NVIDIA GRID управляемый решениями Citrix.

Терминология

В данной статье мы рассматриваем виртуализацию рабочих столов, где выполняются основные приложения, предоставляя пользователям возможности полноценной рабочей станции с помощью удаленного подключения. В данном подразделе вы познакомитесь с основной терминологией.

CitrixReceiver – Легковесное приложение которое запускается на Windows, Mac, Linux, iOS, Android и Windows Phone устройстве пользователя и соединяется с виртуальной машиной в дата-центре на которой установлен Citrix XenDesktop.
CitrixXenDesktop – Продукт виртуализации рабочих столов от Citrix предоставляющий пользователю доступ к удаленному рабочему столу.
CitrixXenServer – Коммерческий гипервизор от Citrix который позволяет запускать множество операционных систем на одном серверном узле.
ВыделенныйGPU (DedicatedGPU) – решение, где GPU полностью используется виртуальной машиной не распределяясь между другими виртуальными машинами.
GPUPass-Through – технология которая связывает виртуальную машину с GPU. Эта технология разработана NVIDIA и известна как NMOS (NVIDIA Multi-OS). Она позволяет каждой операционной системе выполняемой на сервере виртуализации напрямую использовать все возможности физического GPU.
Хост (HostMachine) – компьютер на котором установлен гипервизор и запущена одна или несколько виртуальных машин и являющийся хостом. Каждая из виртуальных машин называется гостевой машиной. Гипервизор предоставляет гостевым операционным системам виртуальную операционную платформу и управляет выполнением гостевых операционных систем.
Гипервизор (Hypervisor) – технологически гипервизор или менеджер виртуальных машин (VMM) является частью программного обеспечения, прошивка или оборудование которого создают и запускают виртуальные машины.
Удаленная рабочая станция (RemoteWorkstation) – единица рабочей станции, которая запускается в дата-центре и перенаправляется через сеть на клиентское устройство. Удаленная рабочая станция может быть доступна как из офиса пользователя, так и может быть доступна со стороны партнерского портала, в путешествии или из дома пользователя.
Виртуальная машина (VirtualMachine) – единица операционной системы, которая запускается поверх гипервизора, используя абстрактный образ оборудования реализуемым гипервизором.
Виртуализация (Virtualization)– практика абстракции виртуальной машины из физического оборудования, на котором она выполняется. На практике виртуализация используется для запуска виртуальных машин на одном физическом сервере (оборудовании).
- Инфраструктура виртуальных рабочих столов (VirtualDesktopInfrastructure (VDI)) – практика размещения операционной системы на виртуальной машине в централизованном или удаленном сервере.
- Виртуализация оборудования (HardwareVirtualization) – создание виртуальной машины, которая действует подобно реальному оборудованию поверх гипервизора или как поднабор оборудования. Программное обеспечение выполняемое на таких виртуальных машинах, работает поверх ресурсов физического оборудования (т.е. операционная система может загружать родные для оборудования драйверы и взаимодействовать с ними напрямую).
- Аппаратно-виртуализированныйGPU (HardwareVirtualizedGPU) – платы K1 и K2 на основе чипов архитектуры NVIDIA Kepler позволяют множеству пользователей использовать возможности одного GPU и предоставляют каждому пользователю прямой доступ к "железному" GPU. Это увеличивает плотность пользователей, предоставляя им реальную производительность и совместимость.
- Программная виртуализация (SoftwareVirtualization) – программная виртуализация обеспечивает интерфейс между оборудованием и виртуальной машиной, создавая плотную адаптацию между различными уровнями конфигураций оборудования. На практике программы действуют аналогично аппаратным ресурсам, пропуская команды к гипервизору, который может выполнять их на реальном оборудовании или эмулируемом оборудовании.
- ВиртуальныйGPUNVIDIAGRID (NVIDIAGRIDvGPU) – ключевая технология, используемая для реализации виртуализации GPU. Это позволяет множеству виртуальных машин взаимодействовать напрямую с GPU. Система GRID Virtual GPU управляет ресурсами GPU которые позволяют множеству пользователей распределять возможности основного оборудования увеличивая плотность и формировать возможности полноценных PC в облаке.
Как вы можете заметить, ключевые технологии достаточно просты в понимании их назначения. Но как же реализуется инфраструктура сервера виртуальных машин на базе гипервизора Citrix XenServer и NVIDIA GRID? Для демонстрации инфраструктуры в данной статье мы приведем два примера; первый для решения VDI на основе GPU Pass-Through, а второй для VDI на основе vGPU.

NVIDIA CUDA и vGPU важная особенность

Если вы планируете использовать приложения, активно использующие GPU для ускорения вычислений, вам стоит обратить внимание на важную особенность. Технология виртуализированных GPU (vGPU) не поддерживает NVIDIA CUDA, OpenCL и Direct Compute. Это технологическая особенность присущая технологии вычислений общего назначения на GPU. Для обхода данной особенности необходимо использовать Dedicated GPU с технологией GPU Pass-Through. Это позволяет напрямую выполнять обращение из виртуальной машины к графическому процессору и "пробрасывать" GPU-accelerated приложения из виртуальной среды на реальное оборудование. При использовании vGPU вам доступны только графические API, такие как OpenGL и DirectX.

В таблице 1.2 приведены приложения, графические подсистемы которых поддерживают vGPU и функциональные ограничения, вызванные описанной выше особенностью.

Приложение

Поддержка vGPU

(OpenGL и DirectX)

Ограниченные возможности 1

Редакторы 3D графики и анимации

Autodesk 3ds Max 2016

Не доступен NVIDIA PhysX с GPU ускорением

Autodesk Maya 2016

Не доступен OpenCL evaluator (Evaluation Manager)

Не доступна аппаратная тесселяции геометрии в OpenSubdiv

Не доступен NVIDIA PhysX с GPU ускорением

Autodesk Mudbox 2016

Pixologic ZBrush 5

The Foundry MARI

Не доступны функции с GPU ускорением (CUDA, OpenCL)

Side Effects Houdini 14

Не доступна аппаратная тесселяция геометрии в OpenSubdiv

Не доступны функции с GPU ускорением в POP Grains Solver

Не доступны функции с GPU ускорением в Pyro

Не доступна аппаратная тесселяция геометрии в OpenSubdiv

Не доступна аппаратная тесселяция геометрии в OpenSubdiv

Редакторы 2D и векторной графики

Adobe Photoshop CC

Не доступны фильтры с GPU ускорением

Adobe Illustrator CC

Не доступны инструменты с GPU ускорением

Редакторы видео и системы пост-продакшн/композитинга

Adobe Premiere Pro CC

Adobe Mercury Engine с GPU ускорением

Переходы и эффекты с GPU ускорением

Adobe After Effects CC

Adobe Mercury Engine с GPU ускорением

Эффекты и фильтры с GPU ускорением

Ядро визуализации с трассировкой луча (NVIDIA OptiX)

The Foundry NUKE

Не доступны функции с GPU ускорением

Не доступны функции с GPU ускорением

Системы визуализации

NVIDIA mental ray

Не доступны функции GPU AO и GPU GI, NVIDIA iray (CUDA)

Не доступна версия с GPU ускорением (CUDA)

В Autodesk 3ds Max также не доступна версия с GPU ускорением

Chaos Group V-Ray RT

Не доступна версия с GPU ускорением (CUDA, OpenCL)

Не доступна версия с GPU ускорением (CUDA, OpenCL)

Otoy Octane Renderer

Cebas Moskito Renderer

PIXAR RenderMan 20

Да (Visualizer Integrator)

1 – Отсутствие прямой поддержки CUDA и OpenCL из-за ограничения технологии vGPU.

Таблица 1.2. Поддержка vGPU со стороны приложений и ограниченные возможности

Также хочется заметить, что на текущий момент гипервизор от Citrix и реализация управляющего драйвера NVIDIA GRID для Citrix XenServer не позволяют "пробрасывать" несколько GPU в одну виртуальную машину. Поэтому вы можете использовать только NVIDIA GRID в режиме GPU Pass-Through или исключить обработку OpenGL и DirectX на аппаратном уровне, а такой GPU как NVIDIA Tesla можно "пробросить" в виртуальную среду для вычислений CUDA-приложений.
Если же у вас используются не требовательные к графической подсистеме приложения или приложения, обладающие программным драйвером визуализации виртуального пространства, например Autodesk 3ds Max с драйвером Nitrous (Software), трюк с "пробросом" NVIDIA Tesla может сработать. Тогда вы получаете возможность выполнения вычислений на GPU с помощью NVIDIA CUDA, OpenCL и Direct Compute, а трехмерная сцена или модель, будут обрабатываться силами центрального процессора.

Инфраструктура виртуальных рабочих столов (VDI) с Dedicated GPU

Данная концепция носит имя Виртуальные удаленные рабочие станции (Virtual Remote Workstations) или VDI with Dedicated GPU. В данную концепцию входит предоставление неограниченных в функциях виртуальных рабочих мест с высокой производительностью свойственной персональным высокопроизводительным рабочим станциям применяемых инженерами или художниками для работы с комплексными моделями и большими массивами данных.

Общая схема реализации элементов VDI с Dedicated GPU.

В виртуальных рабочих станциях каждый из установленных в NVIDIA GRID K1 и K2 графических чипов целиком выделяется под виртуальную машину. Операционная система в виртуальной среде видит графический ускоритель и задействует его аналогично тому, как это реализовано в персональной рабочей станции. Такой подход позволяет использовать ключевые возможности современных графических ускорителей от NVIDIA и поддерживает не только API OpenGL или DirectX, но также позволяет выполнять вычисления общего назначения на GPU с помощью NVIDIA CUDA, OpenCL и Direct Compute. При этом выделенная под каждый из GPU память будет доступна в максимальном объеме (4 Гб на GPU).
Если планируется использовать такие приложения как Autodesk Maya 2016, Autodesk 3ds Max 2016 с NVIDIA iray renderer и V-Ray RT GPU, а так же приложения для вычислений физических моделей, поддерживающие вычисления на GPU, данный тип виртуальных рабочих столов будет наиболее подходящим.
Но у данного типа есть одно существенное ограничение. Оно заключается в том, что мы не можем использовать множество виртуальных машин и распределять каждый из GPU на плате GRID под несколько виртуальных машин. Это обусловлено описанной выше важной особенностью, – поддержкой технологии NVIDIA CUDA и других API для вычислений общего назначения на GPU.

Инфраструктура виртуальных рабочих столов (VDI) с vGPU

Вторая концепция ориентирована на развертывание нескольких виртуальных машин на каждом из GPU. Она позволяет профессиональным пользователям использовать ресурсоемкие графические приложения, требовательные к графической подсистеме (OpenGL, DirectX) без значительного снижения производительности и качества визуализации изображения и виртуального пространства. Это актуально в таких областях как проектирование в CAD и моделирование или анимация в DCC приложениях несколькими пользователями.

Общая схема реализации элементов VDI с vGPU.

На рисунке выше приведена общая диаграмма для четырех виртуальных машин выполняемых на сервере с NVIDIA GRID K2, где каждый из GPU работает с двумя виртуальными машинами. За управление распределением ресурсов GPU отвечает специальная система управления NVIDIA GRID установленная на Citrix XenServer.
Как уже было сказано выше, у данной концепции есть одно существенное ограничение. Оно заключается в том, что нельзя использовать CUDA приложения. Например, такие решения для визуализации как NVIDIA iray и V-Ray RT будут доступны только в режиме работы на центральном процессоре (CPU).
Эту особенность можно обойти следующим образом: вывести все вычисления на GPU в отдельный узел. Это может быть отдельный сервер с GPU линейки NVIDIA Tesla или это может быть комплексное решение в виде NVIDIA Quadro VCA. Это специальное серверное решение, которое обеспечивает высокую производительность в таких инструментах визуализации, как NVIDIA iray и V-Ray RT GPU или других решениях использующих NVIDIA CUDA. При соответствующей конфигурации прикладного программного обеспечения можно вынести вычисления из виртуальной среды на отдельные узлы и снизить нагрузку на сервер виртуализации.

Сколько виртуальных машин и пользователей поддерживаются NVIDIA GRID?

Так как мы рассматриваем две концепции реализации GPU в виртуальной среде, в данном подразделе представлены сведения о том, сколько виртуальных машин может быть развернуто на каждом из GPU и для каких задач они могут быть использованы.

Таблица 1.3. Количество виртуальных машин и пользователей для VDI with vGPU и VDI with Dedicated GPU.

Каждый из физических GPU способен работать одновременно с 8 виртуальными машинами. Но при развертывании необходимо отталкиваться от выполняемых задач. Например, если вы хотите использовать все возможности графических ускорителей, не только обработку графических API, но и вычисления, то тогда вам будет доступно только по одному GPU на каждую виртуальную машину.
Также имеется зависимость объемов памяти от выбранного типа vGPU и количества пользователей. При настройке Citrix XenServer вам будут доступны заранее подготовленные модели vGPU с фиксированным объемом памяти (таблица 1.4).

Плата

Кол-во физических GPU

Типы виртуальных GPU

Кол-во vGPU на физ. GPU

Grids: лучший Instagram-клиент для вашего Mac

Instagram — мобильный сервис, однако пользователи и разработчики давно пытаются перенести свою любимую фотосоцсеть на просторы настольных компьютеров. Неплохая попытка получилась у Picdeck, который отображал снимки в нескольких потоках, примерно как твиты в Tweetdeck. На этот раз хочу познакомить вас с программой Grids, которая предлагает классическую механику просмотра снимков в Instagram.

В Telegram-канале «Лайфхакер» только лучшие тексты о технологиях, отношениях, спорте, кино и многом другом. Подписывайтесь!

В нашем Pinterest только лучшие тексты об отношениях, спорте, кино, здоровье и многом другом. Подписывайтесь!

Здесь все, как и в привычном мобильном Инстаграме — лента друзей, раздел популярное, избранные снимки, снимки поблизости, ваш профиль, фидбек подписчиков. Поддерживаются все возможности кроме непосредственной загрузки снимков. Можно комментировать, лайкать и реагировать на комментарии ваших фолловеров.

Элемент управления Grid

Табличные элементы управления (обычно в их названии присутствуют слова Table или Grid) широко используются при разработке GUI. Так получилось, что на работе мы используем С++ и MFC для разработки пользовательского интерфейса. В начале мы использовали CGridCtrl — общедоступную и довольно известную реализацию грида. Но с некоторого времени он перестал нас устраивать и появилась на свет собственная разработка. Идеями, лежащими в основе нашей реализации, я хочу с вами здесь поделиться. Есть задумка сделать open source проект (скорее всего под Qt). Поэтому данную заметку можно рассматривать как «Proof Of Concept». Конструктивная критика и замечания приветствуются.

Причины, по которым меня не устраивают существующие реализации я опущу (это тема для отдельной заметки).
Проекты у нас инженерно-научные, с богатой графикой, и списки и таблицы используются повсеместно. Поэтому новый грид должен был обеспечивать гибкую кастомизацию, хорошее быстродействие и минимальное потребление памяти при показе больших объемов информации. При разработке я старался придерживаться следующим правилом: реализуй функциональность максимально обобщенно и абстрактно, но не во вред удобству использования и оптимальности работы. Конечно, это правило противоречиво, но насколько мне удалось соблюсти баланс — судить вам.

Чтобы с чего-то начать, давайте попробуем дать определение элементу управления grid. Для сохранения общности можно сказать, что grid — это визуальный элемент, который разбивает пространство на строки и столбцы. В результате получается сетка ячеек (место пересечения строк и столбцов), внутри которых отображается некоторая информация. Таким образом у грида можно различить два компонента: структуру и данные. Структура грида определяет как мы будем разбивать пространство на строки и столбцы, а данные описывают, собственно, то, что мы хотим видеть в получившихся ячейках.
- Главное свойство Count — количество линий, из которых состоит Lines
- Каждая линия может менять свой размер (строка высоту, а столбец — ширину)
- Линии можно переупорядочивать (строки сортировать, столбцам менять порядок)
- Линии можно скрывать (делать невидимыми для пользователя)
Комментарии и некоторые служебные функции и поля опущены для наглядности.
Вы можете заметить, что в классе есть функции GetAbsoluteLineID и GetVisibleLineID . Так как мы позволяем перемешивать и скрывать линии, то абсолютный и видимый индекс линии различаются. Надеюсь картинка наглядно показывает эту ситуацию.

Также нужно сделать пояснение по поводу строки
Здесь определён сигнал (так он называется в Qt или boost). С появлением С++11 и std::function, можно легко написать простую реализацию signals/slots, чтобы не зависеть от внешних библиотек. В данном случае мы определили эвент в классе Lines, и к нему можно подключать любую функцию или функтор. Например грид подключается к этому эвенту и получает оповещение, когда экземпляр Lines меняется.

Таким образом структура грида у нас представлена двумя экземплярами Lines:

Переходим к данным. Каким образом давать гриду информацию о том, какие данные он будет отображать и как их отображать? Здесь уже всё изобретено до нас — я воспользовался триадой MVC (Model-View-Controller). Начнем с элемента View. Так же как класс Lines определяет не одну линию, а целый набор, определим класс View как нечто, что отображает какие-то однородные данные в некотором подмножестве ячеек грида. Например, у нас в первом столбце будет отображаться текст. Это означает, что мы должны создать объект, который умеет отображать текстовые данные и который умеет говорить, что отображаться эти данные должны в первой колонке. Так как данные у нас могут отображаться разные и в разных местах, то лучше реализовать эти функции в разных классах. Назовем класс, который умеет отображать данные, собственно View, а класс, который умеет говорить где данные отображать Range (набор ячеек). Передавая в грид два экземпляра этих классов, мы как раз указываем что и где отображать.

Давайте подробнее остановимся на классе Range. Это удивительно маленький и мощный класс. Его главная задача — быстро отвечать на вопрос, входит ли определенная ячейка в него или нет. По сути это интерфейс с одной функцией:

Таким образом можно определять любой набор ячеек. Самыми полезными конечно же будут следующие два:
Первый класс определяет набор из всех ячеек, а второй — набор из одного конкретного столбца.
- Сколько надо места, что бы отобразить данные (например чтобы колонкам установить ширину, достаточную для отображения текста — режим Fit)
- Дай текстовое представление данных (чтобы скопировать в буфер обмена как текст или отобразить в tooltip)
Для наглядности рассмотрим пример в котором в первом столбце отображаются чекбоксы и текст. Во втором столбце представлены радио-кнопки, квадратики с цветом и текстовое представление цвета. И еще в одной ячейке есть звёздочка.

Например для чекбокса мы будем использовать LayoutLeft, который спросит у View его размер и «откусит» прямоугольник нужного размера от прямоугольника ячейки. А для текста мы будем использовать LayoutAll, к которому в параметре cellRect перейдет уже усеченный прямоугольник ячейки. LayoutAll не будет спрашивать размер у своего View, а просто «заберет» все доступное пространство ячейки. Можно напридумывать много разных полезных Layouts, которые будут комбинироваться с любыми View.

Возвратимся к классу Grid, для которого мы хотели задавать данные. Получается, что хранить мы можем тройки <Range, View, Layout>, которые определяют в каких ячейках, каким образом отображать данные, плюс как эти данные должны быть расположены внутри ячейки. Итак класс Grid у нас выглядит примерно так:
1. Нужно отфильтровать m_data и оставить только те тройки, для которых наша ячейка попадает в Range
2. Определить прямоугольник для ячейки
3. Определить прямоугольники для всех View
4. Отрисовать все View в рассчитанные для них прямоугольники
Этот класс в конструкторе выполняет первые три пункта и сохраняет результат в m_cache. При этом функция Draw получилась достаточно легковесной. За эту легковесность пришлось заплатить в виде m_cache. Поэтому создавать экземпляры такого класса на каждую ячейку будет накладно (мы ведь договорились не иметь данных, зависящих от общего количества ячеек). Но нам и не надо иметь экземпляры CellCache для всех ячеек, достаточно только для видимых. Как правило в гриде видна небольшая часть всех ячеек и их количество не зависит от общего числа ячеек.

Таким образом у нас появился еще один класс, который управляет видимой областью грида, хранит CellCache для каждой видимой ячейки и умеет быстро рисовать их.

Когда пользователь меняет размер грида или скроллирует содержимое, мы просто выставляем новый visibleRect в этом объекте. При этом переформируется m_cells, так чтобы содержать только видимые ячейки. Функциональности GridCache достаточно, что бы реализовать read-only грид.

Разделение классов Grid и GridCache очень полезно. Оно позволяет, например, создавать несколько GridCache для одного экземпляра Grid. Это может использоваться для реализации постраничной печати содержимого грида или экспорта грида в файл в виде изображения. При этом объект GridWindow никаким образом не модифицируется — просто в стороне создается GridCache, ссылающийся на тот же экземпляр Grid, в цикле новому GridCache выставляется visibleRect для текущей страницы и распечатывается.

Как же добавить интерактивности? Здесь на первый план выходит Controller. В отличие от остальных классов, этот класс определяет интерфейс со многими функциями. Но лишь потому, что самих мышиных событий достаточно много.

Так же как и для отрисовки, для работы с мышью нам нужны только видимые ячейки. Добавим в класс GridCache функции обработки мыши. По положению курсора мыши определим какая ячейка (CacheCell) находится под ней. Далее в ячейке для всех View, в чей прямоугольник попала мышь, забираем Controller и вызываем у него соответствующий метод. Если метод возвратил true — прекращаем обход Views. Данная схема работает достаточно быстро. При этом нам пришлось в класс View добавить ссылку на Controller.

Осталось разобраться с классом Model. Он нужен как шаблон адаптер. Его основная цель — предоставить данные для View в «удобном» виде. Давайте рассмотрим пример. У нас есть ViewText который умеет рисовать текст. Что бы его нарисовать в конкретной ячейке, этот текст надо для ячейки запросить у объекта ModelText, который, в свою очередь, лишь интерфейс, а его конкретная реализация знает откуда текст взять. Вот примерная реализация класса ViewText:

Таким образом несложно угадать какой интерфейс должен быть у ModelText:

Обратите внимание, мы добавили сеттер для того, что бы им мог воспользоваться контроллер. На практике наиболее часто используется реализация ModelTextCallback

Эта модель позволяет при инициализации грида назначить лямбда функции доступа к настоящим данным.
Ну а что же общего у моделей для разных данных: ModelText, ModelInt, ModelBool . В общем-то ничего, единственное, что про них всех можно сказать, что они должны информировать все заинтересованные объекте о том, что данные изменились. Таким образом базовый класс Model у нас примет следующий вид:

В итоге наш грид разбился на множество небольших классов, каждый из которых выполняет четко определенную небольшую задачу. С одной стороны может показаться, что для реализации грида представлено слишком много классов. Но, с другой стороны, классы получились маленькими и простыми, с четкими взаимосвязями, что упрощает понимание кода и уменьшает его сложность. При этом всевозможные комбинации наследников классов Range, Layout, View, Controller и Model дают очень большую вариативность. Использование лямбда функций для ModelCallback позволяют легко и быстро связывать грид с данными.

В следующей заметке я опишу как реализовать стандартную функциональность грида: selection, sorting, column/row resize, printing, как добавить заголовок (фиксированные верхние строки и левые столбцы).
Раскрою небольшой секрет — все что описано в данной статье уже достаточно для реализации вышеперечисленного. Если какую-то функциональность я пропустил, пожалуйста, пишите в комментариях и я опишу их реализацию в следующей статье.

CSS Grid понятно для всех

Grid представляет собой пересекающийся набор горизонтальных и вертикальных линий — один набор определяет столбцы, а другой строки. Элементы могут быть помещены в сетку, соответственно строкам и столбцам.

Поддержка браузерами

В 2020 году поддержка браузерами достигает 94 %

Grid контейнер

Мы создаем grid контейнер, объявляя display: grid или display: inline-grid на элементе. Как только мы это сделаем, все прямые дети этого элемента станут элементами сетки.

grid-template-rows — это CSS свойство, которое определяет названия линий и путь размера функции grid rows.

CSS свойство grid-row определяет с какой строки в макете сетки будет начинаться элемент, сколько строк будет занимать элемент, или на какой строке завершится элемент в макете сетки. Является сокращенным свойством для свойств grid-row-start и grid-row-end.

Свойство CSS grid-gap является сокращенным свойством для grid-row-gap и grid-column-gap , определяющего желоба между строками и столбцами сетки.

Свойство grid-template-areas определяет шаблон сетки ссылаясь на имена областей, которые заданы с помощью свойства grid-area.

Повторение названия области приводит к тому, что содержимое охватывает эти ячейки. Точка означает пустую ячейку. Сам синтаксис предоставляет визуализацию структуры сетки.

С помощью свойства grid-area мы можем назначить каждой из этих областей свое собственное имя. Именование областей еще не создает никакого макета, однако теперь у нас есть именованные области, которые мы можем в нем использовать.

Создаем шаблон сайта с CSS Grid:

Изменяем шаблон

Вы можете изменить шаблон просто перераспределив грид-области в grid-template-areas .

Таким образом, если мы сменим на это:

То в результате получим такой шаблон:

Гриды с медиа запросами

Одной из сильных сторон гридов является то, что вы можете создать уже совершенно другой шаблон за секунды.

Это делает CSS Grid идеальным для медиа запросов. Мы можем просто переназначить значения в ASCII-графике и обернуть результат в конечный медиа запрос.

В результате получим:

Таким образом, все дело состоит в переназначении значений в свойстве grid-template-areas .

Заключение

В данной статье мы рассмотрели всего лишь верхушку CSS Grid Layout айсберга. Иногда сложно поверить своим глазам какие штуки удается сделать при помощи CSS Grid. Это разрыв всех шаблонов. И мне это нравится.

Я вам советую обратить внимание на данную спецификацию и потратить немного своего времени на ее изучение. Поверьте, в будущем вам это точно пригодится и не важно, пишете вы на React, Angular, Vue (вставьте свое). Grid’ы пришли надолго.

Читайте также: