mozilla :: #servo

21 Apr 2017
01:38jdmwhat's the correct way to use a modified local dependency as part of a stylo build?
03:06Manishearthbholley: after dealing with system font false positives for days, the hazard analysis has found a real issue
03:06Manishearthhttps://dxr.mozilla.org/mozilla-central/source/widget/gtk/nsLookAndFeel.cpp?q=%2Bfunction%3A%22GetSystemFontInfo%28GtkWidget+%2A%2C+nsString+%2A%2C+gfxFontStyle+%2A%29%22&redirect_type=single#898
03:06Manishearthwe seem to cache system font results fetched from the OS
03:07Manishearthshould I eliminate this optimization for stylo? or do something else? who do I talk to to know how important it is?
03:07Manishearthalso, won't caching the system font prevent us from responding to OS changes?
03:13Manishearthour font stack is insanely not-thread-safe
03:13Manishearthbholley: should I just land system fonts and whitelist the heap write, filing a followup? system fonts unblock a lot of tests
03:14Manishearththe whole set of font things unblocks a lot of tests in general
03:14ManishearthI think system fonts and font metrics are the last bits (text-zoom shouldn't be playing a large part), but im not sure
03:14bholleyManishearth: can we just disable the caching if we're in the parallel traversal?
03:15bholleyManishearth: also, this is platform-specific code, so we need to audit what windows and osxc do
03:15bholley*osx do
03:15bholleysince the analysis doesn't run on those platforms :-(
03:15Manishearthyeah
03:15Manishearthim doing that right now :
03:15Manishearth:| :|
03:15Manishearthbholley: we could, I'm wondering how costly that would be
03:16bholleyManishearth: jfkthame is the person to ask about it
03:20bholleyManishearth: in general I want to get this into the tree as soon as possible, but I'd prefer disabling the cache for the servo traversal (at least for now) rather than whitelisting a real hazard
03:20Manishearthokay
03:21Manishearthbholley: I'd still need to whitelist it though, I don't think the analysis is smart enough to detect what I'd be doing here
03:22bholleyManishearth: the analysis is smart enough to notice if (IsInServoTraversal())
03:22Manishearthbholley: yes but the code here is more comple
03:22bholleyManishearth: we do that all over the place for these situations
03:22ManishearthI could split it into two near-identical functions and that would work
03:22Manishearthbut I can't keep the code clean
03:22bholleyManishearth: I don't understand why we can't just make the heap writes conditional on IsInServoTraversal()
03:23Manishearthbholley: the heap writes are important here
03:23bholleyManishearth: in general I'm pretty opposed to whitelisting stuff - we should rewrite things in such a way that the analysis can prove it's ok
03:23Manishearththe only issue is the target
03:23Manishearthbholley: the heap write is a write to the font that will contain the final value
03:24Manishearthactually, I'll just duplicate it, it's only a couple of lines
03:27Manishearthbholley: figured it out
03:27Manishearththanks
03:27bholleyManishearth: yay!
03:27Manishearthbholley: are we fine with a priori paying the cost here and fixing it later, or should I ni? jfkthame first and not land till I have a response?
03:28bholleyManishearth: fine to land, but we should file a followup and NI
03:28bholleyManishearth: also make sure that the audit gets done
03:28Manishearthyes of course :)
03:28Manishearththe audit of the other ones?
03:28Manishearther, windows and stuff?
03:28bholleyManishearth: yes, windows and mac
03:29Manishearthbholley: I thought you wanted me to do that just now, but I can defer to a followup
03:29bholleyManishearth: oh, do _that_ part now
03:29Manishearthbholley: ?
03:29Manishearththe linux stuff only?
03:30bholleyManishearth: do the audit now
03:30bholleyManishearth: optimize perf later
03:30Manishearthah ok
03:30bholleylike I'm fine with landing such that stylo works but doesn't cache fonts
03:30bholleynot fine with landing such that windows and mac may have races
03:30Manishearthokay, that's what I thought
03:30bholleyManishearth: but it's also worth just dumping a list of all the platform-specific font stuff we call into in 1354966 so we can double-check it before shipping
03:31Manishearthas far as i can tell we hit like half of gfx ther
03:31Manishearth;p
03:33Manishearthwindows seems to be ok
03:33Manishearthit does this ptrlogfont thing but afaict its readonly
03:34jdmwhat's the correct way to use a modified local dependency as part of a stylo build?
03:34jdms/what's the correct way/how do I/
03:35Manishearthlol all system fonts on android are the same
03:35Manishearthgood job android
03:36Manishearthbholley: okay, good news, it's only linux (well, gtk) which is broken here
03:36ManishearthI think mac uses gtk too
03:37ManishearthI need to do a bit more checking in windows. maybe add a const pointer
03:37bholleyManishearth: mac definitely doesn't use gtk
03:38Manishearthbholley: well there's no other nsLookAndFeel.cpp
03:38Manishearthhm
03:38bholleyManishearth: well there's something, and it's not gtk :-)
03:39Manishearthoh theres a .mm file
03:39Manishearth NSFontSymbolicTraits traits = [[font fontDescriptor] symbolicTraits];
03:39bholleysounds like mac
03:39Manishearthwat
03:40Manishearththis isn't kansas anymore
03:40Manishearthobjc i guess
03:40bholleyyep
03:44Manishearthokay, this has no heap writes either afaict but I'm not very sure, it's objc code and I need to double check some things
03:45Manishearthalso I'm going to stick a const ptr in the windows code to prevent it from being mutated later
03:53pcwaltongw: so Ive got a current plan if all goes well it should work as far back as GLES2
03:53pcwaltongw: the idea is that I will write CPU implementations of everything, targeting GLES2
03:53pcwaltonof everything that GLES2 doesnt support that is
03:54pcwaltonand then as the GL version increases more and more gets moved to the GPU
03:54pcwaltonthe trapezoidation algorithm Im using is simple enough that I think it could be moved to the GPU with GL4 compute shader, but it certainly doesnt require it and its quite fast on CPU
04:08hirosomeone delegate+ above PR, please?
04:11hirocbrewster: thank you!
04:12cbrewsterhiro: no problem :)
04:25Manishearthbholley: quick r? bug 1358362
04:25firebothttps://bugzil.la/1358362 ASSIGNED, manishearth@gmail.com stylo: Whitelist some outparams in the heap write analysis
04:25Manishearthfeel free to press autoland if you r+ it
04:25Manishearthalready passes try
04:30KiChjangManishearth, i hear you're like a god these days
04:30KiChjangwhen it comes to FFI stuff
04:30bholleyManishearth: r+, pushed autoland
04:38Manishearthbholley thanks!
04:38bholleyManishearth: thanks for fixing this stuff!
04:39Manishearththe remaining ones are font metrics ones which heycam is doing and one weird one which i need to poke at
04:39* bholley goes back to making stylo faster and faster
04:39Manishearthbholley: after tge selectors fix, did we improve on tp5?
04:39Manishearthkichjang wat
04:39bholleyManishearth: maybe, I haven't checked - tp5 isn't worth looking at right now because we're screwing things up with revalidation selectors
04:39bholleyManishearth: that's on my list to fix, but for now I'm avoiding the problem by profiling with the style sharing cache disabled
04:41Manishearthah
04:41bholleyManishearth: we're not filtering the revalidation selectors in the way we should, so we ruin performance every time we check the cache
04:42bholleyManishearth: I'll fix it, but first I'm focusing on the no-style-sharing no-parallelism case
04:42bholleyManishearth: and making all that stuff blazing fast
04:42Manishearthcool
04:42bholleyManishearth: most of it boils down to "pointer chasing kills you"
04:43bholleyManishearth: which all validates Gankro's talking points
04:44Gankro?
04:44* bholley seems to recall Gankro writing things on the internet about how linked lists were terrible for performance
04:44GankroHehe
04:45GankroI thought servo killed those
04:45bholleyGankro: there are still several in the style system
04:45Manishearthgecko absolutely loves linked lists
04:45bholleyGankro: I doubled the performance of the style system by removing one
04:45GankroNice
04:46bholleywell, "performance of selector matching on a particular microbenchmark"
04:46bholleybut well
04:47GankroClassic servo perf
04:58bzManishearth: Gecko loves hashtables and arrays too
04:58bzManishearth: They're everywhere
04:59bzManishearth: we don't use heaps and trees as much as we should...
05:09stshinepcwalton: What is the reason we need to do inorder traversal to inline blocks?
05:09pcwaltonstshine: can you link me to the code?
05:09stshinepcwalton: https://github.com/servo/servo/blob/master/components/layout/inline.rs#L1476
05:10pcwaltonstshine: thats just in case the inline block contains floats
05:12stshinepcwalton: but inline blocks are block formatting context
05:12pcwaltonoh, hmm
05:12pcwaltonmaybe they dont need it then
05:12stshineokay
05:12pcwaltonif nothing breaks, feel free to remove it
05:13stshinelet me deal with the float things first
05:13stshinepcwalton: thanks
05:33Manishearthbz yeah, but it at least uses arrays (well, vectors) where it should some times
05:33Manisheartha lot of the LLs should have been a HT or vec
06:17bholleybz: yt?
06:17bholleyand SimonSapin
06:17SimonSapinhey bholley
06:17bholleySimonSapin: hey!
06:17* bholley was hoping to sort out a plan on this bool caching thing
06:18bholleyin particular whether we want to (a) Flush styles when the first !important or non-!important declaration is added to a PDB, or (b) do the rule tree thing
06:19SimonSapinI think the rule tree thing is independent
06:19bholleywell, it would make this issue moot
06:19SimonSapin(assuming you mean avoiding matching selectors twice)
06:19bholleyyes
06:19SimonSapinbholley: you can still have a style rule that both, either, or neither
06:20SimonSapinout of !important and not-!important
06:20bholleySimonSapin: I don't follow
06:20bholleySimonSapin: if we were dealing with !important later, we wouldn't need the bools, right?
06:20bholleySimonSapin: because then it would just be "does this PDB have any rules at all"
06:20bholleyer
06:20bholleyany declarations at all
06:21SimonSapinbholley: the current setup skips matching selectors of a rule that doesnt have any declaration (after removing invalid/unsupported ones)
06:21bholleySimonSapin: exactly
06:21SimonSapinso we still need at least one bool
06:21bholleySimonSapin: or are you saying the bools are what accomplishes that
06:21bholleyI see
06:21SimonSapinunless we give up on skipping that
06:22SimonSapin(Im kind of amazed that pointer chasing alone can make such a difference)
06:23bholleySimonSapin: gecko doesn't do the skipping
06:23bholleySimonSapin: but I think the skipping is good
06:24bholleySimonSapin: ok, so I guess we can just flush if the threshold is crossed
06:24bholleybz: does that sound acceptable to you perf-wise?
06:24SimonSapinbholley: I *think* we dont recreate the stylist of style rule modification, but I dont know for sure. The test case I described should tell you
06:24SimonSapinwhat threshold?
06:24bholleySimonSapin: the threshold of "having {important,non-important} rules when we didn't before"
06:25bholleySimonSapin: i.e. we don't need to flush on every add
06:25bholleySimonSapin: only when the first such rule is added
06:25bholleySimonSapin: we presumably do recreate the stylist when the selector part of a style rule is modified
06:25bholleySimonSapin: otherwise the stylist would be all wrong
06:25bholleySimonSapin: so I wasn't sure if we carefully separate out the selector part or just do it unconditionally
06:25bz_sleepbholley: oh, you pinged?
06:26bholleybz: yes
06:26bholleybz: just hoping to sort out this bool caching business
06:26bholleybz: while the three of us are here
06:26bholleybz: see backscroll
06:26* bz reading
06:26SimonSapinbholley: selectorText setter is separate from setProperty/removeProperty
06:26bzso...
06:27bzLet me see if I understand the servo setup correctly
06:27bzThe reason it was biting us on that testcase is that we did nontrivial work to decide whether to try matching
06:27bholleybz: yes
06:27bzbefore we applied the bloom filter
06:27bzSo we did it on all sorts of rules we didn't care about
06:27bholleybz: pointer-chasing to compute the bools
06:27SimonSapinbholley: I think that marking the stylist dirty when setProperty/setPropertyPrority/removeProperty changes the result of any_important() or any_normal() would work
06:29bholleybz: in theory that rejection should be faster than bloom filter rejection
06:29bholleybz: but only if we don't pointer-chase
06:29bzright
06:29SimonSapinbz: nontrivial only in terms of cache locality, I think?
06:29bholleybz: assuming we continue selector-matching twice for the !important case, I think we need to keep the bools to avoid doubling work
06:29bzRight
06:29* bholley assumes this only works because !important is rare
06:29bholleyis that right?
06:30bz!important rarity ... it depends
06:30bzbut generally, I think that's a good assumption
06:30bzOutside of our UA stylesheets. ;)
06:30SimonSapinmy assumption when writing this code was that having both !important and non-!important in the same rule is rarer
06:30bzI think pretty much every rule that has !important has non-!important too
06:30bz(that's even true for our UA sheets)
06:30SimonSapinah, so I assumed wrong :)
06:31bznote that I am stating gut feeling
06:31SimonSapinsame
06:31bzwhich should not be confused for telemetry data!
06:31* bholley our UA stylesheets back up bz's feeling: http://searchfox.org/mozilla-central/source/layout/style/res/forms.css
06:31bzWhich we could gather here, fwiw
06:31bholleybz: yes, but that takes time
06:31bzSure
06:31bholleybz: and I'm in a hurry
06:32bzI don't know that we need a perfect solution for 57
06:32bzJust a solution
06:32bholleybz: ok - so is flushing the stylist when adding a rule acceptable?
06:32bholleybz: er
06:32bholleybz: adding a declaration
06:32bholleybz: when there previously was none
06:32* bz is not sure what the impact of flushing the stylist is
06:32bholleybz: rebuilding all the rulehashes
06:33SimonSapinand all the rule trees?
06:33bholleySimonSapin: yes, that too
06:33bholleybz: presumably gecko does something similar?
06:33bholleybz: it certainly must invoke RebuildAllStyleData
06:33* bz is looking up excatly what Gecko does
06:33bzbholley: we certainly do NOT do that
06:34bzbholley: absolutely certainly not
06:34bholleybz: because it'd be too slow?
06:34SimonSapinwhen CSSOM modifies something inside CSSStyleRule.style
06:34bzgimme a few to look up what Gecko does
06:34bholleyI guess maybe it throws away the style structs but keeps the rule nodes?
06:35jdmwoo, flailing with lifetimes when I would rather be sleeping
06:35bzSo
06:35bzLet's start with modifying the .style of a rule in a sheet
06:36bz(this stuff got changed some since I last looked)
06:36SimonSapinbholley: random idea: would an arena allocator help with cache locality?
06:37bznsIPresShell::RestyleForCSSRuleChanges
06:37bzSo we do a restyle_subtree on the root
06:37bzThat's not all of it, though
06:38bholleySimonSapin: (for selectors? Yeah, it would help with locality and parsing performance - adds complexity though)
06:38bzWe also call CSSStyleSheet::DidDirty(
06:39bzWhich clears the rulehashes.
06:39bzThose get rebuilt on-demand
06:39bholleybz: isn't that exactly what RebuildAllStyleData does?
06:39* bholley needs to go to bed soon
06:39bzno, RebuildAllStyleData blows away the ruletree
06:40bzNone of the stuff above touches the ruletree
06:40bholleybz: ah, I see
06:40bzso any rules that didn't get changed still have all their cached computed structs in there
06:40bzyou rematch selectors
06:40bholleybz: well, we're not caching style structs in the servo rule tree
06:40bzand hence things might end up pointing at new ruletree branches..
06:40bzSure
06:41bzAnyway, so this happes for every .style mutation on a style rule in Gecko
06:41bzregardless of whether declarations are added, removed, whatever
06:41bzIt's not exactly the fastest way to handle this stuff
06:42bzBut in practice, people pretty rarely mutate these via CSSOM...
06:42bzOf more interest is changes to inline style
06:42bholleybz: ok - so back to the original question - is it acceptable to blow away the stylist then?
06:42* bholley really needs to leave soon
06:43bzBlowing stuff away for mutations to css rules is probably fine
06:43bzBlowing stuff away for inline style mutations obviously not
06:43bholleyright
06:43bholleyhm, I wonder what happens with !important on inline style changes...
06:43bzin Gecko?
06:44bholleybz: in my proposed servo setup
06:44* bz doesn't know
06:44bholleybz: ok, gotta run - we can pick this up tomorrow, I'll dig some more and ping you if I have questions
06:44bholleybz: SimonSapin - thanks!
06:45bzIn Gecko, you get eRestyle_StyleAttribute and then we recompute the relevant parts of the ruletree branch for the element
06:45bzto pick up the maybe-now-we-have-it !important bit for the inline style
06:49SimonSapinbholley: we could always insert style attributes in the rule tree at both normal and important positions, and skip based on any_important() and any_normal() during the cascade
06:49SimonSapinthere is no selector matching to skip
06:58bzSimonSapin++
06:58bzin terms of complexity of changes from what we have right now that seems simplest
08:00wafflesoooh, serde 1.0
08:47emilioSimonSapin: bz: Style attributes aren't in Rule objects in servo, how are they affected by bholley's changes?
09:04noxDid our dependency graph change? For some reason mach rebuilds script every time I change something in style. oO
09:11feliix42So I'm trying to wrap my head around how servo is using pipelines and threads. Is there any good reading material on this (other than the source code)?
09:24emilionox: afaik script has always depended on style
09:24noxIf anyone can do a geckotry on https://github.com/servo/servo/pull/16558 it would be nice.
09:24crowbotPR #16558: Properly parse alignment shorthands (fixes #16391) - https://github.com/servo/servo/pull/16558
09:24noxemilio: No?
09:24noxOr did it?
09:24noxAnd I am somehow confused with my recent contributions to net,
09:24noxthat may be possible.
09:25emilionox: hmm... I'm pretty sure that at least for the style attribute stuff and preshints we need some style code :)
09:25noxYeah,
09:25noxI probably confused myself.
09:25noxemilio: r? ^
09:25emilionox: will do your try asap btw
09:25noxemilio: Ok,
09:25noxemilio: can you do one for them gradients too?
09:26emilionox: which pr is it?
09:26noxemilio: #16548
09:26crowbotPR #16548: Improve parsing of gradients - https://github.com/servo/servo/pull/16548
09:26* emilio has been distracted with schoolwork this week
09:26emilionox: sure, will do
09:31emilionox: https://treeherder.mozilla.org/#/jobs?repo=try&revision=0505bdf71c7c5d44e084e2764813da97c7b362fa
09:31emilionox: (that's for both PRs
09:31emilio*)
09:31noxemilio: Merci beaucoup. :)
09:32emilionp :)
09:41emilionox: lol @ geckolib build failure: https://treeherder.mozilla.org/logviewer.html#?job_id=93259231&repo=try&lineNumber=19074
09:42emilionox: I believe you need to use FLAGS.bits instead of flags.0
09:42noxFFS
09:45avadacatavranox: would it make any sense to put an origin in globalscope
09:45noxemilio: Also, there should be 5 methods like that in fact. :(
09:45noxavadacatavra: Maybe, maybe not.
09:47avadacatavraso, the problem is when we create a DissimilarOriginWindow. We create it with a GlobalScope and BrowsingContext. There's one spot where we create it where it's easy to pass an origin
09:48avadacatavrabut then in browsingcontext::new_dissimilar_origin, we just have a GlobalScope, FrameId and Option<BrowsingContext>
09:48avadacatavranot sure how to acquire the origin for the DissimilarOriginWindow in this case?
09:49* avadacatavra might be missing something obvious though
09:49noxemilio: In AlignJustifyContent shouldn&#39;t I be checking both primary and fallback?
09:50noxI don&#39;t even understand what the hell is a fallback here.
09:50noxOh found it in the spec.
09:52avadacatavranox: it kinda seems like i either need an origin in BrowsingContext or GlobalScope
09:53noxavadacatavra: Sorry, you should ask jdm I don&#39;t really know what&#39;s the best way to get an origin from GlobalScope,
09:53avadacatavranox: will do
09:53noxI was under the impression that you can get the origin back from Principals or something like that.
09:54avadacatavranox: the problem is https://github.com/servo/servo/pull/16501/files#diff-b8211de881132905e8dc1ee4a135311bR143
09:54avadacatavrathat&#39;s where i create the principal, so i need the origin there
09:54avadacatavrabut...obj isn&#39;t necessarily a window
09:55avadacatavraso instead, i&#39;m passing origin to create_global_object from CodegenRust.py
09:56noxavadacatavra: I see.
09:56noxWell I guess it makes sense to move it to GlobalScope, then.
09:56noxemilio: Can you geckotry again? I fixed the build failure.
09:56avadacatavracrowbot: ask jdm what do you think about putting origins in GlobalScope?
09:56avadacatavranox: sounds good. i&#39;ll try that out and see what jdm thinks
09:57noxavadacatavra: It would help some stuff in general in the net crate too, I think.
09:58* avadacatavra opens new branch
10:10noxseanmonstar: reqwest can only be used with native-tls?
10:16emilionox: sure
10:16noxemilio: Thanks.
10:18emilionox: https://treeherder.mozilla.org/#/jobs?repo=try&revision=7351f05ca75737f6583d97f2921ad410e3883598
10:22SimonSapinnox: get icecc so you can compile gecko in single-digit minutes
10:22noxSimonSapin: I don&#39;t have FTTH.
10:23SimonSapinah, forgot youre never in the office :)
10:24nox:)
10:41travis-ciServo failed to build with Rust nightly: https://travis-ci.org/servo/servo-with-rust-nightly/builds/224286901 CC nox, SimonSapin
10:44noxTIL there is an event today in my univ,
10:44noxfor CS students to meet with former students from there,
10:44noxI guess I&#39;ll go and talk about Mozilla.
10:52noxemilio: https://treeherder.mozilla.org/#/jobs?repo=try&revision=7351f05ca75737f6583d97f2921ad410e3883598&selectedJob=93277209
10:52noxI don&#39;t understand where the log is,
10:52noxbut I&#39;m going out for a bit, will check your answer later.
10:53noxAFAICT these patches should produce unexpected PASS results,
10:53noxbut I don&#39;t see any.
11:03emilionox: I wouldn&#39;t care about the non-stylo build issue, it&#39;s probably a builder issue
11:03emilionox: there are still 5 webkit-linear-gradient failures htough
11:05emiliohiro: ping?
11:05hiroemilio: hi!
11:06emiliohiro: hey! So, I&#39;m doing some patches to fix some getComputedStyle + pseudo-element issues, and I found some animation-related servo-only failures
11:07emiliohiro: the difference is, when possible we grab the style from the frame now
11:07emiliohiro: (this is bug 1355351)
11:07firebothttps://bugzil.la/1355351 NEW, nobody@mozilla.org pseudo-elements don&#39;t return the correct style via getComputedStyle.
11:07emiliohiro: so it seems we may miss to update some pseudo-styles in the frames, even when Servo has it properly
11:08hiroemilio: oho? yeah, on stylo we have some problems animations on pseudo elements too.
11:08emiliohiro: My question is: what&#39;s the status of pseudo-element animations on Stylo, should they work properly?
11:08emiliohiro: also: do they follow the same post-traversal path as normal restyles do?
11:09hiroemilio: that&#39;s what I am not sure thing.
11:09emiliohiro: the failures are the ones at https://treeherder.mozilla.org/#/jobs?repo=try&revision=f67a90c430e410b756cb681633539c28fe0146b1
11:10hiroemilio: animation pseudo element in some simple test case works fine, but some mochitests fail.
11:10emiliohiro: the style context of the pseudo-element frame seems to be outdated. I have an extra patch to fix it, but it didn&#39;t fix those tests, so that&#39;s why I&#39;m asking :)
11:10hiroemilio: oh. increased failures. I was hoping some failures fixed.
11:11emiliohiro: yup! me too :)
11:11emiliohiro: so that&#39;s why I asked before digging more into it
11:11emiliohiro: but I can also dig, no worries ;)
11:12hiroemilio: thanks. I will check it tomorrow too.
11:12emiliohiro: thanks!
11:20jdmavadacatavra: yes, origin on globalscope makes sense
11:21noxemilio: Can you link to them?
11:21avadacatavrajdm: perfect i&#39;ll do that
11:21noxI don&#39;t understand how to navigate TH.
11:22emilionox: https://treeherder.mozilla.org/logviewer.html#?job_id=93285301&repo=try&lineNumber=2748 (though that&#39;s not very helpful)
11:24emilionox: there aren&#39;t that many webkit-linear-gradient tests in http://searchfox.org/mozilla-central/search?q=-webkit-linear-gradient&path= though
13:20emilioboris: ping?
13:21emilioboris: could you point me to where do we propagate the styles to the frame during transitions in stylo? Is it the normal post-traversal?
13:50Murray_BHi! I am testing servo (linux, 64 bit) from time to time and always make it freeze, I think it is a handling problem.
13:51Murray_BI call &quot;servo&quot;, enter an adress and it gets displayed. Now I try to enter another adress: I click at the top until I get the input field with the current adress - and now servo freezes - what am I doing wrong?
14:12nicalWhat&#39;s the command line switches to display webrender&#39;s overlay debugging info in servo ?
14:12emilionical: from memory I think &quot;-Z wr-debug&quot;, but let me look it up
14:12emilionical: yeah, that should work
14:13nicalthanks!
14:13emilionp :)
14:19nicalwr-stats actually
14:23Gankrodoing some quick profiling; any recommended pages that will remain fairly stable over days/weeks?
14:25ajeffreyCurrently working on worklets, it looks like an MPMC queue will come in handy.
14:25ajeffreyThere&#39;s one in https://docs.rs/crossbeam/0.2.10/crossbeam/sync/struct.MsQueue.html,
14:25ajeffreywould anyone object to adding crossbeam to servo? or is there another crate I should be looking at? aturon or acrichto?
14:27acrichtoajeffrey: crossbeam has historically had a few segfaults, I forget if they&#39;re fixed now though
14:27acrichtoa month or so ago I had to remove crossbeam from futures-cpupool :(
14:27ajeffreyacrichto: :/
14:27acrichtocrossbeam&#39;s under new maintainership, though, and the bugs may have been fixed
14:27acrichtoIIRC all the bugs were known, just not fixed
14:27stjepangajeffrey: Crossbeam is going through a renaissance at the moment. Great stuff is coming in the near future, I promise. Can you tell me what kind of MPMC queue you need? I&#39;ll make your wish true.
14:28acrichtostjepang is the man :)
14:28ajeffreystjepang: one remarkably like MsQueue :)
14:28stjepangDo you need bounded/unbounded queues? Queue-like or channel-like API? Do you need a select macro? Perhaps select functionality that doesn&#39;t require a macro?
14:31ajeffreyNot sure I&#39;ve thought this through at that level of detail I&#39;m afraid.
14:33stjepangajeffrey: Ah, that&#39;s all right. So I figure you need an unbounded queue that is Sync, with simple push/pop operations. This is definitely coming within the next 3 months. I believe the current MsQueue is okay at the moment, except it leaks nodes (it is missing a Drop implementation).
14:33ajeffreyI think what would be ideal is an unbounded queue, no select, but the ability to broadcast to all receivers as well as send to one receiver.
14:34stjepangajeffrey: For broadcasting I&#39;d recomment the &quot;bus&quot; crate.
14:34* ajeffrey goes and looks
14:53noxemilio: You mean &quot;TEST-UNEXPECTED-FAIL | layout/style/test/test_value_storage.html | failure pattern `-webkit-linear-gradient` in this test - expected 10 failures but got 5&quot;?
14:53noxWhere are the expectations for this, so I can see the 5 remaining failures for -webkit-linear-gradient?
14:55jryansnox: the stylo-failures file lists the current count for this https://dxr.mozilla.org/mozilla-central/source/layout/style/test/stylo-failures.md#203
14:56noxAh. :/
14:56noxAnd I guess on TH there is no way to know which tests failed?
14:56jryansnox: yes, there is, do you have link to a run?
14:57noxjryans: I do. https://treeherder.mozilla.org/#/jobs?repo=try&revision=7351f05ca75737f6583d97f2921ad410e3883598&selectedJob=93285301
14:59seanmonstarnox: correct (reqwest)
15:00jryansnox: clicking the log link for the failure takes you to the point that error appeared in the bottom subpanel, such as https://treeherder.mozilla.org/logviewer.html#?job_id=93285301&repo=try&lineNumber=2748
15:01jryansnox: the failure pattern error has to wait for the whole test to finish, and these tests are large, so it could be a bit far from the specific failures, let&#39;s see...
15:02jryansnox: ah, i see :S most of the output was skipped for the test <snipped 146382 output lines - if you need more context, please use SimpleTest.requestCompleteLog() in your test>
15:03jryansnox: you could either run it locally, or you can add a call to SimpleTest.requestCompleteLog() at the beginning of the test file and run again to have full output logged
15:03noxCan anyone with an existing tree run that test and tell me which failures remain for layout/style/test/test_value_storage.html? I would like to finish this before end of day.
15:04noxFor webkit gradients I mean, sorry.
15:06Murray_BI call &quot;servo&quot;, enter an adress and it gets displayed. Now I try to enter another adress: I click at the top until I get the input field with the current adress - and now servo freezes - what am I doing wrong?
15:06noxstandups: Spent 3 hours at my univ, telling people to try to join Mozilla, to learn Rust, and to contribute to Servo.
15:06standupsOk, submitted #45050 for https://www.standu.ps/user/nox/
15:06jryansnox: you want to know the test output from what&#39;s currently merged?
15:06Murray_BErr, I shoul mention, I am using the prebuild version
15:07noxjryans: Yes, which cases from test_value_storage.html related to gradients in current tree.
15:07cbrewsterMurray_B: what platform are you on?
15:08Murray_BLinux 64 bit
15:09Murray_BWell, I have acess to an Windows 7 64 bit, now I could try it there too, because there are prebuild versions
15:09Murray_BI guess I will do it this weekend, just to see if there is a difference
15:10cbrewsterMurray_B: give that a shot, I can&#39;t reproduce that behavior on my end. Would you mind filing an issue?
15:10jryansnox: i&#39;ll do a try run with the extra logging, don&#39;t have a super recent build locally right now...
15:10noxjryans: I swear I&#39;ll set it up next week.
15:10noxMeanwhile, thanks for your help. :)
15:12Murray_Bcbrewster: I&#39;ll see if I can get some information to file an issue. I have this problem since the first prebuild version, I can&#39;t believe it is still normal, so I thought I ask google and IRC ;-)
15:13cbrewsterMurray_B: Thanks! :)
15:14jryansnox: okay, we should see results appear at https://treeherder.mozilla.org/#/jobs?repo=try&revision=5e4975299507fe27a6bcc69a0a497a309f4662b8
15:17noxjryans: Thanks a lot!
15:23emiliobholley: yt?
15:30jryanshaha &quot;This setup for ServoComputedValues-backed nsStyleContexts is probably not something we should ship.&quot; (1 year ago)
15:34Manishearthwe don&#39;t back contexts with ServoCVs, do we?
15:34ManishearthI thought they&#39;re stye structs
15:34Manishearthand we convert back on demand via needs_clone
15:43jryansManishearth: mm, maybe the comment is just old then? nsStyleContext has ServoComputedValues* (via NonOwningStyleContextSource) and the style structs are filled like you said by calls to Servo_GetStyle<X>
15:45emiliojryans: that comment is definitely up-to-date
15:45emilioManishearth: how not? gecko doesn&#39;t know about servo&#39;s computed value representation, except for animations
15:53Manishearthemilio yes, thats what im saying?
15:53Manishearthoh wait i mixed up ServoCompitedValues with Servo computed values
15:53Manishearthmy bad
15:56jryansemilio: do you know why bholley&#39;s old comment says it shouldn&#39;t ship that way?
15:57emiliojryans: I have no clue, can you point me to it? That may help.
15:57emiliojryans: but probably it was because of being afraid of FFI call overhead or something?
15:58jryansemilio: https://dxr.mozilla.org/mozilla-central/source/layout/style/nsStyleContext.cpp#705-708
16:04emiliojryans: no clue :)
16:04jryans:)
16:33noxjryans: The build finished but I don&#39;t know where to look at.
16:33jryansnox: let&#39;s see
16:33noxThanks for the handholding again, TH is so overwhelming.
16:34noxcrowbot: What&#39;s new?
16:34crowbotLynx destroyed Servo&#39;s average memory safety :)
16:34noxOops.
16:35jryansnox: here&#39;s the same job from before. since there aren&#39;t active failure (just expected ones) they aren&#39;t as obvious, we have to look at the log directly. https://treeherder.mozilla.org/#/jobs?repo=try&revision=5e4975299507fe27a6bcc69a0a497a309f4662b8&selectedJob=93351418
16:36jryansnox: for that the &quot;raw log&quot; (2nd paper looking icon) https://queue.taskcluster.net/v1/task/RvcuuStaSpGuTOXi4lnFHg/runs/0/artifacts/public/logs/live_backing.log is useful
16:36noxThanks!
16:36jryansnox: you can search for lines like &quot;TEST-FAIL | layout/style/test/test_value_storage.html&quot;
16:36noxFound the cases.
16:46noxdbaron: I see that neither the 2011 spec nor the current one for linear-gradient allows &quot;0 red&quot; for color stops, I guess I should support that anyway given there is a test for it in test_value_storage.html?
16:46noxhttps://www.w3.org/TR/2011/WD-css3-images-20110217/#color-stop-syntax https://drafts.csswg.org/css-images/#typedef-color-stop-list
16:46crowbotnox: that&#39;s probably not the spec you want. Please read https://github.com/servo/servo/wiki/Relevant-spec-links
16:47noxcrowbot: Pipe down.
16:48noxemilio: AFAICT the remaining failures are unrelated to my PR, they are just things I didn&#39;t write code for yet.
16:57cynicaldevilnox: could you help me with something to do with wptserve?
16:57noxjryans: Do you know if anyone is working on fixing the serialisation of animation-timing-function?
16:57noxcynicaldevil: Maybe but jgraham or gsnedders are probably more knowledgeable to reply.
16:58jryansnox: i don&#39;t believe so!
16:58cynicaldevilnox: Its a basic question, I can&#39;t understand what a fetch to &#39;stash.py&#39; does.
17:01jryansnox: oh! i did spot https://bugzilla.mozilla.org/show_bug.cgi?id=1358330 which seems related
17:01firebotBug 1358330 ASSIGNED, hikezoe@mozilla.com stylo: computed timing function should preserve keyworded function
17:01noxOk cool.
17:03cynicaldevilnox: nvm I found it. The repo was moved recently and I was not able to find the docs
17:03jryansnox: https://wiki.mozilla.org/Quantum/Stylo has a bunch of links to different bug searches, i use these to understand the state of things
17:03noxjryans: I added a block on the test_value_storage.html ticket.
17:03jryansok!
17:05noxxidorn: Around?
17:32Manishearth*phew* g_object_unref is threadsafe
17:33bzManishearth: heh
17:34bzmanishearth: lookandfeel code?
17:34cpetersonemilio: did you figure out whether the intermittent image test failures in the rayon PR were existing issues? froydnj&#39;s PR updated both rayon and jpeg-decoder, but I don&#39;t know whether jpeg-decoder needed to be updated to work with rayon 0.7 or it was a opportunistic ride-along. Is the image test failure probably related to rayon 0.7 or jpeg-decoder?
17:34Manishearthbz: yep
17:34Manishearthbz: the windows and macos and android stuff is pretty straightforward
17:34Manishearththe linux stuff does caching *and* dodgy gtk calls
17:34bzManishearth: heh
17:35mbrubeckManishearth: Hmm... I just realized that &quot;all safe Rust functions are thread-safe&quot; might be a strong selling point to a C++ programmer... maybe moreso than &quot;Rust prevents use-after-free&quot;
17:35Manishearthyes
17:36Manishearthgod yes
17:36Manishearththis has been my life for the last two months
17:36mbrubeck(since so many seem to believe that use-after-free isn&#39;t a &quot;real&quot; problem, but they aren&#39;t under such illusions about race conditions)
17:36ManishearthEVERYTHING IS NOT THREAD SAFE TAKE COVER
17:36Manishearthdata race, fwiw, other race conditions can occur
17:41emiliocpeterson: I don&#39;t think so, I did a few try runs the other day on that PR and there was only one test failure, and not image-related
17:41emilionox: sounds good
17:43cpetersonemilio: thanks. I&#39;ll ask froydnj in the PR if we really need to include jpeg-decoder.
17:44emiliocpeterson: we probably do, given otherwise servo would pull two different rayon versions
17:44* emilio cries looking at scrollbars inside generated content :&#39;(
17:45emilioand how broken is our handling of those
17:46bzemilio: stylo&#39;s, gecko&#39;s, or both? ;)
17:47emiliobz: thinking about stylo... Started debugging some animation test failures and ended up here... oh well.
17:47froydnjum...&quot;process didn&#39;t exit successfully: `/home/worker/workspace/build/src/obj-firefox/toolkit/library/debug/build/heapsize-6a8e11c8cf3246ad/build-script-build` (signal: 11, SIGSEGV: invalid memory reference)&quot;
17:47emiliobz: would definitely be curious about Gecko though
17:47froydnjhow worried about that should we be?
17:48bzemilio: Ah. I don&#39;t know of specific Gecko issues here, fwiw.
17:48emiliobz: but in particular: http://searchfox.org/mozilla-central/source/layout/base/nsCSSFrameConstructor.cpp#1918 means we&#39;ll style a generated content element as-if it was a normal content node
17:48* froydnj wonders what in the world heapsize is doing in a build script, of all things
17:48bzemilio: funtimes
17:49emiliobz: and of course skipping styling of those there means that we won&#39;t find</