Мне нужно эмулировать стратегию размещения окна Fluxbox оконный менеджер.
В качестве приблизительного руководства визуализируйте окна с произвольным размером, заполняющие экран по одному за раз, где грубый размер каждого результата составляет в среднем 80 окон на экране без какого-либо окна, перекрывающего другое.
Если в вашей системе установлены Fluxbox и Xterm, вы можете попробовать xwinmidiarptoy BASH script, чтобы увидеть грубый прототип того, что я хочу. См. Примечание xwinmidiarptoy.txt. Я написал об этом, объясняя, что он делает и как его следует использовать.
Важно отметить, что окна будут закрыты, а пространство, закрывающее ранее занятые окна, снова станет доступным для размещения новых окон.
Алгоритм должен быть Online Algorithm обрабатывать данные "по частям в серийном режиме, т.е. в том порядке, в котором вход подается в алгоритм, без ввода всего ввода с самого начала".
Стратегия размещения окна Fluxbox имеет три бинарных параметра, которые я хочу подражать:
-
Windows строит горизонтальные строки или вертикальные столбцы (потенциально)
-
Windows размещаются слева направо или справа налево
-
Окна размещаются сверху вниз или снизу вверх
Различия между целевым алгоритмом и алгоритмом размещения окна
Единицы координат не являются пикселями. Сетка, в которой будут размещаться блоки, будет 128 x 128 единиц. Кроме того, область размещения может быть дополнительно уменьшена граничной областью, помещенной внутри сетки.
Почему алгоритм является проблемой?
Он должен работать до крайних сроков потока в реальном времени в звуковом приложении.
В настоящий момент меня интересует только быстрый алгоритм, не беспокойтесь о последствиях потоков реального времени и всех препятствий в программировании, которые это приносит.
И хотя алгоритм никогда не будет размещать окно, которое перекрывает другое, пользователь сможет размещать и перемещать определенные типы блоков, будут существовать перекрывающиеся окна. Структура данных, используемая для хранения окон и/или свободного пространства, должна иметь возможность справиться с этим перекрытием.
До сих пор у меня есть два варианта, из которых я создал проиллюстрированные прототипы для:
1) Порт алгоритма размещения Fluxbox в мой код.
Проблема заключается в том, что клиент (моя программа) выходит из звукового сервера (JACK), когда я пытаюсь помещая наихудший сценарий из 256 блоков с использованием алгоритма. Этот алгоритм выполняет более 14000 полных (линейных) сканирований списка блоков, уже размещенных при размещении 256-го окна.
Для демонстрации этого я создал программу под названием text_boxer-0.0.2.tar.bz2, которая принимает текстовый файл в качестве входного и упорядочивает его в ячейках ASCII. Выполните make
, чтобы создать его. Немного недружелюбный, используйте --help
(или любую другую недопустимую опцию) для списка параметров командной строки. Вы должны указать текстовый файл, используя опцию.
2) Мой альтернативный подход.
Только частично реализованный, этот подход использует структуру данных для каждой области прямоугольного пространства free unused (список окон может быть полностью разделенным и не нужен для тестирования этого алгоритма). Структура данных действует как node в двусвязном списке (с сортировкой вставки), а также содержит координаты верхнего левого угла, ширины и высоты.
Кроме того, каждая структура данных блока также содержит четыре ссылки, которые соединяются с каждым непосредственно смежным (касающимся) блоком на каждой из четырех сторон.
ВАЖНОЕ ПРАВИЛО: Каждый блок может касаться только одного блока на сторону. Это правило относится к алгоритму хранения свободного неиспользуемого пространства и не имеет никакого отношения к тому, сколько фактических окон может касаться друг друга.
Проблема с этим подходом заключается в том, что очень сложный, Я применил простые случаи, когда 1) пространство удалено из одного угла блока, 2) разделение соседних блоков так, чтобы соблюдалось ВАЖНОЕ ПРАВИЛО.
Менее простой случай, когда место, которое нужно удалить, может быть найдено только в столбце или строке ящиков, только частично реализовано - если один из блоков, которые нужно удалить, является точной подгонкой для ширины (то есть столбца) или высота (т.е. строка), тогда возникают проблемы. И даже не упоминайте, что это только проверяет столбцы на одну коробку шириной и строит одну коробку высотой.
Я реализовал этот алгоритм в C - языке, который я использую для этого проекта (я не использовал С++ в течение нескольких лет, и мне неудобно его использовать, сосредоточив все свое внимание на разработке C, это хобби), Реализация - это 700 + строк кода (включая множество пустых строк, линий фигур, комментариев и т.д.). Реализация работает только для стратегии размещения горизонтальных строк + left-right + top-bottom.
Итак, мне нужно добавить какой-то способ сделать эти строки кода +700 для других 7 вариантов стратегии размещения, или мне придется дублировать эти +700 строк кода для остальных семи опций, Ни один из них не привлекателен, во-первых, потому что существующий код достаточно сложный, второй - из-за раздувания.
Алгоритм даже не на том этапе, когда я могу использовать его в сценарии с наихудшим сценарием в реальном времени из-за отсутствия функциональности, поэтому я до сих пор не знаю, действительно ли он работает лучше или хуже первого подхода.
Текущее состояние реализации этого алгоритма C freespace.c. Я использую gcc -O0 -ggdb freespace.c
для сборки и запускаю его в формате xterm, чтобы по крайней мере 124 х 60 символов.
Что еще есть?
Я снял и сбрасывал со счетов:
-
Bin Packing: их акцент на оптимальную подгонку не соответствуют требованиям этого алгоритм.
-
Рекурсивное бисекционное размещение: звуки многообещающие, но они предназначены для проектирования схем. Их упор - оптимальная длина провода.
Оба этих, особенно последних, все элементы, которые должны быть размещены/пакеты, известны до начала алгоритма.
Что вы думаете об этом? Как бы вы к нему подошли? На какие еще алгоритмы я должен смотреть? Или даже какие концепции я должен исследовать, видя, как я не изучал информатику/разработку программного обеспечения?
Пожалуйста, задавайте вопросы в комментариях, если необходима дополнительная информация.
Дальнейшие идеи, разработанные с момента запроса этого вопроса
- Некоторая комбинация моего "альтернативного алгоритма" с пространственным хешмапом для определения того, будет ли размещено большое окно, будет охватывать несколько блоков свободного пространства.