Created attachment 13878 [details] [review]
The proposed patch

Created attachment 13879 [details] [review]
The proposed patch

Hi Adi:

Thanks for the patch.

I see that you are doing your post-processing inline, that is, in the
same thread as the rest of the zoom region update.  Given the
complexity of the smoothing code I suggest that it should go into an
idle handler, as suggested in the comment in zoom-region.c:

  /**
   * ADI: This is where your image smoothing code
   * hooks into the magnifier.  This routine can call others which
   * post-process the GdkPixbuf before rendering to the screen.
   *
   * We can make this a two-stage process also, whereby the
post-process code
   * is only called in a lower-priority idle handler, and queues repaints
   * when it is done.
   **/

I will apply the patch and see what the performance impact is like,
but I expect we may need to change the code to use an idle handler
before checking the changes into CVS.

-Bill

I think you are right.

In addition I want to mention a crash that appears in
zoom_region_update function, at line 1912 (with my patch), in some
cases, and wich I suspect to be caused by the update mechanism. BUT I
am not really sure. I really hope that you could tell me if I am right
or not. If NOT, I would really apreciate some help, because I am
running out of ideas.

Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME
bug list :)

Apologies for spam; marking as AP3 so it appears in the right place on
our buglist.

Adding the PATCH keyword.

removing PATCH keyword since existing patch is not suitable for
application.

note the dependency on 104729; we can't apply compute-intensive
smoothing algorithms until we put the architecture in place for doing
the smoothing in an idle handler of lower priority than the usual
'update' idle handler.

Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs.
 Filter on "SUN A11Y SPAM" to ignore.

Adi, could you update this patch to the current gnome-mag code?

Other thing, where I can find text that explaim the algorithm that you are using. I think that it's important to us have a theoretical reference to it.

Unfortunately Adi Dascal is no longer working on Gnopernicus (or at BAUM).  Perhaps someone else at BAUM (Remus?) might be able to work on this?

I applied the patch here and find that it's works better when the Font Rendering, in the Font Preferences, is setted to Monochrone. I think that this is an important information to other assistive tecnologies developers, like the ones fromm gnopernicus and orca. I don't know if it's important to put this information somewhere else.

Just FWY, this patch appear to use a Sobel mask to detect edges and then make triangles joining the pixels that make the edge.

I percepted that the letters smoothed by this sometime appear incomplete. Someone have this same issue? Any guess where is the source of this behavior?

Adi patch is intended for font smoothing, isn't is? Modifications in how applications render fonts must be made or in how the code works. I think that the  first one is simpler. This can be a GNOME goal?

If you set in Font Preferences the Font Rendering option to Monochrome some applications continue to use anti-aliasing in the rendering. I notice this in Epiphany, Abiword and Firefox. Probably more applications present this behavior.

Maybe we can modify the algorithm a little to make it work better with anti-aliased fonts, but when you add Subpixel smoothing the things get more difficult.

Other way to achieve better font smooth is throw cooperation with Xserver, but this is not a short-term solution for the problem IMO.

Comments about this are welcome, since font smooth is something very appreciate from some visually impaired users.

gnome-mag development has been stalled and it has been replaced by gnome-shell
mag [1]. Maintainers don't have future development plan so i am closing all the bugs as WONTFIX.

[1] https://mail.gnome.org/archives/gnome-bugsquad/2011-October/msg00001.html