Re: Enable accessibility by default in development releases?

Tue, 22 Nov 2005 13:40:05 -0800

Looking at Ross's suggestion and your profile data Padraig, does look as if something like the "scrollbar-updated signal is causing the a11y layer to refetch the contents of the terminal several times on every output"

So Kjartan's patch replaces the following g_return_if_fail macros in vteaccess.c with g_asserts allowing them to be compiled out which is great, but I fear the % of cpu time in the function they take up will be small relative to the  time taken to update the snap_shot text :( But certainly worth trying. Suspect we'll get most mileage out of looking how to batch the scroll events, be clever on the type of redraw we are doing ...

JR

/vte-0.11.15/src/vteaccess.c
    249 static void
    250 vte_terminal_accessible_update_private_data_if_needed(AtkObject *text,
    251 						      char **old, glong *olen)
    252 {

		:
    259 
    260 	g_return_if_fail(VTE_IS_TERMINAL_ACCESSIBLE(text));
    261 
    262 	/* Retrieve the private data structure.  It must already exist. */
    263 	priv = g_object_get_data(G_OBJECT(text),
    264 				 VTE_TERMINAL_ACCESSIBLE_PRIVATE_DATA);
    265 	g_return_if_fail(priv != NULL);
    266 
    267 	/* If nothing's changed, just return immediately. */
    268 	if ((priv->snapshot_contents_invalid == FALSE) &&
    269 	    (priv->snapshot_caret_invalid == FALSE)) {
    270 		if (old) {
    271 			if (priv->snapshot_text) {
    272 				*old = g_malloc(priv->snapshot_text->len + 1);
    273 				memcpy(*old,
    274 				       priv->snapshot_text->str,
    275 				       priv->snapshot_text->len);



Padraig O'Briain wrote: 
I have looked at profile data when accessibility is enabled and most of
the time is spent in
vte_terminal_accessible_update_private_data_if_needed.

I need to apply the patch to replace g_return_if_fail calls with
g_assert calls and see what improvement that makes.

Padraig

On Tue, 2005-11-22 at 12:16 +0000, John Rice wrote:
  
As can sometimes be the case with automated benchmarks, not quite what
it seems :(

Derek had an issue with doing one of the automated benchmarks in
gnome-terminal and gedit, so he went back and rechecked them all
manually. Difference from previous automated results below, when
cat'ing a large file in GT or opening a large file in GEdit.

Looks like if you need to cat large files flick the off button :)
Apart from that things look ok for enabling this by default. All the
previous automated benchmark tests were uneffected.

JR
Revised results from manually measuring;

o cat a big file in gnome-terminal (Using a .html file, 26,332,850 bytes)
-  AllY Off: 40 secs
-  AllY On: 214 secs  (over 500% increase in mean scroll time)

o open a file in gedit (same .html file as above)
-  AllY Off: 3.18 sec
-  AllY On:  4.49 sec  (40% increase in mean file load time)



Federico Mena Quintero wrote: 
    
On Mon, 2005-11-21 at 16:34 +0000, John Rice wrote:

  
      
Doing 'cat' of a big file in gnome-terminal was the only area where a
significant difference was seen. Approx 45 secs with A11Y ON, and 42.4
secs with A11Y Off.

All other areas looked at above were not significantly different
comparing A11Y On Vs A11Y Off.
    
        
This is great news :)  And the difference in gnome-terminal could be
just noise.

So, have people *felt* a performance impact from running their session
with a11y enabled, or is it just a placebo?

Anyway, let's go ahead with the change - this will let us test the code
better.

  Federico

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

  

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

Reply via email to