Re: Proposal: enable accessibility by default for GNOME
- From: Willie Walker <William Walker Sun COM>
- To: Mark Doffman <mark doffman codethink co uk>
- Cc: desktop-devel-list gnome org
- Subject: Re: Proposal: enable accessibility by default for GNOME
- Date: Thu, 31 Jul 2008 10:57:42 -0400
Thanks for the numbers Mark! Numbers speak a lot louder than blanket
statements, IMO, and you've always been awesome about giving numbers.
:-) I ran some tests on my Ubuntu Intrepid with GNOME 2.23.5 machine as
well.
1) As you mention, the at-spi-registryd will be automatically started by
gnome-session. The impact is data memory 550k and code size 40k with 0%
CPU as your numbers show. This seems to be on the order of the geyes
applet (900k/24k - DATA/CODE). Compare that to an xterm, which is at
4.2m/304k.
2) Again, as you mention, all GTK+ applications will load the
accessibility modules, adding what seems to be 150k of odd data. For
what looks like the smallest GTK+ app known to man (the test program you
provide), this accounts for an increase of 1%.
3) To test for the extra overhead of creating ATK/GAIL peers for each
GTK+ object, I ran the following test twice, once with a11y enabled and
once w/o a11y enabled, both on a fresh boot/login:
a) Run gtk-demo
b) Run top to monitor the the CODE and DATA of the gtk-demo process
c) Open and then close each of the demos in gtk-demo
This test causes many many widgets to be created and thus exercises the
ATK/GAIL mechanism heavily. The results are *not* promising. :-(
Without a11y enabled, I see gtk-demo grow from 4.2m/140k to 11m/140k.
With a11y enabled, I see gtk-demo grow from 4.2m/140k to 27m/140k. Ouch
- more than double. This is very unexpected and I'm not sure what's
going on. On the positive front, the at-spi-registryd doesn't grow.
4) The bonobo-activation-server is automatically started on my machine,
but that happens regardless of whether a11y is enabled or not. I'm not
sure who is running it, but it accounts for 32m/84k.
In any case, the results of #3 above make alarms go off, even for an
accessibility pundit such as myself. This will require some more
investigation.
Will
Mark Doffman wrote:
Hi everyone,
Rob Taylor wrote:
Hmm, my take here is that the current AT-SPI is possibly a little too
heavy to enable by default. I'd suggest we look at enabling a11y by
default when the new AT-SPI DBus is ready (2.26 at current estimations)
I'll take my best guess about what happens when a11y is turned on:
1. The atspi registry daemon needs to be running.
'top' has the data memory usage at 550kb and the code size at 40kb. The
cpu utilization is exactly zero.
2. All gtk applications are going to load accessibility modules.
I'm not sure which modules are going to be loaded. I would say libgail
and libatk-bridge (including libspi). Perhaps not gail, isn't it now
included in gtk? Are liborbit and libbonobo loaded for other reasons on
gtk_init?
So the test program:
int main(int argc, char* argv[])
{
gtk_init(&argc, &argv);
gtk_main();
}
It uses 15464kb virtual memory and 596kb of data when accessibility is
turned on.
When accessibility is turned off it uses 13660kb of total virtual memory
and 456kb of data.
So there is 150kb odd of data initializing the atk-bridge and libspi.
3. Accessible objects are created for gtk widgets / other UI elements.
Finding how an ATK object is created feels very much like jumping down a
rabbit hole. In the end though Gail objects and Bonobo servants are only
created on-demand. This means that there will be very little additional
memory usage if accessibility is turned on but not accessed.
This is the important part really. Bonobo servants might be very large,
and this, I think, is where ORBit/Bonobo gets its reputation for being
heavy. However, if a11y goes unused there shouldn't be any created.
I've cc'd Mark Doffman for his imput as he's probably got the most
experience profiling current AT-SPI behaviour.
Rob
Willie Walker wrote:
The way accessibility support works is that GTK+ loads accessibility
modules (gail and atk-bridge) if it detects that accessibility
support is enabled.
If accessibility support is not enabled when an application starts, I
don't believe there is a way to indicate to a running GTK+
application to go ahead and load the accessibility modules
retroactively. As such, one needs to quit running applications and
restart them in order for changes to the accessibility setting to
take effect.
The current user experience is very bad and kind of a Catch 22
situation: in order to enable accessibility, they often need to use
assisitve technologies. In order to use assisitve technologies, they
often need accessibility enabled. So, what we do now is tell users
to find some way to enable accessibility for their session, then log
out and log back in. It's really embarrassing as far as I'm concerned.
I'll see if we can dig up some metrics on the costs of enabling a11y.
If anyone has good suggestions for how to do this and how to get
numbers that people will trust, I'd like to hear them. :-) Even if
the numbers are not favorable, however, I think I'd still argue to
turn a11y on by default: it's far easier for someone without a
disability to turn it off than it is for a person with a disability
to turn it on.
Will
Mathias Hasselmann wrote:
Am Mittwoch, den 30.07.2008, 13:11 -0400 schrieb Willie Walker:
Alexander Jones wrote:
> Isn't this a distro decision?
Ultimately, I guess the value for any gconf setting in
schemas/desktop_gnome_interface.schemas can be whatever a distro
wants it to be. What I'm proposing, however, is that the default
value that we choose for GNOME is that accessibility will be
enabled by default. If distros want to revert this back to
disabling accessibility, I guess it would be their choice.
What is the motivation for enabling accessibility by default?
Anecdotally....
I have had 'assistive technologies' turned on now for a year. I am not a
user. My fairly modest computer (IBM T43 512mb of ram) hasn't had any
difficulties. I haven't seen any detrimental effect.
Having assistive technologies turned off by default is a real hassle for
those who need to use it. Having it turned on by default doesn't have
much of an effect. For those who want to optimize their desktop turning
it off takes exactly 10 seconds.
For the regular user (not handicapped, not a testing engineer) the
accessibility bridge just consumes resources without providing any
benefit - AFAIKS.
Why can't accessibility be activated on demand? With D-Bus activation
we have the platform for enabling such features on demand.
Ciao,
Mathias
------------------------------------------------------------------------
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Thanks
Mark
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]