Re: Additional issues to address for the constraints_experiments branch?

[Elijah Newren <newren gmail com>]

On 11/14/05, Rob Adams <readams readams net> wrote:
> 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.

This is basically how workareas and strut lists are updated (in both
HEAD and constraints_experiments; that part of the code was mostly
left alone), and since I had made the assumption that regions change
only when struts change, I actually have the region computation being
done inside workspace.c:ensure_work_areas_validated().  It still seems
like a sane location anyway, since the workarea (meaning the rectangle
to which maximized windows are set) would also need to be updated when
the screen size changes from XRandR stuff--right?

> 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.

Well, that whole comment is somewhat about pathological cases, so it
may be worth mentioning, even though I don't think any of those
optimizations will ever be needed.

Cheers,
Elijah