Re: Additional issues to address for the constraints_experiments branch?

[Rob Adams <readams readams net>]

OK I think that's pretty likely to work in most, if not all, situations
we care about.  You could almost certainly do your tessellation in time
linear in the number of struts with an appropriately-sorted list of
struts, but as you say n is probably not more than 8 generally so
probably not a huge deal, and it'd have to be 100-200 or so before it
became an issue.  And if we ever get that many regions, there's a lot
we'd want to change about how this is working, such as using maybe
quad-trees to do region intersections, or various clever data structures
out of databases to do cartesian "nearest" operations.

One issue though is in a comment about optimization (but perhaps not the
code) you say that the xineramas and screen size can't change; this
isn't strictly true.  With XRandR both the number of xineramas and the
screen size could potentially change.  With the nvidia driver, you can
actually do both using just the "Screen Resolution" control panel applet
that ships with GNOME.  So if you cache the region list, be sure to
invalidate it on RandR updates (iirc these show up as configure requests
on the root window) as well as on strut changes.

-Rob