[14:50:59] Reedy: is there a way to report a PHPStorm bug without my full name showing up? [14:51:26] The only solution I found is to remove the full name from the account, but I'm unsure if that might be bad for the license etc. [14:52:07] What's up? [14:52:23] You don't necessarily need a real name on your account, I think [14:52:47] Nothing special, just weird but valid syntax being reported as invalid [14:52:58] Oh really? [16:31:25] Majavah: did you see that comment for nature.com for wgCopyUploadsDomains? [16:32:29] acagastya: I got an email but I completely forgot to get that done, sorry [16:33:06] Ah, okay. [16:50:28] Hi folks. Ticket has come into OTRS saying https://en.wikipedia.org/wiki/Normal_distribution causes a significant CPU spike for them. I can replicate it - seems to cause +30% on normal usage for me (Chrome). Is it simply unavoidable because of the sheer volumes of latex syntax on the page, or am I missing something? [16:51:55] I don't really understand. shouldn't all the images be cached? [16:52:49] when I clicked through just now it was blindingly fast to load, and my cpus are busy doing other things. this is firefox but it shouldn't mater [16:52:51] *matter [16:53:18] It loads fast enough for me, but seems to continue hogging CPU. [16:53:39] I got nothing like that over here [16:53:53] * acagastya has been using KaTeX for personal work, and that seems to be very light-weight. [16:54:03] were they complaining about load during editing maybe? but even so the rendering of latex is on the upstream end, not the client [16:54:30] It starts about 10 seconds after loading the page for me. (Chrome) [16:54:37] [zulip] svg images are not cached afaik [16:55:02] I would have put it down to user error had I not been able to replicate it (and I'm only viewing the page, not editing) [16:55:07] [zulip] and latex is always processed client-side [16:55:17] [zulip] so combine both of those things, it's kind of expected imo [16:55:27] oh are these all svgs now [16:55:32] I am out of date [16:56:24] zulip - how long would you expect the spike to continue for? By all indications the page is fully rendered but the spike doesn't seem to go away for me (not sure about for you, juancarlos ?) [16:56:26] in firefox what behavior do you see? because honestly with firefox and a bunch of tabs open and vlc in the background and a bunch of memory hogged by gnome etc [16:56:34] it's unnoticeable [16:57:19] [zulip] the svg images should be cached since they are served as pngs but i am not aware if the images are generated on-the-fly or otherwise [16:58:00] [zulip] if on-the-fly then understandable or else, maybe just the tons of latex, i suggest trying another page with a lot of latex to see if you can replicate it [16:59:30] Hm. It's definitely not as noticeable with Firefox. And by that I mean it doesn't cause my computer's fan to jumpstart like it did with Chrome. :) [16:59:34] must be on the fly, because when i check the image location and retrieve it for any of the rendered latex, it's a mess of svg indeed [17:00:00] Hm, I don't get the same issue with https://en.wikipedia.org/wiki/Poisson_distribution [17:00:22] Ticketer is Chromium on Debian [17:01:51] I wonder if there's some specific render that's causing the reporter the trouble [17:01:59] Edge doesn't like it either. [17:02:24] [zulip] on cached loads, Normal distribution renders faster for me [17:02:29] [zulip] i'm running the latest Firefox [17:02:43] Edge is webkit now, so that tracks [17:03:15] er, sorry, blink [17:03:29] edge uses the same renderer as chromium, is what I'm trying to say :) [17:03:37] Yea [17:04:52] Firefox spikes initially but drops to normal usage within seconds [17:07:55] there's over 300 svgs in that article [17:08:32] Yea, there's shedloads. But firefox is clearly doing a better job at handling them than chromium browsers. [17:08:48] less than 200 in the other article [17:08:53] that by itself could make the difference [17:09:12] yep [17:10:05] [zulip] chromium and handling resources effectively are... erm... a bit out there [17:10:46] Yeah I've heard that story [17:11:06] Are we saying that the fault lies exclusively with chromium being inefficient, or is there anything we can do to improve? [17:11:23] (Short of removing svg's from the article, which I will suggest, but clearly may not be the ideal fix) [17:11:39] You could certainly file bugs upstream [17:11:53] "Hey, this Wikipedia page causes issues on Chrome due to all the SVGs) [17:11:57] does chrome have an open bug tracker? [17:12:02] chromium does [17:12:08] https://bugs.chromium.org/p/chromium/issues/list [17:12:12] anyone got chromium to do a test? [17:12:19] might as well verify it's in that too [17:12:31] The original reporter was using Chromium on Debian [17:13:45] oh chromium indeed [17:14:48] they could try in a sandbox previwing the first half of the page (or someone here could), see if it's still slow, then the second half... if one is slow and not the other maybe it can be tracked to some set of the svgs and how they are handled [17:15:01] if they are both slow or both not, then... meh. punt upstream I guess [17:15:42] Yeah that's a fair shout [17:16:11] I'm just throwing this in here.... could it be that the Fhromium browser renders via software, while Firefox has been known for a few versions to do on the GPU even on L:inux? [17:16:28] honestly no idea [17:16:58] I wouldn't expect the gpu to be fast for something like that but what do I know [17:17:09] got a crap intel integrated gpu here on this laptop btw [17:17:32] 5 years old crap intel gpu to be clear [17:17:53] well, Firefox does lay-out rendering on the GPU with the right hardware. It's called WebRender [17:18:36] [zulip] my GPU usage is consistent, it's a gaming GPU so either it's too less work to have an effect on usage or it has no effect [17:20:09] I see a modest GPU spike loading on firefox but I don't see the same sort of lingering usage that I get on Chrome [17:20:29] well, I guess thats WebRender doing its thing Darren [17:20:52] Can you check if hardware acceleration is turned on? [17:21:09] On Chrome, or FF? [17:21:13] chrome [17:21:42] Yeah, it is [17:21:48] hmm [17:23:30] fwiw I backchanneled with a friend on the chrome team, and without looking at it deeply her answer was "weird! please file a bug" [17:24:29] ha [17:24:50] I cant make sense of this... for me it shows more cpu and gpu usage on firefox, then it does for chromium.... on Windows.... [17:26:16] [zulip] i get 0-0.1% (and i checked and it's certainly using the GPU engine) [17:27:32] [zulip] small spike of 2% on Normal distribution and about 2.3% for Poisson's distribution [17:28:59] wonderful [17:31:07] [zulip] on an off-topic question, do GET requests on Phabricator also require tokens? [17:35:47] what do you mean with tokens. zulip? [17:36:11] [zulip] API tokens [17:37:26] thats a question I cannot really answer for you. someone might. I don't have enough knowledge about that subject to say anything useful, sorry [17:37:42] they do, but if i remember correctly there is some toolforge that can proxy read requests and add its own token there [17:41:11] [zulip] hmm no issue will deal with tokens, would you happen to know if there's any way to retrieve plaintext or something else? the API returns raw wikitext-ish from manifest.search Majavah [18:55:05] rzl: I'll submit a bug and also pop a post on pump just in case anybody has any ideas of anything we can do to e.g. reduce the size of the svgs or whatever. [18:55:08] Thanks [18:55:22] sgtm [19:11:27] why do you need to reduce svg size? [19:12:00] it's only a hypothesis. [19:12:35] But Chrome for several people is really struggling with https://en.wikipedia.org/wiki/Normal_distribution , presumably because of the volume of svgs in the math markup [19:13:27] I have seen the backlog now [19:14:46] yes, on firefox there is an spkie, then stops [19:15:21] it also drops on chromium, for me [19:15:44] *spike