mozilla :: #gfx

18 Apr 2017
06:27pulsebotCheck-in: - Ethan Lin - Bug 1349500 - Add webrender support for BulletFrame path type. r=mchang
08:00Jerry_IRCCloudsotaro: nical: ping
08:01sotaroJerry_IRCCloud, pong
08:01nicalon my way
13:09pulsebotCheck-in: - 132 changesets - Merge m-c to graphics
13:22pulsebotCheck-in: - peter chang - Bug 1345017 - pass animation data from content to WebRenderBridgeParent, r=kats
13:23pulsebotCheck-in: - peter chang - Bug 1345017 - Update WebRenderAPIs to enable OMTA, r=kats
13:23pulsebotCheck-in: - peter chang - Bug 1345017 - Add animation sampling for WR, r=kats
13:23pulsebotCheck-in: - peter chang - Bug 1345017 - Discard compositor animations on the next layer transaction, r=kats
13:23pulsebotCheck-in: - peter chang - Bug 1345017 - Disable OMTA with webrender by default, r=kats
14:06katsGankro: for some reason your WR patch broke all the things
14:06katsGankro: this is just a heads-up for now, i'm gonna investigate a bit and see if I can figure out what happened
14:08pchangkats: thanks, I will work on the try failure to enable omta with wr by default
14:08katspchang: sounds good
14:13katsGankro: i guess you said that "Firefox's headers will need to be updated" in your commit message, do you have details?
14:16Gankrokats: BuiltDisplayListDescriptor needs to be regenerated
14:16GankroTwo new fields
14:16katsGankro: ah ok. i'll rerun the generator and add a patch to the queue. thanks
14:17katsi should probably make that a part of my script
14:17Gankrokats: in the future, is there something more I should do when I make changes that need downstream updates?
14:18katsGankro: dropping a comment or a patch onto the current "future webrender upate bug" would be helpful. but don't feel bad about not having done it, this workflow is still new and i haven't asked people to do that in the past
14:19Gankrokats: ok, duly noted!
14:19Gankrokats: did you see my comment about vendor rust being broken?
14:19katsGankro: no
14:20katsGankro: was it on IRC?
14:21katsGankro: thanks, i'll look into it
14:21GankroThe update issue is the place to post that stuff, I guess?
14:25katsGankro: yeah that would be the best place
14:25katsi don't watch the WR github repo except for specific issues
14:27Gankrokats: ok cool. lmk if my patch or that patch need interesting changes -- I'm debugging an instant crasher on my local branch building off yours
14:36Gankrokats: oh crap you also need to update some code that MsgSends the contents of the descriptors
14:38Gankrogrep from display_list_items_size; needs the two new fields
14:38Gankro(Sry walking to work)
14:48Gankro(Neither side is expecting those values so it might come out in the wash? Modulo uninitialized performance counters)
15:08jrmuizelrhunt: talk to mystor
15:08katsGankro: i did a try push with the FFI header regenerated, i'll see how that goes
15:10pulsebotCheck-in: - Kartikaya Gupta - Bug 1357065 - Rename the parameters to PushScrollLayer to be more correct. r=jrmuizel
15:10pulsebotCheck-in: - Kartikaya Gupta - Bug 1357065 - Add a PushClip/PopClip API to WebRenderAPI to more easily distinguish between scrolling clips and non-scrolling clips. r=jrmuizel
15:10pulsebotCheck-in: - Kartikaya Gupta - Bug 1357065 - Update WebRenderDisplayItemLayer to use PushClip instead of PushScrollLayer because it's pushing a non-scrolling clip. r=jrmuizel
15:14mchangBas: Do you know why we need mRealizedBitmap here -
15:15Basmchang: I think it had to do with perf issues if you collect too many draws of non-realized images into other non-realized images.
15:15BasLook at the commit log.
15:16mchangBas: I did, it was the add d2d backend :)
15:17Basmchang: I think that was it, but I'm not 100% sure.
15:17mchangBas: im just confused why mRealizedBitmap is created and copied over from the old mRealizedBitmap
15:18pulsebotCheck-in: - Kartikaya Gupta - Bug 1355475 - Update webrender to 07b6c6a1f93b5d8af1dd9ae825906dcf5c310810. r=jrmuizel
15:18pulsebotCheck-in: - Kartikaya Gupta - Bug 1355475 - Update reftest fuzziness for change in webrender cset e3f6317. r=jrmuizel
15:18Basmchang: Oh wait, I'm confused, this is just because the old one is going to be changed.
15:18BasThat's what this function is for.
15:20mchangBas: what do you mean the old one is going ot be changed? It basically seems to create a new mREalizedBitmap to copy itself back to mRealizedBitmap
15:20mchangunless there is some d2d magic m not seeing
15:21Basmchang: right, because the oldBitmap is the surface the DrawTarget this is a snapshot of is going to be writing to.
15:24mchangBas: why createa new bitmap everytime instead of just writing to mImage?
15:25Basmchang: It shouldn't be 'every time' once 'DrawTargetWillChange' has been called, mSnapshot on the DT will be nulled, and it will never be called again
15:25Basmchang: that's what 'MarkIndependent()' does
15:41katsGankro: so the try push is still showing the same errors (debug build results only so far). when i run reftests on my local build (which is opt) they seem to pass. i'm gonna wait and see what the opt build produces on try. it might be a debug-only problem now
15:41Gankrokats: interesting; maybe debug catches the uninit perf counters?
15:42katsGankro: maybe. i'll kick off a local debug build anyway to see if i can repro. even if that's the problem i want to figure out why we're not getting any useful output or stacktraces
15:42mstangejrmuizel: <evilpie> we need AMD to fix this issue with their new driver
15:43katsGankro: indeed it seems to be debug-only. the opt jobs on the try push are coming back green so far
15:47mchangBas: sorry, still confused as to why in DrawTargetWillChange(), you would want to recreate mREalizedBitmap every call?
15:48Basmchang: It&#39;s only ever called once.
15:48Gankrokats-afk: this is the diff you want, I think
16:30katsGankro: thanks. when i run it locally (without your patch) i do get a backtrace and rust panic. so that&#39;s something at least
16:52jimmdo we have any stats showing what percentage of Windows users fail to get accelerated rendering?
16:56Basjimm: There&#39;s a dashboard for it.
16:56Basdvander will know the URL
16:57jimmdvander: ^?
16:57jimmI found this in my history -
16:58jimmthat doesn&#39;t really help though
16:59jimmah, the Trends option helps
17:46rhuntjrmuizel: ping
17:50dvanderjimm: the &quot;Windows Features&quot; dropdown shows it as ~27% of windows users
17:54jrmuizelrhunt: pong
17:55rhuntjrmuizel: did you say that wrench recording is broken?
17:55jrmuizelrhunt: replay is broken
17:55jrmuizelrhunt: fixes it
17:56rhuntjrmuizel: ah, okay I&#39;ll use that branch then
18:32jimmdvander: thanks!
18:46Gankrokats: you may or may not run into a fun rustc codegen bug:
18:47katsGankro: oh fun
19:30pulsebotCheck-in: - Ryan Hunt - Bug 1357335 - Use Into<T> for webrender bindings conversions r=kats
20:27Gankrokats: this &quot;fixes&quot; the bug
20:27GankroDunno if that&#39;s the one you&#39;re seeing, though
20:28katsGankro: i&#39;m not seeing any issue at the moment. the patch you provided earlier (in the IPC code) fixes the debug jobs
20:28Gankrokats: ah great!
20:34rhuntis anyone else getting shader compile errors with qr on windows?
20:37gwrhunt: there&#39;s a servo issue opened where some people are seeing shader compile errors on windows.
20:37gwrhunt: seems gpu / device specific, but I haven&#39;t looked into it yet
20:40rhuntgw: ?
20:40rhuntgw: I&#39;m getting some error from angle with vClipMaskUvBounds, which is similar to the error in there
20:41gwrhunt: yep - the WR CI runs the shaders through the ANGLE shader validator, so it&#39;s somewhat surprising...
20:46pulsebotCheck-in: - Ryan Hunt - Bug 1357543 - Add rustfmt.toml and run rustfmt on webrender_bindings r=kats
20:48rhuntgw: yeah that is odd, changing vClipMaskUvBounds to be a vec4 instead of a RectWithEndpoint fixed it for me
20:48gwrhunt: I guess that particular driver doesn&#39;t handle structs as interpolators :/
20:48gwkvark: ^
20:49kvarkoh nice (really, really, not)
20:51rhuntgw, kvark: do you want a pull request with the change?
20:51kvarksure thing
20:52kvarkgw: what about ? is there anything else to address there?
20:54gwkvark: r+&#39;ed
20:58kvarklsalzman: do you mind squashing ?
20:59lsalzmantechnically yes, but i can :/
21:02lsalzmansquashed to 2 commits
21:02lsalzmanversion change and code change
21:04kvarkbeautiful, thanks!
21:47BenWaAFAIK there&#39;s no way for CSS animation to reset/restart without forcing/waiting on a style flush before setting the animation again. Feels like something that should be fixed.
23:19birtlesBenWa: just got your mail
23:20birtlesBenWa: there are probably a couple of hacks you can use
23:20BenWabirtles: Cool, I hope I didn&#39;t just miss an obvious way to have it work :)
23:20birtlesif you have &quot;animation: abc 3s&quot;
23:21birtlesI think &quot; = &#39;abc, abc&#39;&quot; might get it to restart but I need to check
23:21birtlesOtherwise, &quot; = &#39;abc, \&quot;abc\&quot;&#39;&quot; might work
23:21birtlesLong-term the elem.getAnimations() API will help
23:22birtlessince you&#39;ll be able to get the CSSAnimation object back, hold on to it, then just call `animation.currentTime = 0`
23:22BenWaOhh great. Glad to know something is in the works
23:22birtles(currently getAnimations() is specced to flush, however, so you&#39;d want to get it once and hold onto it)
23:23birtleswe could also make the spec say it doesn&#39;t flush if that works out better.. that part of the API hasn&#39;t shipped yet but is in Nightly
23:25BenWabirtles: Yea if it flushes we&#39;re almost better off just doing doing the reset over two rAF without flushing and hope we get them for &#39;free&#39; if the page is touching DOM on those frames
23:26BenWabirtles: a generation id would solve the problem but we probably don&#39;t want to expose a generation id in CSS
23:26birtlesBenWa: yeah, fair enough. Although, if you haven&#39;t touched style already flushing won&#39;t do anything
23:27BenWaI don&#39;t know of any sites that have a way of running code when the dom isn&#39;t dirty. Having a postAnimationFrame would do it if such an API existed
23:28BenWaIt&#39;s doable with if you interpose rAF I guess
23:31birtlesyeah--if you&#39;re one of the first callbacks after style (e.g. animation event callback, rAF callback) then you&#39;ll often be ok
23:31BenWarAF runs before style flush
23:32birtlesah, sorry, yeah, it runs after animations have updated though
23:33BenWaohh? I figured we would need style flush to happen to match updated animations
23:33birtleswe do
23:33birtleswhen rAF has run the animation state has been updated, but the style hasn&#39;t yet
23:34BenWastyle.animationName = &quot;example, example, example&quot; seems to work FWIW
23:35birtlesso if you trigger a style flush inside rAF, then you&#39;re probably just triggering work that is about to happen anyway
23:35birtlesgood to hear
23:35BenWaYes but the problem is on a large site you&#39;ll have multiple rAF. So if you cause a flush there&#39;s a good chance that someone else will dirty it again
23:36birtles(probably need to check that animationName hack works in all browsers though since there was definitely some differences in behavior there at one point)
19 Apr 2017
No messages
Last message: 9 days and 16 hours ago