RU2483350C2

RU2483350C2 - Диспетчер компоновки

Info

Publication number: RU2483350C2
Application number: RU2010120429/08A
Authority: RU
Inventors: Суджал С. ПАРИХ; Дэвид П. РЕЛАЯ
Original assignee: Майкрософт Корпорейшн
Priority date: 2007-11-21
Filing date: 2008-11-14
Publication date: 2013-05-27
Also published as: RU2010120429A; CN101868791A; EP2223234A4; US20090132578A1; WO2009067388A2; JP5260672B2; EP2223234A2; CN102591637A; WO2009067388A3; JP2011507056A; CN101868791B; US8095865B2; BRPI0820487A2

Abstract

Изобретение относится к области управления обновлениями компоновки в элементах пользовательского интерфейса. Техническим результатом является повышение эффективности управления обновлениями компоновки для элементов пользовательского интерфейса. "Грязное" состояние элементов пользовательского интерфейса отслеживается в дереве с множеством узлов элементов пользовательского интерфейса. "Грязное" состояние позволяет идентифицировать "грязные" поддеревья узлов. Корневой узел идентифицируется для каждого из "грязных" поддеревьев. Затронутые части дерева обновляются, начиная с корневого узла, который был идентифицирован для каждого из "грязных" поддеревьев. Любые процессы компоновки, которые выполняются в настоящее время в каких-либо узлах-потомках измененного предка, отменяются, и процесс компоновки возобновляется в измененном предке. После обновления затронутых частей дерева обновленные элементы пользовательского интерфейса затем визуализируются на устройстве вывода. 3 н. и 9 з.п. ф-лы, 8 ил.

Description

УРОВЕНЬ ТЕХНИКИ

Современные компьютерные операционные системы имеют возможность представлять и управлять элементами графического пользовательского интерфейса на устройстве вывода, таком как монитор или принтер. Когда элемент графического пользовательского интерфейса создается в приложении, объект подгоняется по размеру и помещается соответствующим образом для визуализации на устройстве вывода. Аналогичным образом, когда существующий элемент графического пользовательского интерфейса модифицируется или удаляется в приложении, или добавляется новый элемент пользовательского интерфейса, устройство вывода должно отражать это изменение соответствующим образом. Существующие компьютерные операционные системы используют драйверы устройств, чтобы связываться с конкретными устройствами вывода, таким образом, избавляя разработчика программного обеспечения от сложных подробностей визуализации графических выходных данных на конкретных устройствах вывода. В существующих компьютерных операционных системах это достигается посредством публикации прикладных программных интерфейсов ("API") для разработчиков будущего программного обеспечения.

Обычно API - это набор высокоуровневых вызовов функций, которые доступны разработчику программного обеспечения и которые не зависят от низкоуровневых инструкций, необходимых для какого-либо конкретного устройства. Платформа или операционная система, с помощью драйверов устройств, типично выполняет любое необходимое преобразование высокоуровневых API-вызовов в низкоуровневые специфичные для устройства вызовы.

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

Раскрытие изобретения

Различные технологии и способы раскрываются для управления обновлениями компоновки для элементов пользовательского интерфейса. "Грязное" состояние элементов пользовательского интерфейса отслеживается в дереве элементов пользовательского интерфейса. Дерево содержит множество узлов элементов пользовательского интерфейса, и "грязное" состояние позволяет идентифицировать "грязные" поддеревья узлов. Корневой узел идентифицируется для каждого из "грязных" поддеревьев. Затронутые части дерева обновляются, начиная с корневого узла, который был идентифицирован для каждого из "грязных" поддеревьев. После обновления затронутых частей дерева, обновленные элементы пользовательского интерфейса затем визуализируются на устройстве вывода.

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

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

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

Краткое описание чертежей

Фиг. 1 является схематическим видом компьютерной системы одного варианта осуществления.

Фиг. 2 является схематическим видом приложения диспетчера компоновки одного варианта осуществления, функционирующего в компьютерной системе на фиг. 1.

