For consistency and backwards compat, it would be best to expose this functionality as a gnome-mag server (see gnome-mag IDL). IOW, metacity would call BAS and advertise itself as a provider of GNOME::Magnifier:1.0 or whatever.

Do we need to support "multiple zoomers"?  I suggest that the API should allow it, but that we can live without it in the short term (i.e. requesting more than one 'zoom region' should fail detectably).  From the POV of internal API, we need some kind of pluggability that allows renderop to plug into the WM/CM (probably on a per-toplevel-window basis (or per-window-node basis?))  Since the output of the pixop may be bigger than the input, some API will need to be provided which tells the WM what policy to use when placing the resulting output on the physically composited "screen".  

So for instance, a bilinear-resampling-scaling pixop that does 2x magnification could be plugged in at the root window of a display, so that the entire window stack gets resized/resampled in the last compositing step; at that point the WM will be handed a pixmap too large to fit the current screen, so some kind of viewport-moving API would be required.  Either the plugin could use internal API to tell the WM/CM what subregion to render to the physical screen, or the WM/CM could implement GNOME:Magnifier:ZoomRegion::setROI() directly, so that clients could tell the WM where to "pan" to.

A similar scenario illustrating how the plugins might be "per toplevel window" - you might want to use the rescaling plugin only on the currently active toplevel, leaving the other windows at normal size.  Or you could decrease the contrast on the non-active toplevels, for cognitive impairments (making the surrounding screen contents less distracting), etc.  You can probably think of eye-candy sorts of things that could be achieved in the same way, by putting some pluggable filters in the chain for a particular toplevel window, or for the "active window".  etc.

This may be worth adding to EWMH.  Clients could set properties asking the window manager to turn their window into a zoom region.  We could then have the actual implementation of the gnome-mag server be in a client, with only the actual window scaling needing to be handled by the compositing manager.  All the UI and such would be in a client.

Rob, that's how it works now (more or less); the logic for "what to display" is in the client, and the magnification service is just a pixel repainter (with client control over the viewports and source/target regions, of course).

BTW by "how it works" I mean "how gnome-mag works/how the gnome-mag API was intended to be used".

re-reading; it's not the "client" in the sense of the window manager client that's calling the shots here, it's a third-party, the "assistive technology client" which is sending messages/service requests to a magnification service.  I guess the magnifier could potentially be setting WM hints on other applications' windows, but that seems rather invasive to me, isn't only the client app or WM supposed to go poking around in window props?

The window that holds the magnified region could set window properties on itself to instruct the compositing/window manager that "This window should contain the contents of the following desktop region, scaled to fit the window."  The magnifier could use EWMH mechanisms to query for window manager support for doing that, then fall back to using the old slow way if unavailable.

This has the advantage that 1) it uses the existing system to communicate with the WM, 2) it could be standardized in the future so that the magnifier could be used on any desktop with any compliant WM or compositor.

If KDE is using dbus I think further unnatural acts with X properties would be a little masochistic, for things that aren't naturally/directly related to EWMH/window-management kind of stuff.

I'd rather avoid adding bonobo as a dep though, for a variety of reasons that don't need rehashing again. We could easily make a bonobo proxy process that implements the IDL, and have it talk to metacity via whatever saner IPC mechanism is practical and easy. That way gnome-mag can remain unmodified.

Moving to compositor component.  

See the following two documents as possible designs:
http://www.alphaworks.ibm.com/technologies/mcm/mcm.pdf
http://www.alphaworks.ibm.com/technologies/mcm/gscope.pdf

George:  404 on both those URIs.

Backup to http://www.alphaworks.ibm.com/technologies/mcm/
For an explanation, please see http://lists.freestandards.org/pipermail/accessibility/2006-February/001494.html

George, your mcm URL doesn't work for me, but this one does:
 http://www.alphaworks.ibm.com/tech/mcm

Note that current metacity HEAD does have a simple magnifier. If you start metacity with the environment variable USE_MAGNIFIER=1, it should show up.

I am not closing this bug though, since it is not yet a full solution.

This is something we need to ask Iain about now. (Iain, sorry to add a ton of spam to your inbox today.)

bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all
old feature requests in Bugzilla which have not seen updates for many years.

If you still use metacity and if you are still requesting this feature in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/

Thank you for reporting this issue and we are sorry it could not be implemented.