mozilla :: #accessibility

6 Oct 2017
06:15JamieMarco-M: Hi! yeah, I noticed that weirdness with the buffer taking longer to load when refreshed. That doesn't make any sense to me. It should be faster when the browser isn't handling anything else, not slower.
06:16JamieErr, wrong Marco. Blerg.
06:16JamieMarcoZ: ^
06:19MarcoZJamie: I don't understand it, either. The actual slurping of that article takes 12-13 seconds regardless of whether it's just been loaded or the buffer is being refreshed. Just the initial rendering, before the initial buffer slurp, is a bit snappier with surkov's patches.
06:20JamieMarcoZ: I don't quit efollow. Not sure what you mean by initial render versus buffer slurp. Both should be one and the same; i.e. when you focus a doc for the first time, it slurps the buffer.
06:20JamieMarcoZ: For me, if I visit the URL, the entire doc loads and starts reading within about 7 seconds. if I hit NVDA+f5 at any point, that takes 13 seconds or so.
06:22MarcoZJamie: I mean from the time I hit Enter on the URL bar, focus goes to the document and NVDA starts telling me on the braille display that the document started loading. That is now a bit snappier. However evenn that initial loading of stuff into the virtual buffer takes 12-13 seconds for me.
06:23JamieAh, that's interesting. I'm starting to wonder whether it has something to do with my CPU turbo boosting or something.
06:24JamieMarcoZ: Well, I pushed a try build with the latest caching patches. From the testing I did locally last week, I'm not overly hopeful, but maybe the try build will be better optimised
06:27MarcoZI will give it a try later today when it has finished.
06:41JamieMarcoZ: I think the caching will very possibly help JAWS, since it seems ot ask repeatedly for the same thing on the same node quite a bit. Looking at the logs, for example, I see 20 calls to IAccessible2::attributes on the body element alone
07:02JamieHmm. I put -t none in my try syntax, but I still got a whole heap of artifacts like target.mochitest.tests.zip. Am I missing something here?
07:02JamieAnd -u none
07:07JamieAlso, this article says symbols aren't generated for try builds by default, but I got a crashreporter-symbols-full.zip. Just want to make sure I'm not doing anything wrong or if that's the default these days. https://wiki.mozilla.org/ReleaseEngineering/TryServer
07:30MarcoZJamie: I believe this is standard.
07:38MarcoZJamie: I am indeed not noticing any perf improvement when slurping in that Wikipedia article with the try build. In fact -- and I am now going to verify this with a regular nightly --, the more often I hit NVDA+F5, the longer the time it takes to load the buffer. Second is 13, third about 15-16, and fourth time is up to 20 seconds. That is without reloading
07:38MarcoZthe page, just NVDA+F5 consecutively.
07:47MarcoZJamie: Also happens without the caching bug. It appears the first two runs it's OK at about 13 seconds, then bumps up to 20, 22, and seems to stay there. So something is triggering subsequent tree traversals to become much slower than initial ones.
08:05Jamiemarcoz: Eek. Note that you need to reinstall or re-reg the handler between builds, but I assume you already did that. I wasn't seeing that perf decrease with multi refreshes, but I'll test again on Monday.
08:05Jamiemarcoz: Also, worth testing caching with JAWS in particular.
08:09MarcoZJamie: Yes I do full uninstalls and installs with this handler stuff.
08:09MarcoZHave a good weekend!
14:15davidbMarcoZ: sounds like a bug
7 Oct 2017
No messages
   
Last message: 11 days and 8 hours ago