Фиг. 3 является схематическим видом примерного дерева узлов, которое имеет два различных "грязных" поддерева узлов.

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

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

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

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

Фиг. 8 является блок-схемой процесса для одного варианта осуществления, который иллюстрирует этапы, включенные в отмену процесса компоновки.

Осуществление изобретения

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

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

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

Например, указатели состояния могут использоваться процессом компоновки, который вызывается диспетчером компоновки перед повторным выполнением обновлений в пользовательском интерфейсе. Термин "процесс компоновки", как используется в данном документе, подразумевает включение в себя процесса задания размеров и расположения элементов пользовательского интерфейса. Термин "скомпонованный", когда используется в данном документе, подразумевает включение в себя того факта, что элемент пользовательского интерфейса был подогнан по размеру и расположен, чтобы отражать изменения, которые до сих пор оказывали влияние на этот элемент пользовательского интерфейса. Процесс компоновки может включать в себя процесс измерения и/или процесс размещения. "Процесс измерения" - это процесс, который устанавливает, насколько большим необходимо быть отдельному элементу пользовательского интерфейса. Во время процесса измерения узел определяет размер, который ему требуется, путем определения размера, который требуется всем его дочерним узлам, или если узел не имеет дочерних узлов, путем определения размера, который требуется самому узлу. При измерении своих дочерних узлов (если есть) узел предоставляет ограничение по размеру, которым типично является размер, который узел-родитель оставил для распределения дочерним узлам, который узел еще должен измерить; ограничение размера может также быть неограниченным в одном или обоих измерениях. В одном варианте осуществления, независимо от того, имеет ли узел дочерние узлы или нет, другие ограничения, такие как высота, минимальная высота, максимальная высота, ширина, максимальная ширина и минимальная ширина, могут также использоваться, если они были указаны. "Процесс размещения" - это процесс, в котором родительский элемент уведомляет дочерний узел о положении и размере, который назначен этому дочернему узлу для его отображения. Он может быть меньше, больше или равен размеру, который узел указал как требуемый ему в процессе измерения. Узел соответствующим образом располагает себя на экране и подгоняет по размеру. Такие свойства, как режим растяжения, горизонтальное выравнивание и вертикальное выравнивание могут также использоваться, чтобы определять положение и/или размер узла, если указаны.

В некоторых вариантах осуществления, описанных с дополнительными подробностями на фиг. 4-8, состояние изменений, которые произошли в узлах-предках, используются для того, чтобы сделать выполнение процесса компоновки (например, процессы измерения и/или размещения) более эффективным. Термин "узел-предок", как используется в данном документе, подразумевает включение в себя любого предшествующего узла, который содержится в восходящей линейной цепочке для указанного узла. Термин "родительский узел", как используется в данном документе, подразумевает включение в себя непосредственного родительского узла (например, вышестоящий узел) для указанного узла. При выполнении процесса компоновки (процесса измерения и/или размещения) для данного узла, диспетчер компоновки определяет, изменились ли какие-либо узлы-предки. Если какие-либо узлы-предки изменились, тогда любые компоновки (измерения и/или размещения) в процессе для узлов-потомков (например, дочерних узлов) ниже измененного предка отменяются, и процесс компоновки (измерение или размещение) возобновляется в измененном предке. Если какие-либо узлы-предки для указанного узла не изменились, тогда процесс компоновки (измерения и/или размещения) продолжает идти вниз по пути узлов-потомков. В одном варианте осуществления, распознавая внесенные изменения в предках, можно избежать бесполезной работы посредством обработки изменений на уровне предка как противоположность уровню потомка. В ином случае, эти усилия можно направить на обработку изменений в узлах-потомках, которые могут затем стать устаревшими, когда обновления для узлов-предков позже обрабатываются. Некоторые из этих способов теперь будут объяснены более подробно.

