Re: Additional issues to address for the constraints_experiments branch?



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

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.

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.

Thanks,
Elijah



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]