- From: Mark Rogers <mark.rogers@powermapper.com>
- Date: Sat, 11 Aug 2012 10:05:02 -0500
- To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>, Olaf Drümmer <olaf@druemmer.com>
- CC: W3C WAI ig <w3c-wai-ig@w3.org>, Adam Cooper <cooperad@bigpond.com>, Vivienne CONWAY <v.conway@ecu.edu.au>
>I can't see any fundamental reason why this should take a long time. >VoiceOver doesn't just handle them in memory, it displays them in the Item Chooser list. Pretty much instantly. >Likewise Opera surfaces 2000 links in its Links list pretty much instantly. >If this is a problem in JAWS, that represents fundamental inefficiency either in its communication with browsers (assembling the list) or its widget set (rendering the list). I think the likely reason for this is JAWS (and NVDA) on are separate applications, which means they run in their own protected memory space. This means they can't access memory in the browser directly, and need to marshall data between processes (e.g. to get a list of links). This is much, much slower than just accessing the data directly in memory. This is one reason JAWS and NVDA both have plugins for IE and Firefox - these run as part of the browser process to speed up some common operations. Some details on this here: http://www.nvda-project.org/wiki/DesignOverview#Inter-processCommunication I'm not familiar with the internals of VoiceOver, but I'd guess it's loaded into each process automatically because it's part of iOS / MacOS, which means it doesn't suffer the performance hit. Best Regards Mark Mark Rogers - mark.rogers@powermapper.com PowerMapper Software Ltd - www.powermapper.com Registered in Scotland No 362274 Quartermile 2 Edinburgh EH3 9GL
Received on Saturday, 11 August 2012 15:05:31 UTC