Как показано на фигуре 1, примерная компьютерная система, чтобы использоваться для осуществления одной или более частей системы, включает в себя вычислительное устройство, такое как вычислительное устройство 100. В своей наиболее базовой конфигурации, вычислительное устройство 100 типично включает в себя, по меньшей мере, один блок 102 обработки и запоминающее устройство 104. В зависимости от точной конфигурации и типа вычислительного устройства, запоминающее устройство 104 может быть энергозависимым (например, RAM), энергонезависимым (например, ROM, флэш-память и т.д.) или какой-либо комбинацией двух этих вариантов. Эта самая базовая конфигурация проиллюстрирована на фигуре 1 посредством пунктирной линии 106.

Дополнительно, устройство 100 также может иметь дополнительные особенности/функциональность. Например, устройство 100 может также включать в себя дополнительное устройство хранения (съемное и/или стационарное), в том числе, но не только, магнитные или оптические диски либо ленты. Такое дополнительное устройство хранения проиллюстрировано на фиг. 1 посредством съемного запоминающего устройства 108 и несъемного запоминающего устройства 110. Компьютерные носители хранения данных могут включать в себя энергозависимые и энергонезависимые, съемные и несъемные носители, реализованные любым способом или технологией для хранения информации, такой как читаемые компьютером инструкции, структуры данных, программные модули или другие данные. Запоминающее устройство 104, съемное устройство 108 хранения и стационарное устройство 110 хранения являются примерами компьютерных носителей хранения. Компьютерные носители хранения включают в себя (но не только) RAM, ROM, EEPROM, флэш-память или другую технологию памяти, CD-ROM, универсальные цифровые диски (DVD) или другие оптические устройства хранения, магнитные кассеты, магнитные ленты, устройства хранения на магнитных дисках или другие магнитные устройства хранения, либо любой другой носитель, который может быть использован для того, чтобы сохранять нужную информацию, и доступ к которому может осуществляться посредством устройства 100. Любые такие компьютерные носители хранения могут быть частью устройства 100.

Вычислительное устройство 100 включает в себя одно или более соединений 114 связи, которые позволяют вычислительному устройству 100 связываться с другими компьютерами/приложениями 115. Устройство 100 может также иметь устройство(а) 112 ввода, такие как клавиатура, мышь, перо, устройство голосового ввода, устройство сенсорного ввода и т.д. Устройство(а) вывода 111, такие как дисплей, динамики, принтер и т.д., также могут быть включены. Эти устройства хорошо известны в области техники, и нет необходимости детально обсуждать их здесь. В одном варианте осуществления вычислительное устройство 100 включает в себя приложение 200 диспетчера компоновки. Приложение 200 диспетчера компоновки будет описано более подробно на фигуре 2.

Обращаясь теперь к фигуре 2 и продолжая ссылаться на фигуру 1, иллюстрируется приложение 200 диспетчера компоновки, функционирующее на вычислительном устройстве 100. Приложение 200 диспетчера компоновки является одной из прикладных программ, которые постоянно находятся в вычислительном устройстве 100. Однако будет понятно, что приложение 200 диспетчера компоновки может альтернативно или дополнительно быть осуществлено как машиноисполняемые инструкции на одном или более компьютерах и/или в других вариациях, чем показано на фигуре 1. Альтернативно или дополнительно, одна или более частей приложения 200 диспетчера компоновки могут быть частью системной памяти 104, на других компьютерах и/или приложениях 115, или другими такими вариациями, которые придут на ум специалисту в области техники компьютерного программного обеспечения.

Приложение 200 диспетчера компоновки включает в себя программную логику 204, которая отвечает за выполнение некоторых или всех способов, описанных в данном документе. Программная логика 204 включает в себя логику для координирования обновления размеров и позиций элементов 206 пользовательского интерфейса (как описано ниже относительно фигуры 3); логику для отслеживания "грязного" состояния элементов пользовательского интерфейса в дереве элементов 208 (как описано ниже относительно фигур 4-7); логику для обновления затронутых частей дерева элементов 210 (как описано ниже относительно фигуры 6); логику для использования специального состояния в узлах в дереве, чтобы находить корни "грязных" поддеревьев, чтобы избежать бесполезных повторных вычислений во время обновлений 212 (как описано ниже относительно фигур 4-7); и другую логику 220 для работы приложения 200 диспетчера компоновки.

