Re: No module anymore & perfect zoom feature

--===============7576772994139635722==
Content-Type: multipart/alternative; boundary="94eb2c117a6868d1d205665b9276"

--94eb2c117a6868d1d205665b9276
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 1 Mar 2018 at 20:48, Samuel Thibault <[email protected]>
wrote:

> Hello,
>
> Emmanuele Bassi, on jeu. 01 mars 2018 14:42:27 +0700, wrote:
> > On 26 February 2018 at 17:49, Samuel Thibault
> > <[email protected]> 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 =E2=80=94
>
> 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=E2=80=99t 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=E2=80=99s perfectly capable of dealing with these require=
ments.
Targeting an obsolete graphics stack is not going to get you anywhere -
especially for a new major version of the toolkit, where we don=E2=80=99t h=
ave
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
>
--=20
https://www.bassi.io
[@] ebassi [@gmail.com]

--94eb2c117a6868d1d205665b9276
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div><br><div class=3D"gmail_quote"><div dir=3D"auto">On Thu, 1 Mar 2018 at=
 20:48, Samuel Thibault &lt;<a href=3D"mailto:[email protected]"=
>[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"=
gmail_quote" style=3D"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>
&gt; On 26 February 2018 at 17:49, Samuel Thibault<br>
&gt; &lt;<a href=3D"mailto:[email protected]" target=3D"_blank">=
[email protected]</a>&gt; wrote:<br>
&gt; &gt; Hello,<br>
&gt; &gt;<br>
&gt; &gt; So, I also saw the removal of generic modules.<br>
&gt; &gt;<br>
&gt; &gt; Unfortunately we currently need it for implementing perfect zoom =
feature<br>
&gt; &gt; :)<br>
&gt;<br>
&gt; I don&#39;t know what a &quot;perfect zoom feature&quot; is =E2=80=94<=
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>
&gt; 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=3D"auto"><br></div><div dir=3D"auto">The compositor c=
an say to the toolkit to render with a different scaling factor - we do tha=
t for hidpi so toolkits already know how to deal with it. No need to do vec=
tor rendering; after all, things are rendered to pixmaps anyway, not using =
vector based API.</div><div dir=3D"auto"><br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><br>
Also, the control on zooming should really not implemented in the<br>
server. Usually you&#39;ll also want color inversion or mangling, adding<br=
>
position hints etc. I don&#39;t think freedesktop people will be happy to<b=
r>
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=3D"auto"><br></div><div dir=3D"auto">Don=E2=80=99t re=
ally agree at all. Considering that Compiz is mostly dead, and that the cur=
rent GNOME Shell already has logic for zoom, color inversion, and other eff=
ects, it=E2=80=99s perfectly capable of dealing with these requirements. Ta=
rgeting an obsolete graphics stack is not going to get you anywhere - espec=
ially for a new major version of the toolkit, where we don=E2=80=99t have l=
egacy code.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Ciao,</div><=
div dir=3D"auto">=C2=A0Emmanuele.</div><div dir=3D"auto"><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><br>
&gt; Having said that, we do have a magnifier inside GTK, used by the<br>
&gt; Inspector. We could make that feature public, and improve it.<br>
<br>
Interesting.=C2=A0 Having mentioned adding the feature to AT-SPI, I&#39;m<b=
r>
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>
&gt; We definitely do not want to let people inject code into running appli=
cations.<br>
<br>
Ok :)<br>
<br>
Samuel<br>
</blockquote></div></div>-- <br><div dir=3D"ltr" class=3D"gmail_signature" =
data-smartmail=3D"gmail_signature"><a href=3D"https://www.bassi.io" target=
=3D"_blank">https://www.bassi.io</a><br>[@] ebassi [@<a href=3D"http://gmai=
l.com" target=3D"_blank">gmail.com</a>]</div>

--94eb2c117a6868d1d205665b9276--

--===============7576772994139635722==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
gnome-accessibility-devel mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel

--===============7576772994139635722==--