Re: Additional issues to address for the constraints_experiments branch?

[Rob Adams <readams readams net>]

On Mon, 2005-11-14 at 16:50 -0700, Elijah Newren wrote:

> Oops, that part of that optimization comment is also true in the code;
> I totally forgot about XRandR.  I'll have to look into that (and maybe
> bug 106849 at the same time...).  Quick question, though--shouldn't
> the strut list also change upon XRandR if any of the struts would
> become offscreen (or does that already happen)?  I guess it shouldn't
> hurt to not have the struts list updated in such a case (and my code
> tries to handle some various weirdness with struts like that) but it'd
> seem cleaner.

I'm not sure how you implemented it, but I'd probably just have a
"regions_invalid" bit that you can set quickly, and only actually update
the regions list the first time you need them, then queue a "reconstrain
everything" that's handled in an idle handler.  Then you can have a
quick invalidate_constraint_region_cache call that runs in O(1) in
response to the configure requests.  Then you can feel good about
invalidating them even in cases where you're likely to get a whole
flurry of requests that might end up invalidating them, such as a screen
resize.

> Also note that in regards to that optimization comment, I did
> eventually implement option (4) as it allowed for various code
> cleanups anyway and became natural when trying to figure out how to
> fix the remaining issues in bug 144126.  So ignore that item of that
> comment (I'll clean it up in a little while), but the other ones are
> still fine.  I think I'll point to your email as well since quad-trees
> hadn't occurred to me.

I suspect that most of the crazy optimizations I listed would actually
slow it down for any real cases.  You'd only want that if screen
geometry became extremely complex.  Quad-trees are things you normally
see in 2D collision-detection code where you need to compute highly
complex collision geometry, and the equivalent Oct-trees for 3D
collisions.

-Rob