Фигура 3 является схематическим видом примерного дерева узлов, которое имеет два различных "грязных" поддерева узлов. Термин "поддерево", как используется в данном документе, подразумевает включение в себя меньшего поднабора узлов в дереве, или установленный другой путь, дерево в дереве. Термин "грязное поддерево", как используется в данном документе, подразумевает включение в себя одного или более соседних узлов предков и потомков, которые помечены как "грязные", и которые имеют только один узел, у которого родительский узел не является "грязным". Давайте посмотрим на несколько примеров, чтобы сделать это определение более ясным. В примере, показанном на фиг. 3, существуют два "грязных" поддерева. Первое поддерево содержит canvas1. Canvas1 является членом только первого поддерева, поскольку он не имеет непосредственного предка или потомка, который также является "грязным". Второе поддерево содержит canvas3 и R4. Canvas3 и R4 имеют связь предок/потомок, являются соседними, и canvas3 является членом только поддерева, которое не имеет непосредственного предка, который также является "грязным". Концепция "грязного" поддерева будет использоваться далее, в обсуждении некоторых чертежей, таких как фигура 6.

Обращаясь теперь к фигурам 4-8 и продолжая ссылаться на фигуры 1-3, этапы осуществления одного или более вариантов осуществления приложения 200 диспетчера компоновки описываются более подробно. В некоторых вариантах осуществления процессы, показанные на фигурах 4-8, по меньшей мере, частично реализованы в операционной логике вычислительного устройства 100. Фигуры 4-5 предоставляют некоторые высокоуровневые примеры использования изменений предка, чтобы сделать процесс компоновки более эффективным. Фигуры 6-8 описывают некоторые более подробные способы применения этих более широких концепций к примерным вариантам осуществления.

Обращаясь теперь к фигуре 4, где показана блок-схема 240 процесса, которая иллюстрирует один вариант осуществления этапов, включенных в использование состояния изменений предка, чтобы сделать процесс компоновки (измерение, размещение и т.д.) более эффективным. Процесс компоновки вызывается для данного узла (этап 242). Приложение 200 диспетчера компоновки определяет, изменились ли какие-либо узлы-предки для данного узла (этап 244). Если какой-либо предок(и) изменились (точка 246 принятия решения), тогда компоновки в процессе выполнения для узлов-потомков ниже изменившегося предка отменяются (этап 248), и процесс компоновки возобновляется в измененном предке (этап 249). Если предок(и) не изменились (точка 246 принятия решения), тогда процесс компоновки продолжает идти вниз по пути потомков (этап 250).

Обращаясь теперь к фигуре 5, где показана блок-схема 270 процесса, которая иллюстрирует один вариант осуществления этапов, включенных в пометку родительского узла как "грязного", когда размер узла изменился, чтобы избежать бесполезной работы. Процесс компоновки начинается для указанного узла (этап 272). Если требуемый размер узла изменился (точка 274 принятия решения), тогда "грязный" указатель помечается на родительском узле указанного узла (этап 278), текущий процесс компоновки отменяется (этап 278), и процесс компоновки выполняется в родителе (этап 280), как описано более подробно на других чертежах. Если требуемый размер узла не изменился (точка 274 принятия решения), тогда процесс компоновки продолжается со следующим узлом-братом для этого узла (этап 282).

Фигура 6 является блок-схемой 320 процесса, которая иллюстрирует один вариант осуществления этапов, включенных в обновление компоновки непосредственно перед визуализацией посредством обработки "грязных" поддеревьев. В начале процесса обновления компоновки диспетчер 200 компоновки определяет, изменился ли размер окна, или необходимо ли измерить элемент где-либо в дереве (например, измерение является "грязным") (точка 322 принятия решения). Окно может включать в себя любую область экрана, в которой отображаются элементы пользовательского интерфейса, такую как весь экран, окно на экране, область страницы браузера и т.д. Если любое из этих условий истинное, тогда корневой узел "грязного" поддерева измеряется (этап 324), и оценка затем выполняется снова рекурсивно (чтобы обработать дочерние узлы каждого узла). Если никакое из этих условий не истинно (точка 322 принятия решения), тогда диспетчер 200 компоновки, определяет, необходимо ли где-либо в дереве разместить элемент (например, размещение является "грязным") (точка 326 принятия решения). Если так, тогда корневой узел размещается (этап 328), и процесс циклически возвращается в точку 322 принятия решения.

Если размещение не является "грязным" где-либо в дереве (точка 326 принятия решения), тогда запускаются любые стоящие в очереди события изменения размера (этап 330), чтобы позволять приложению выполнять дополнительный код, вставляемый пользователем, в ответ на изменение элементом своего размера прежде, чем элемент отображается со своим новым размером. Если дерево "грязное" (точка 332 принятия решения), тогда процесс циклически возвращается в точку 322 принятия решения. Если дерево не "грязное" (точка 332 принятия решения), тогда запускаются события обновленной компоновки (этап 334), чтобы позволять приложению выполнять код, вставляемый пользователем, в ответ на завершение операции обновления компоновки прежде, чем какие-либо из обновленных элементов отображаются со своими новыми размерами и/или положениями. Если дерево "грязное" (точка 336 принятия решения), тогда процесс циклически возвращается в точку 322 принятия решения. Если дерево не "грязное" (точка 336 принятия решения), тогда процесс завершает работу (этап 338).

Обращаясь теперь к фигуре 7, где показана блок-схема 350 процесса, которая иллюстрирует один вариант осуществления некоторых подробных этапов, затронутых при выполнении процесса компоновки в указанном узле. Если сам указанный узел не является "грязным" (точка 352 принятия решения), тогда диспетчер 200 компоновки выполняет проверку, чтобы увидеть, имеет ли указанный узел "грязного" потомка (точка 358 принятия решения), и продолжает обработку по пути "грязного" потомка, как будет описано ниже. Если сам указанный узел является "грязным" (точка 352 принятия решения), тогда процесс компоновки выполняется в указанном узле (этап 354). Если узел-предок в настоящее время помечен как "грязный" (точка 356 принятия решения), тогда процесс компоновки отменяется для указанного узла (этап 357).

Если узел-предок не помечен как "грязный" (точка 356 принятия решения) после выполнения компоновки в указанном узле, тогда диспетчер 200 компоновки определяет, имеет ли указанный узел "грязного" потомка (точка 358 принятия решения). Диспетчер компоновки также определяет, имеет ли указанный узел "грязного" потомка, если сам указанный узел не был признан "грязным" в точке 352 принятия решения. В любом случае, если указанный узел не имеет "грязного" потомка (точка 358 принятия решения), тогда процесс компоновки завершается (этап 362). Если указанный узел имеет "грязного" потомка (точка 358 принятия решения), тогда следующий дочерний узел находится (этап 360) и компонуется (этап 364). После компоновки дочернего узла диспетчер 200 компоновки определяет, помечен ли предок как "грязный" (точка 366 принятия решения). Если так (точка 366 принятия решения), тогда процесс компоновки отменяется (этап 357). Если предок не помечен как "грязный" (точка 366 принятия решения), тогда диспетчер 200 компоновки определяет, является ли сам узел "грязным" (точка 367 принятия решения). Если сам узел является "грязным" (точка 367 принятия решения), тогда процесс компоновки выполняется для узла (этап 354), а другие этапы продолжают выполняемые процессы компоновки, как описано ранее. Если сам узел не является "грязным" (точка 367 принятия решения), тогда следующий дочерний узел обрабатывается, если существуют еще дочерние узлы (этап 368). Если больше не существует дочерних узлов (точка 368 принятия решения), тогда процесс циклически возвращается к обработке следующего узла-брата для текущего родителя в "грязном" поддереве (этап 352).

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

