[prev in list] [next in list] [prev in thread] [next in thread]
List: gtk-devel
Subject: Re: No module anymore & perfect zoom feature
From: Emmanuele Bassi <ebassi () gmail ! com>
Date: 2018-03-01 15:32:37
Message-ID: CALnHYQEMkD5Yd9GwBsFeEtMSrC6w2yVTi-M4OKqTECvtYnL_GA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Thu, 1 Mar 2018 at 20:48, Samuel Thibault <samuel.thibault@ens-lyon.org>
wrote:
> Hello,
>
> Emmanuele Bassi, on jeu. 01 mars 2018 14:42:27 +0700, wrote:
> > On 26 February 2018 at 17:49, Samuel Thibault
> > <samuel.thibault@ens-lyon.org> wrote:
> > > Hello,
> > >
> > > So, I also saw the removal of generic modules.
> > >
> > > Unfortunately we currently need it for implementing perfect zoom
> feature
> > > :)
> >
> > I don't know what a "perfect zoom feature" is —
>
> Please compare the two attached examples :)
>
> zoom-gimp.png is the kind of zoom you can get with state-of-the-art
> zooming heuristics. zoom-perfect.png is simply obtained by getting gtk
> to redraw the window into a bigger pixmap.
>
> > but zooming on a window should be part of the display server.
>
> The display server can not invent information, at best it could
> achieve the zoom-gimp.png result, which is really not enough for
> visually-impaired people. Here I have only magnified a couple of times,
> people quite often request for 10x-30x magnification.
>
The compositor can say to the toolkit to render with a different scaling
factor - we do that for hidpi so toolkits already know how to deal with it.
No need to do vector rendering; after all, things are rendered to pixmaps
anyway, not using vector based API.
> Also, the control on zooming should really not implemented in the
> server. Usually you'll also want color inversion or mangling, adding
> position hints etc. I don't think freedesktop people will be happy to
> see that added to the display server, so an external solution is needed,
> currently implemented in Compiz (but lacking access to re-rendering on a
> bigger pixmap).
>
Don't really agree at all. Considering that Compiz is mostly dead, and that
the current GNOME Shell already has logic for zoom, color inversion, and
other effects, it's perfectly capable of dealing with these requirements.
Targeting an obsolete graphics stack is not going to get you anywhere -
especially for a new major version of the toolkit, where we don't have
legacy code.
Ciao,
Emmanuele.
> > Having said that, we do have a magnifier inside GTK, used by the
> > Inspector. We could make that feature public, and improve it.
>
> Interesting. Having mentioned adding the feature to AT-SPI, I'm
> however interested in putting the interface there, so that not only GTK
> application can benefit from it, but also Qt, etc. and GTK can just plug
> its support into AT-SPI.
>
> > We definitely do not want to let people inject code into running
> applications.
>
> Ok :)
>
> Samuel
>
--
https://www.bassi.io
[@] ebassi [@gmail.com]
[Attachment #5 (text/html)]
<div><br><div class="gmail_quote"><div dir="auto">On Thu, 1 Mar 2018 at 20:48, Samuel \
Thibault <<a href="mailto:samuel.thibault@ens-lyon.org">samuel.thibault@ens-lyon.org</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br> <br>
Emmanuele Bassi, on jeu. 01 mars 2018 14:42:27 +0700, wrote:<br>
> On 26 February 2018 at 17:49, Samuel Thibault<br>
> <<a href="mailto:samuel.thibault@ens-lyon.org" \
target="_blank">samuel.thibault@ens-lyon.org</a>> wrote:<br> > > Hello,<br>
> ><br>
> > So, I also saw the removal of generic modules.<br>
> ><br>
> > Unfortunately we currently need it for implementing perfect zoom \
feature<br> > > :)<br>
><br>
> I don't know what a "perfect zoom feature" is —<br>
<br>
Please compare the two attached examples :)<br>
<br>
zoom-gimp.png is the kind of zoom you can get with state-of-the-art<br>
zooming heuristics. zoom-perfect.png is simply obtained by getting gtk<br>
to redraw the window into a bigger pixmap.<br>
<br>
> but zooming on a window should be part of the display server.<br>
<br>
The display server can not invent information, at best it could<br>
achieve the zoom-gimp.png result, which is really not enough for<br>
visually-impaired people. Here I have only magnified a couple of times,<br>
people quite often request for 10x-30x magnification.<br>
</blockquote><div dir="auto"><br></div><div dir="auto">The compositor can say to the \
toolkit to render with a different scaling factor - we do that for hidpi so toolkits \
already know how to deal with it. No need to do vector rendering; after all, things \
are rendered to pixmaps anyway, not using vector based API.</div><div \
dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><br> Also, the control on zooming \
should really not implemented in the<br> server. Usually you'll also want color \
inversion or mangling, adding<br> position hints etc. I don't think freedesktop \
people will be happy to<br> see that added to the display server, so an external \
solution is needed,<br> currently implemented in Compiz (but lacking access to \
re-rendering on a<br> bigger pixmap).<br>
</blockquote><div dir="auto"><br></div><div dir="auto">Don't really agree at all. \
Considering that Compiz is mostly dead, and that the current GNOME Shell already has \
logic for zoom, color inversion, and other effects, it's perfectly capable of dealing \
with these requirements. Targeting an obsolete graphics stack is not going to get you \
anywhere - especially for a new major version of the toolkit, where we don't have \
legacy code.</div><div dir="auto"><br></div><div dir="auto">Ciao,</div><div \
dir="auto"> Emmanuele.</div><div dir="auto"><br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><br> > Having said that, we do have a magnifier inside \
GTK, used by the<br> > Inspector. We could make that feature public, and improve \
it.<br> <br>
Interesting. Having mentioned adding the feature to AT-SPI, I'm<br>
however interested in putting the interface there, so that not only GTK<br>
application can benefit from it, but also Qt, etc. and GTK can just plug<br>
its support into AT-SPI.<br>
<br>
> We definitely do not want to let people inject code into running \
applications.<br> <br>
Ok :)<br>
<br>
Samuel<br>
</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" \
data-smartmail="gmail_signature"><a href="https://www.bassi.io" \
target="_blank">https://www.bassi.io</a><br>[@] ebassi [@<a href="http://gmail.com" \
target="_blank">gmail.com</a>]</div>
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic