Comment 53 for bug 156550

(In reply to comment #15)
> Well, xscreensaver doesn't work that way. If it worked that
> way, I wouldn't have to call Xinerama functions at all. A
> different screen saver is run on each *monitor*. It does
> not run a single saver that spans monitors and is then
> clipped. To accomplish this, xscreensaver needs to know
> where the *glass* is.
>
> You seem to be telling me, "you're no longer allowed to know
> that." I don't find that a particularly satisfying answer.

You can know it as well as the X server knows it. The Xinerama geometry is
every piece of glass we're displaying to, which may include even glass that
we're not sure is physically present. If you want to distinguish between
connected/disconnected/unknown, XRRGetOutputInfo() will tell you.

> (The reason xscreensaver does it this way is simple: with
> screen savers, spanning monitor looks like ass with all but
> a tiny handful of few savers. That's why Apple does it this
> was as well.)

Then you have your choice of what kind of ass to look like.

For the (sane) case where no outputs overlap you can run one xscreensaver window
each. That's not changed. For the case where they do overlap, you can do any of:

a) Run on the smallest of the overlapped outputs
b) Run on each of the outputs
c) Run on the whole canvas

a) is what you're doing, it seems, and this doesn't blank the whole screen. b)
and c) will both look weird, but c) will probably look less wrong; b) will have
weird seams at xscreensaver window edges, whereas c) will just have some of the
screensaver potentially not visible.

This isn't an answer I'm happy with either. I don't like the display model in
X, but it's a bit difficult to change at this point. Technically,
implementation-wise, it's easy, but users are noisy creatures and think it's a
feature.

> > You might as an optimization create just one window per
> > output, if they're all completely disjoint, as that will
> > save some memory and probably perform better.
>
> What do you mean by "output"?

Agh terminology disaster. The RANDR model is: an X protocol screen maps to one
GPU (or more, but that's not finished yet). One GPU may have one or more CRTCs.
 A CRTC is really just a region of pixels that's being scanned out. Each CRTC
may have one or more outputs connected to it. An output is a physical
presentation device. The Xinerama geometry is a mirror of the CRTC geometry.
So in the above, I should have said "one window per CRTC".

(In the above where I say "the Xinerama geometry is every piece of glass we're
displaying to", I'm still not lying: a CRTC doesn't exist in the geometry if you
haven't enabled it, and you can't do that unless there's at least one output
attached to it.)

Now that I think about it I don't mean "all disjoint". I mean "all disjoint
after eliminating identical rectangles", since you could (theoretically) have a
geometry like:

1: 800x600+0+0
2: 800x600+0+0
3: 800x600+800+0

Here 1 and 2 are cloned but 3 is immediately right of both of them, so 1 and 2
should be treated as a single xscreensaver view.

> > I wonder how OSX handles this. I suspect they just don't
> > allow any overlap cases besides exact cloning.
>
> Correct. If you're not cloning, then the "Monitor
> Arrangement" preference panel lets you drag the rectangles
> representing every attached monitor around. Edges are
> constrained to at least partially touch (on top, bottom,
> left or right), and rectangles cannot overlap.
>
> However, screen savers are run "full screen" on each
> *monitor*. With screen savers, placement of monitors and
> size of the virtual desktop canvas do not come into play at
> all.

My kingdom for a real window system.