- Бит IsMeasureDirty: Чтобы помечать узел как "грязный" для измерения

- Бит IsOnPathToMeasureDirty: Чтобы помечать узел как имеющий "грязного" потомка для измерения

- Бит IsArrangeDirty: Чтобы помечать узел как "грязный" для размещения

- Бит IsOnPathToArrangeDirty: Чтобы помечать узел как имеющий "грязного" потомка для размещения

- Бит IsAncestorDirty: Чтобы помечать узел как имеющий "грязного" предка

- Бит IsOnStack: Чтобы помечать, компоновка (измерение или размещение) выполняется.

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

Псевдо-код LayoutManager::UpdateLayout

While (true)

{

If (the display area size changed, or the root has measureDirty or onPathToMeasureDirty flags set)

{

pRoot->Measure(display area size);

}

Else if (the root has the arrangeDirty or onPathToArrangeDirty flags set)

{

pRoot->Arrange(display area rectangle);

}

Else

{

If (there are SizeChanged events that need to be fired)

Fire SizeChanged events

If (the root does not require measuring or arranging (see above))

Fire LayoutUpdated events

}

Else

Break; (exit the while loop)

}

Псевдокод CUIElement::Measure

CUIElement::Measure(availableSize)

{

IsOnMeasureStack = true;

IsAncestorDirty = false;

while (true)

{

if (IsMeasureDirty || availableSize has changed)

{

MeasureInternal(availableSize);

If (IsAncestorDirty || IsLayoutSuspended)

Break;

IsOnMeasureDirtyPath = false;

}

Else if (IsOnMeasureDirtyPath)

{

IsOnMeasureDirtyPath = false;

Foreach (child in Children)

{

If (child->IsMeasureDirty || child->

IsOnMeasureDirtyPath)

{

child->Measure(child->

PreviousConstraint);

}

If (IsAncestorDirty)

{

IsOnMeasureDirtyPath = true;

goto Cleanup;

}

If (IsMeasureDirty)

{

Break; // выход цикла foreach

}

Else

Break; // выход цикла while

}

Cleanup:

IsOnMeasureStack = true;

}

Псевдо-код CUIElement::Arrange

CUIElement::Arrange(finalRect)

{

IsOnArrangeStack = true;

IsAncestorDirty = false;

while (true)

{

if (any node requires measure)

break; // Выход цикла while

if (IsArrangeDirty || finalRect has changed)

{

ArrangeInternal(availableSize);

If (IsAncestorDirty || IsLayoutSuspended)

Break;

IsOnArrangeDirtyPath = false;

}

Else if (IsOnArrangeDirtyPath)

{

IsOnArrangeDirtyPath = false;

Foreach (child in Children)

{

if (any element requires measure)

break; // выход цикла foreach

if (child->IsArrangeDirty || child->

IsOnArrangeDirtyPath)

{

child-> Arrange(GetArrangeRect());

}

if (IsAncestorDirty)

{

IsOnArrangeDirtyPath = true;

Break; // exit foreach loop

}

Else

Break; // выход цикла while

}

Cleanup:

IsOnArrangeStack = true;

}

Как отмечено выше в процедуре UpdateLayout, процесс измерения вызывается, если размер области отображения изменился, или корень имеет флаги IsMeasureDirty или onPathToMeasureDirty, установленные в значение "истина" (т.е. либо сам является "грязным", либо имеет "грязного" потомка). Иначе, если корень имеет установленные флаги IsArrangeDirty или IsOnPathToArrangeDirty, тогда вызывается процесс размещения.

Процессы измерения и размещения, показанные в примерных образцах кода, затем рекурсивно выполняют цикл по дереву узлов, которые подходят для определения того, измерять или размещать их вверх с предками или вниз с потомками в зависимости от оценки различных критериев, описанных здесь (и на фиг. 7).

Фигура 8 является блок-схемой 390 процесса, которая иллюстрирует один вариант осуществления этапов, включенных в процесс отмены процесса компоновки. Если указанный узел уже является "грязным" (точка 392 принятия решения), тогда процесс отмены компоновки завершается (этап 394). Если указанный узел еще не является "грязным" (точка 392 принятия решения), тогда указанный узел помечается как "грязный" (этап 396). Если указанный узел является предком узла, компонуемого в настоящее время (точка 398 принятия решения), тогда все узлы по пути от этого узла (не включая этот узел) до узла, компонуемого в настоящее время, помечаются как имеющие "грязного" предка (этап 400). Если этот узел не является предком узла, компонуемого в настоящее время (точка 398 принятия решения), тогда процесс отмены компоновки завершается (этап 402).

Некоторый примерный исходный код показан ниже, чтобы иллюстрировать процесс на фигуре 8 более подробно. В показанном примере процесс InvalidateMeasure выполняет проверку, чтобы увидеть, находится ли уже указанный узел в стеке (т.е. уже измеряется), и, если так, то процесс InvalidateMeasure завершается. Указанный узел помечается как "грязный", и затем узлы-предки помечаются как имеющие "грязного" потомка.

UIElement::InvalidateMeasure()

{

// Не помечать нас как "грязные", если мы уже измеряемся.

If (CurrentOnStack == this)

{

Return;

}

// Пометить себя как "грязный"

IsDirty = true;

//Пометить пути ко всем предкам

Ancestor = this.Parent;

While (Ancestor != NULL && Ancestor.OnPathToDirty == false)

{

Ancestor.OnPathToDirty = true;

Ancestor = Ancestor.Parent;

}

// Теперь, если мы находимся в стеке, тогда пометить от текущего в стеке до

// нас (но не включая нас) как имеющих "грязного" предка

If (IsOnStack)

{

Child = CurrentOnStack;

While (Child != NULL && Child != this)

{

Child.AncestoryDirty = true;

Child = Child.Parent;

}

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

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

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

Claims

1. Машиночитаемый носитель, имеющий машиноисполняемые инструкции для инструктирования компьютеру выполнять этапы способа управления обновлением компоновки элементов пользовательского интерфейса, содержащего этапы:
отслеживание "грязного" состояния элементов пользовательского интерфейса в дереве элементов пользовательского интерфейса, причем дерево содержит множество узлов, и "грязное" состояние функционирует так, чтобы позволить идентифицировать одно или более "грязных" поддеревьев упомянутых узлов;
идентификацию корневого узла для каждого из "грязных" поддеревьев, причем корневой узел является узлом, который не имеет непосредственного предка, который также является «грязным», при этом идентификация корневого узла для каждого из «грязных» поддеревьев выполняется посредством анализа «грязного» состояния и дополнительного состояния, ассоциированного с узлами в дереве, причем упомянутое дополнительное состояние включает в себя указатель, который указывает, имеет ли выбранный один из узлов «грязный» узел-потомок, причем упомянутое дополнительное состояние дополнительно включает в себя указатель, который указывает, имеет ли выбранный один из узлов «грязный» узел-предок; и
обновление затронутых частей дерева, начиная с корневого узла, который был идентифицирован для каждого из "грязных" поддеревьев, при этом этап обновления начинается с корневого узла, который был идентифицирован для каждого из «грязных» поддеревьев так, что обновления не выполняются над дочерними узлами в «грязных» поддеревьях, которые затем должны быть перезаписаны из-за обновлений, сделанных в родительских узлах.

2. Машиночитаемый носитель по п.1, в котором дополнительное состояние включает в себя указатель, который указывает, компонуется или нет в настоящее время выбранный один из узлов.

3. Машиночитаемый носитель по п.1, в котором "грязное" состояние включает в себя указатель, который указывает, является или нет выбранный один из узлов "грязным".

4. Машиночитаемый носитель по п.1, дополнительно имеющий машиноисполняемые инструкции, чтобы инструктировать компьютеру выполнять этапы, содержащие:
визуализацию элементов пользовательского интерфейса на устройстве вывода после обновления затронутых частей дерева элементов пользовательского интерфейса.

5. Способ управления обновлением компоновки элементов пользовательского интерфейса, содержащий этапы:
отслеживают "грязное" состояние элементов пользовательского интерфейса в дереве элементов пользовательского интерфейса, причем дерево содержит множество узлов, и "грязное" состояние функционирует так, чтобы позволить идентифицировать одно или более "грязных" поддеревьев упомянутых узлов;
идентифицируют корневой узел для каждого из "грязных" поддеревьев, причем корневой узел является узлом, который не имеет непосредственного предка, который также является «грязным», при этом идентификация корневого узла для каждого из «грязных» поддеревьев выполняется посредством анализа «грязного» состояния и дополнительного состояния, ассоциированного с узлами в дереве, причем упомянутое дополнительное состояние включает в себя указатель, который указывает, имеет ли выбранный один из узлов «грязный» узел-потомок, причем упомянутое дополнительное состояние дополнительно включает в себя указатель, который указывает, имеет ли выбранный один из узлов «грязный» узел-предок; и
отменяют процесс компоновки, который выполняется в настоящее время над дочерними узлами, если он есть, в «грязных» поддеревьях; и
обновляют затронутые части дерева, начиная с корневого узла, который был идентифицирован для каждого из "грязных" поддеревьев, при этом этап обновления начинается с корневого узла, который был идентифицирован для каждого из «грязных» поддеревьев так, что обновления не выполняются над дочерними узлами в «грязных» поддеревьях, которые затем должны быть перезаписаны из-за обновлений, сделанных в родительских узлах.

6. Способ по п.5, в котором дополнительное состояние включает в себя указатель, который указывает, компонуется или нет в настоящее время выбранный один из узлов.

7. Способ по п.5, в котором "грязное" состояние включает в себя указатель, который указывает, является или нет выбранный один из узлов "грязным".

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

9. Способ управления обновлением компоновки элементов пользовательского интерфейса, содержащий этапы:
отслеживают "грязное" состояние элементов пользовательского интерфейса в дереве элементов пользовательского интерфейса, причем дерево содержит множество узлов, и "грязное" состояние функционирует так, чтобы позволить идентифицировать одно или более "грязных" поддеревьев упомянутых узлов;
идентифицируют корневой узел для каждого из "грязных" поддеревьев, причем корневой узел является узлом, который не имеет непосредственного предка, который также является «грязным», при этом идентификация корневого узла для каждого из «грязных» поддеревьев выполняется посредством анализа «грязного» состояния и дополнительного состояния, ассоциированного с узлами в дереве, причем упомянутое дополнительное состояние включает в себя указатель, который указывает, имеет ли выбранный один из узлов «грязный» узел-потомок, причем упомянутое дополнительное состояние дополнительно включает в себя указатель, который указывает, имеет ли выбранный один из узлов «грязный» узел-предок; и
обновляют затронутые части дерева, начиная с корневого узла, который был идентифицирован для каждого из "грязных" поддеревьев, при этом этап обновления начинается с корневого узла, который был идентифицирован для каждого из «грязных» поддеревьев так, что обновления не выполняются над дочерними узлами в «грязных» поддеревьях, которые затем должны быть перезаписаны из-за обновлений, сделанных в родительских узлах.

10. Способ по п.9, в котором дополнительное состояние включает в себя указатель, который указывает, компонуется или нет в настоящее время выбранный один из узлов.

11. Способ по п.9, в котором "грязное" состояние включает в себя указатель, который указывает, является или нет выбранный один из узлов "грязным".

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