X Zoom Extension: Ideas and Suggestions!

[Jim Gettys]

The problem is that at this level of the stack (from application, to
toolkit, to graphics library, to commands, to pixels), we're really at
too low a level to know enough about what the application needs.

Even most operations in render are pixel images (e.g. glyphs); about the
only operation you might scale successfully are traps.

Keith and I have been thinking over the issues presented by projectors
and even how one might rotate windows.  Even an affine transform is
insufficient.

A possible solution that leaves things working by dumb applications, but
allows them (and/or toolkits) to do better would be a signaling system,
in which we might inform clients (toolkits) things like: "If you render
into this pixmap over here, which has the following relationship to you
original window, you can get better (higher quality) results".

I've been thinking along these lines for rotated windows, and there
there may be (particularly with GTK moving to using Cairo for its
rendering) significant quality advantage to ask the application to
repaint once rotation has ceased at the final rotation.  Given Cairo as
under pinnings that should be do-able.

So for a magnifier application, we could just give the application a
hint: here's this other pixmap, scaled in relative to the original, and
have it repaint.

For dumb applications, you'd just get cheezy pixel level applications.
					- Jim


On Thu, 2005-04-28 at 20:08 +0200, Gian Filippo Pinzari wrote:
> Alan Coopersmith wrote:
> > That was our initial thought several years ago when we first started
> > working with the GNOME Accessibility project on screen magnification,
> > but we ended up dropping the idea, because they wanted far more control
> > over the magnified output than a simple server side magnifier could
> > provide.   For some cases, it's probably good enough, and clearly more
> > could be made more efficient, but those weren't the cases we had to
> > tackle.
> 
> I understand your points and fully agree. Anyway they seem to me two
> different problems. The point of extensions like RANDR, I think, is
> to make advanced features easily accessible to all clients (built-in?),
> even if these features could be implemented in clients. If we accept
> the idea that to implement magnification we have to grab the pixels
> from the frame-buffer and put it again, magnified, on the server, we
> are loosing most of the advantages of having a high-level protocol
> to draw on the display. My take of X windowing, instead, is that we
> should just go on the "View" menu of the X server and select "Increase
> font size", as we do with Firefox ;-).
> 
> I'm perfectly aware that there are important performance implications
> (an X server is very low in the stack) and that handling something
> like a "X11 CSS" is not like handling HTML, but maybe it's a possibi-
> lity. Extensions like DAMAGE appear to me like a renounce. It's like
> saying: "we can't implement all the things that could be useful in the
> X server, so let's make applications deal directly with the pixels
> on the frame-buffer"...
> 
> /Gian Filippo.
> 
> P.S.: I love the DAMAGE extension and understand the whole lot of
> possibilities it opens to developers ;-).
> 
> 
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg