mozilla :: #gfx

10 Oct 2017
01:32pulsebotCheck-in: https://hg.mozilla.org/projects/graphics/rev/1d917ba31e53 - Matt Woodrow - Make sure we build a wrap list whenever there might be multiple items
11:42evilpieanyone else seeing white flickering when scrolling? http://www.bbc.com/future/story/20171009-the-female-code-breakers-who-were-left-out-of-history-books
11:42evilpieI do have force-enabled compositing on Linux
13:59Gankroaosmond: https://gist.github.com/Gankro/ebb53fc729268c5560d4119e6d7e51d6
14:26rhuntevilpie: yeah I see that on linux with compositing force enabled too
15:19milanjesup: yeah, Canada was away yesterday, so I only monitor slack on the weekends :) If it had been Windows, I'd have guessed a driver restart with the content process not recovering from it. But the other thing we had with "one content process at a time" had to do with native event handling changes.
15:22jesupmilan: it's still in the bad state if attaching a debugger or turning on logs dynamically (via about:networking's backdoor to turn on logs while running) would help
15:38Gankrolin clark wrote a thing on WR: https://hacks.mozilla.org/2017/10/the-whole-web-at-maximum-fps-how-webrender-gets-rid-of-jank/
15:48milanlsalzman: can you think of any more information we can get from jesup while he has the browser in the broken state?
17:20linclarkthere's a question about WebRender on Linux. I know the plan for that isn't totally clear yet, but if anyone wants to respond: https://hacks.mozilla.org/2017/10/the-whole-web-at-maximum-fps-how-webrender-gets-rid-of-jank/#comment-21963
17:20mconleyjrmuizel: Hey - so I nabbed a profile from the Slow-Mo laptop when _just_ animating the throbbers. I throttled down the CPU a bit too in the Windows power management settings to magnify the effect even more. Check it out: https://perfht.ml/2xv1lIL
17:21mconleyso this is us doing mostly nothing except showing 9 tab throbbers
17:22mconleyTwo observations: the old Compositor thread in the parent process seems to be sampled way more frequently than the GPU process main thread
17:22mconleyeven though the old Compositor thread isn't really doing anything
17:22mconleyactually, y'know what, that was my only observation.
17:22mstangemconley: that's an awesome url btw
17:23Gankrolinclark: it works fine on linux today; the primary dev of the backend uses linux primarily
17:23mconleymstange: indeed! :)
17:23Gankrolinclark: also our only CI testing is on linux
17:24linclarkah, ok... I'll have to look back at my notes from my convo with Nicolas to see what I was thinking of
17:25mstangelinclark: the biggest issue is that you have to force-enable hardware acceleration on linux in order to use webrender, and we haven't made any progress on enabling hardware acceleration on linux by default recently
17:26linclarkmstange: ah, ok, that may have been what he said
17:27mstangelinclark: this is an amazing article by the way, so clear and so accurate
17:28linclarkthank you! I love hearing that from the folks working on it
17:28mstangelinclark: thank you for including the group opacity scenario, it's an important case
17:28linclarkmstange: I actually borrowed that example from Chrome's explanation of slimming paint
17:29mstangeheh
17:29mstangewell, good call :)
17:29mconleyI kinda want these in a pamphlet that we can give to new browser engineers that we hire
17:30mconleylike, make it part of the onboarding package
17:30Gankrothe gifs will be tricky ;)
17:30mconleybecause I've been hacking on the browser for years, but it's only been like... the past year or so that I feel like I'm really starting to understand the pipeline that gets stuff on screen.
17:30linclarkha, indeed... I may be packaging it up into a website at some point, though
17:31mconleycool
17:35nicallinclark: congrats for the blog post, it's great!
17:36linclarknical: thank you! and thanks for all your input on it, that was crucial
17:37mstangelinclark: the performance cliff sketch is great
17:38* kats-lunch is PTO this afternoon
17:38linclarkha, yeah, jack was particularly fond of that one as well
17:42Gankrolinclark: re: quantum compositing -- it's possible that it's doing similar things to WR; wr is in some sense redundant with a lot of other quantum projects (omtp, apz), because it's gonna take a lot longer to ship it, and we want wins for everyone now
17:43linclarkGankro: ahhh, ok. That makes sense
17:46jesuplsalzman: ping
17:59botond|homeGankro: WR makes APZ redundant?
18:00Gankrobotond|home: I meant more that the APZ effort is doing a bunch of work that WR duplicates
18:00Gankrohappy to be corrected
18:03botond|homeGankro: do you mean like needing a representation of scroll frames, clips, position-fixed elements, etc., for APZ, that WR has anyway?
18:04Gankrobotond|home: I'll be honest I don't know a lot of details of how APZ looks in gecko/wr. I was just going off the fact that it works without wr, and wr also needs to explicitly do work to support it.
18:05GankroSo presumably there's a bunch of code in gecko that APZ changes/adds that becomes "dead" with wr turned on
18:05botond|homeGankro: ah, i see. yeah, there's definitely code like that in FrameLayerBuilder
18:08dvanderaosmond: how are surfaces expected to be threadsafe when using WR vs without?
18:12aosmonddvander: hmm I think this was about SourceSurfaceSharedData? shared surfaces simply aren't used unless you are using WR, which is how it became moot.
18:13aosmonddvander: but SourceSurfaceVolatileData also has a mutex. if we solve that one, we solve both I believe...
18:14dvanderaosmond: some of the other surface types are ostensibly threadsafe but not really (i.e. using atomics intended to fix ordering issues)
18:14dvanderlong before WR, even
18:14dvanderdo you know if that's just gunk that was never really used?
18:14mstangeBas: with OMTP, is the content backend on Windows still D2D?
18:14aosmondright and for images, afaik, the only concern would be a decoder thread causing an unmap when it is finished decoding, and the main thread mapping in order to draw
18:14dvandermstange: yes
18:14mstangedvander: ok
18:15mstangedvander: what happens if you draw a D2D source surface into a DrawTargetCapture? Do we readback?
18:15mstange(or what is it that OMTP is using? DrawTargetCapture or DrawTargetRecording?)
18:15dvandermstange: the recording will just hold a pointer to the d2d source surface
18:16dvanderyeah DrawTargetCapture is what OMTP uses
18:16mstangeok
18:16mstangedvander: but what happens to that pointer if you send the captured stream over?
18:16dvandermstange: with OMTP it's never "sent" anywhere, it just gets replayed on a different thread
18:16mstangeoh right!
18:17mstangeI forgot
18:17mstangeok great
18:17mstangestupid question, really
18:17aosmondthere might also be conflict in the singular/combined UI/GPU process case where the compositor thread mapping in a surface, and the main thread doing the same or releasing -- normally this isn't a problem due to the process boundary but there are a few images in the UI process obviously.... but I haven't fully thought this scenario out.
18:17dvandercapture has a whole different can of worms :)
18:18mstangeok, so this means that cases where we accidentally don't create a DrawTargetCapture are not prohibitively expensive, they just cause us to do work on the main thread that could theoretically be done on the painting thread
18:18dvandermstange: yeah exactly. i have... bugs open on a few cases we know about where this happens, box shadows are one, rgba luminance effects are another
18:19mstangedvander: I'm currently looking at filters, e.g. http://searchfox.org/mozilla-central/source/layout/svg/nsFilterInstance.cpp#456
18:19dvandermstange: ooh, I missed that one
18:20mstangedvander: there's a profile in https://bugzilla.mozilla.org/show_bug.cgi?id=1407356
18:20firebotBug 1407356 NEW, nobody@mozilla.org When blob images are used, filters are still rasterized on the content side
18:21mstangeone with webrender enabled, not with OMTP
18:21dvandermstange: for OMTP to fix it we need a SourceSurfaceCapture - bug 1395478
18:21firebothttps://bugzil.la/1395478 ASSIGNED, dvander@alliedmods.net Use capture DTs for box shadows
18:22mstangeI see
18:22dvandermstange: the first patches there make us use CreateSimilarDrawTarget more
18:22dvanderso we can keep propagating recordings around
18:22mstangesounds good
18:22mstangeso is this the same as what webrender blob images is using?
18:23mstangeor is there no overlap between the two?
18:23dvandermstange: I think WR uses DrawTargetRecording, but in theory if DrawTargetCapture/Recording make CreateSimilarDrawTarget return the right thing
18:23mstangeI see
18:23dvanderwe should be able to change SVG code to work in both paths
18:23mstangeyeah
18:28dvanderaosmond: okay... so based on that information, I think I'll just move the lock count and mutex to DataSourceSurface, and have each derived class just implement their bare-bones Map/Unmap calls. does that seem reasonable?
18:29aosmonddvander: sounds good to me. what's the bug #?
18:30dvanderaosmond: bug 1405390
18:30firebothttps://bugzil.la/1405390 ASSIGNED, dvander@alliedmods.net Remove DataSourceSurface::GetData
18:31aosmondthanks
19:03mikoDo we have any numbers what % of users are not using hw acceleration?
19:06rhuntmiko: for windows at the least https://dvander.github.io/moz-gfx-telemetry/#view=windows-features
19:07evilpiewow that is surprisingly bad
19:27mikorhunt: awesome, thank you!
20:39mconleyjrmuizel_: can I tempt you with some probably-useful stacks on the slow laptop in Concurrency Visualizer when just throbbing the tabs?
20:39jrmuizel_mconley: yes
21:04Gankromstange: this is "needs to force enable hardware" ? https://www.reddit.com/r/rust/comments/75hzk5/the_whole_web_at_maximum_fps_how_webrender_gets/do6qtiz/?context=3
21:16mstangeGankro: I replied
21:16Gankrotyvm
21:37Gankrogw: in case you're not sure what to work on today, might I suggest the several corrupted text rendering bugs? :) (alpha probably most valuable)
21:43gwGankro: sure - I'm just about to open a large PR, so it's a good time to look at some bugs - you mean like #1839 and #1811?
21:44Gankrogw: yep
21:47gwGankro: ok - will look at them today. I briefly looked at one of them yesterday and was unable to repro it. But that was testing in Servo, so it may not be following the same path.
21:47Gankrogw: ah yeah, these are all in gecko
21:49gwGankro: ok - will ping in the bug if I need more info
22:14Gankrogw: it seems like it might need an opacity stacking-context, but idk how to write those in wrench
22:15gwGankro: opacity-overlap.yaml gives an example of an opacity stacking context
22:15gwGankro: (or opacity.yaml)
22:16mstangegw: what's your main bugzilla account? I'd like to assign a few bugs to you that are being fixed by webrender updates
22:21gwmstange: I usually just log in with my mozilla email address
22:21Gankrohrm can't reproduce in wrench, might be font-specific...
22:24mstangegw: ok
22:24gwGankro: It's also quite possible / likely that it is fixed by the recent changes lsalzman made (which use pre-multiplied alpha for text runs). I thought gecko already had that update, but if it doesn't, that might explain why you can't repro in wrench?
22:25Gankrogw: it just landed like 20 minutes ago
22:25GankroI'll see if it's fixed on master
11 Oct 2017
No messages
   
Last message: 6 days and 15 hours ago