An empirical study of constraint usage in graphical applications

Abstract

One-way constraints have been widely incorporated in research toolkits for constructing graphical applications. However, although a number of studies have examined the performance of these toolkits' constraint satisfaction algorithms, there have not been any empirical studies that have examined how programmers use constraints in actual applications. This paper reports the results of a study intended to address these matters. Seven graphical applications were chosen for their diversity and profiling information was gathered about their use of constraints, The data reveal that constraint networks tend to be modular, that is, divided into a number c~fsmall, independent sets of constraints rather than one mono] ithic set of constraints. This finding suggests that constraint satisfaction algorithms should be able to resatisfy constraints rapidly after a change to one or more variables. It also suggests that debugging constraints should not be unduly burdensome on a programmer since the number of constraints that must be examined to find the source of an error is not terriblly large. Overall, the results of this study should provide a repository of data that will be useful in directing future research on optimizing constraint solvers and developing effective debugging techniques.

Lessons learned about one-way, dataflow constraints in the Garnet and Amulet graphical toolkits

“…This result might seem somewhat anomalous, since we might expect that large applications should have large chains of constraints, which would consume a considerable amount of constraint satisfaction time. However, an earlier study that we conducted of Amulet applications revealed that constraint networks tend to be modular; that is, they are divided into a number of small, independent sets of constraints rather than one monolithic set of constraints [Vander Zanden and Venckus 1996]. Since any given interactive transaction, such as moving an object on the screen, typically only changes a small number of variables, and since constraint networks tend to be small and modular, only a few constraints will have to be reevaluated on any given interactive transaction, no matter how big the application.…”

“…However, an empirical study of Amulet applications revealed that 60-80% of variables have fewer than 10 constraints that depend on them, either directly or indirectly [Vander Zanden and Venckus 1996]. Further, almost no variable was depended on by more than 100 constraints.…”

User Interfaces for On-Line Diagram Recognition

“…For example, a constraint [28] can cause one node to move whenever the user moves another node. The Electronic Cocktail Napkin displays constraints as superimposed drawing annotations, analogous to dimensioning annotations in mechanical engineering drawings.…”

Using model dataflow graphs to reduce the storage requirements of constraints

“…Unfortunately, studies of at least two of these toolkits, Garnet and Amulet, show that constraints can exact a significant storage toll on programs [Vander Zanden and Venckus 1996]. Ultimately, the execution times of programs managing a large number of constrained objects may suffer, since virtual memory must be accessed to meet their storage demands.…”

“…As shown by Table I, the edges in these graphs can consume a considerable amount of storage. One study has shown that dataflow graphs account for up to 50% of the storage required by constraint systems [Vander Zanden and Venckus 1996]. Reducing [Myers et al 1990] 16 Amulet [Myers et al 1997] 24 Eval/vite [Hudsen 1990] 24 Rendezvous [Hill 1993] 16 Fig.…”