mozilla :: #gfx

21 Apr 2017
00:44mattwoodrowmstange: Are you still looking at this?
02:00gw280https://arstechnica.com/information-technology/2017/04/mozilla-microsoft-rebuilding-their-browsers-foundations-without-anyone-noticing/
02:12Morrismattwoodrow: ping
02:12mattwoodrowMorris: hi
02:13Morrismattwoodrow: If I don't reset the mItem, I'll hit an assertion in nsDisplayItemData::EndUpdate.
02:13Morrismattwoodrow: Do you think it ok if I keep reseting the mItem. But also check if the mOptLayer is presence in ComputeGeometryChangeForItem?
02:14mattwoodrowMorris: sure
02:14Morrismattwoodrow: Thanks.
02:33gwrhunt: ping
02:53daoshengmustandups: Bug 1358010 - Permaorange assertion failure and crash in test_vrDisplay_getFrameData.html when Gecko 55 merges to beta on 2017-06-12; land
02:53firebothttps://bugzil.la/1358010 NEW, nobody@mozilla.org Permaorange assertion failure and crash in test_vrDisplay_getFrameData.html when Gecko 55 merges to
02:54daoshengmustandups: Bug 1353523 - Adjust threshold for Gamepad button `pressed` state and introduce pref to handle slightly sticky controller buttons; land
02:54firebothttps://bugzil.la/1353523 NEW, dmu@mozilla.com Adjust threshold for Gamepad button `pressed` state and introduce pref to handle slightly sticky con
04:43Jerry_IRCCloudstandups: WR NV12 supporting patch clean up. Add yuv image testing in WR sample.
07:30daoshengmustandups: Follow up Bug 1358247 - Crash in mozilla::gfx::VRManagerChild::RecvReplyGamepadVibrateHaptic, but can't reproduce it locally
07:30firebothttps://bugzil.la/1358247 NEW, nobody@mozilla.org Crash in mozilla::gfx::VRManagerChild::RecvReplyGamepadVibrateHaptic
07:33daoshengmustandups: Diagnose Bug 1358053 - Assertion failure: surface->IsDataSourceSurface() (The snapshot SourceSurface from WebGL rendering contest is not DataSourceSurface.), at ImageBitmap.cpp:885, it is because we create Skia/Cairo drawTargets but only allow DataSourceSurface to do snapshot in WebGL. However, SkiaSourceSurface and CairoSourceSurface derive from
07:33daoshengmuDataSourceSurface. Probably, we can allow them.
07:33firebothttps://bugzil.la/1358053 NEW, nobody@mozilla.org Assertion failure: surface->IsDataSourceSurface() (The snapshot SourceSurface from WebGL rendering c
09:32pulsebotCheck-in: https://hg.mozilla.org/projects/graphics/rev/68b48ae09aed - sotaro - Bug 1346143 - Forget the widget pointer in WebRenderLayerManager::Destroy() r=nical
09:55pchangstandups: found reftest failures in bug 1358437 because OMTA was not running with animation delay test case
09:55firebothttps://bugzil.la/1358437 NEW, howareyou322@gmail.com Eanble WebRender OMTA by default
10:26daoshengmustandsup: implement Bug 1355648 - Add hasOrientation, hasPosition to the Gamepad extension for tracked controllers, for the controllers losing tracking. send r?
10:26firebothttps://bugzil.la/1355648 NEW, dmu@mozilla.com Add hasOrientation, hasPosition to the Gamepad extension for tracked controllers
13:59pulsebotCheck-in: https://hg.mozilla.org/projects/graphics/rev/2075cd677dc9 - Kartikaya Gupta - Bug 1357392 - Update webrender to f3fa3481aac63ac93c6ccbe805379875e24e5b77. r=jrmuizel,jerry,lsalzman
13:59pulsebotCheck-in: https://hg.mozilla.org/projects/graphics/rev/ca9968f8bce5 - Alexis Beingessner - Bug 1357392 - Update IPC code for new fields in struct added in cb0bc28. r=kats
14:27Gankrokats: so how does the graphics branch work? Are your webrender updates in tree, or do I need to checkout graphics to get those?
14:30katsGankro: i'm not sure i understand the question. the graphics branch is a fork of central where we land stuff and periodically merge things back to central
14:30katsGankro: we also copy the latest webrender upstream to the graphics branch
14:31Gankrokats: right so should i be building off graphics or central, in general?
14:31katsGankro: in general i would say the graphics branch. for webrender-related things it has more recent changes
14:31GankroCool
14:32katsGankro: some documentation at https://wiki.mozilla.org/Platform/GFX/Quantum_Render - not sure if it's useful to you at all
14:33GankroWill look, thanks!
14:38pulsebotCheck-in: https://hg.mozilla.org/projects/graphics/pushloghtml?startID=504&endID=505 - 262 changesets - Merge m-c to graphics
15:00Gankrokats: how can I find the latest "update webrender" bugzilla, in general?
15:00katsGankro: you could probably just search bugzilla for "future webrender update bug"
15:01katsGankro: there should be only one. or you could look at the list of bugs in the webrender component. or you could look a the list of bugs blocking the webrender meta bug
15:01Gankrokats: thanks!
15:01katsGankro: the webrender meta bug can be quickly accessed by going to bugzil.la/webrender
15:04Gankrohas the call started? (not seeing anything in skype)
15:05BasI don't see anything either.
15:05botond|homenor I
15:05katsme neither
15:06katsis anybody in toronto?
15:06katsjrmuizel: milan ^
15:06jlinhey - hmm let me check
15:06jrmuizelkats: yes
15:06jlinoh
15:06jlinthere they are
15:06jrmuizelkats: we forgot
15:06katsheh ok
15:06BasHehehe
15:11pulsebotCheck-in: https://hg.mozilla.org/projects/graphics/rev/e849a232de22 - Kartikaya Gupta - Bug 1345017 - Fix android build bustage due to missing include. r=bustage
15:15pulsebotCheck-in: https://hg.mozilla.org/projects/graphics/rev/232a011e91f6 - Ethan Lin - Bug 1357003 - Keep original layer state for basic layer manager when enabling advanced layer. r=mattwoodrow
15:18rhuntmrobinson: ping
15:18mrobinsonrhunt: Hi!
15:18rhuntmrobinson: so you're not able to repro any issues with the bin file I uploaded?
15:19mrobinsonrhunt: The bin files have never worked for me, but if the issue is reproducible with just the YAML, that should be enough.
15:21rhuntmrobinson: what kind of error are you getting? I've been getting three problems with gecko recording
15:21rhunt1. wrench crashes when I replay the bin file to convert it into yaml, this was the crash with ClipIdMapper
15:22rhunt2. if that's resolved, then wrench crashes when reading the yaml files with show, this is a problem with not finding clip ID's
15:23rhunt3. if that's resolved then the display is wrong for some reason, everything is positioned incorrectly
15:23rhuntthat one I've been able to resolve, by deleting all the identity transforms wrench outputs
15:25mrobinsonrhunt: If you want you can just try my branch and see if it fixes your issue.
15:27mrobinsonrhunt: https://github.com/mrobinson/webrender/commit/03bd8d430a49d223c7a0f4a2ca18ebffc25c47ce
15:27rhuntmrobinson: yeah I can give it a look, sorry that was a lot :)
15:28rhuntI've been able to mostly work around it
15:28mrobinsonrhunt: No problem. I wish I could reproduce your issue! :)
15:42katsGankro: thanks for the patch :)
15:51pulsebotCheck-in: https://hg.mozilla.org/projects/graphics/rev/bec7523b36c6 - Lee Salzman - Bug 1357952 - update WebRenderAPI to allow index in add_raw_font. r=jrmuizel
15:51pulsebotCheck-in: https://hg.mozilla.org/projects/graphics/rev/44890ebd9c5b - Lee Salzman - Bug 1357952 - fix UnscaledFontFreeType::GetFontFileData to read file contents when filename is used instead of an FT_Face. r=jrmuizel
17:27mstangejrmuizel: https://github.com/staktrace/webrender/blob/ec60716bb41ef7f79ead58922de6f46de35405a9/webrender/doc/CLIPPING.md
17:27jrmuizelhttps://github.com/staktrace/webrender/blob/ec60716bb41ef7f79ead58922de6f46de35405a9/webrender/doc/CLIPPING.md
17:28katsy'all looking at clipping?
17:29mstangeyup
17:29mstangeGankro was asking about it and we couldn't answer his questions
17:29mstangeso now we're all learning
17:29katscool
17:30katsat some point i'll have questions too about all the different clips that are possible
17:37katskvark: what's the best way to debug or more useful information to provide if i'm seeing a panic in webrender? in particular the one at the top of TextureCache::insert
17:37katss/more/most/
17:39Gankromrobinson(?): why is it that push_built_display_list unconditionally overwrites all clip ids?
17:47GankroAlso is it correct that every displayItem specifies a ClipRegion?
18:04katsjrmuizel: is it currently possible, or are there plans, to make the binding.rs recording 100% reproducible in standalone WR?
18:04katsjrmuizel: like, i want to browse the web with recording enabled, and when i hit a crash, have a recording that i can debug or hand off to somebody
18:05katsdoing that would also allow fuzzing and i think would generally be quite valuable
18:10botondkats: kvark is a member of the TRIBE today
18:10katsbotond: ah, thanks for the heads up
18:11jrmuizelkats: yes, I would like for that to be true
18:11katsjrmuizel: are there difficult things preventing it?
18:11jrmuizelkats: it should sort of work today
18:11jrmuizelkats: not known things
18:12katsjrmuizel: i have a 12meg .bin file which i recorded while browsing yahoo.com. when i run wrench replay --play on it it panics with UnexpectedEof
18:13katsjrmuizel: actually i should probably make sure i'm using the right version of wrench first, that matches the webrender that did the recording. let me do that
18:13jrmuizelkats: do that
18:14jrmuizelkats: replaying has been fragile
18:14jrmuizelkats: so there are probably still bugs
18:14katsjrmuizel: ok. do you know if the recording is flushed to disk on every operation?
18:14katsi'm wondering if the crash is truncating the recording
18:16jrmuizelkats: I don't know
18:16katsjrmuizel: ok i'm still getting the UnexpectedEof
18:16jrmuizelkats: does it play some of the frames before panicing?
18:17katsjrmuizel: it says "Frame 0 offset: 16" and "Frame 1 offset: 41" and then panics
18:17katsjrmuizel: i see a window flash as well
18:17jrmuizelkats: hmm
18:18jrmuizelkats: does the browser crash right away?
18:18katshttps://pastebin.mozilla.org/9019626
18:18katsjrmuizel: when i made the recording you mean? no, i was browsing for a few seconds at least
18:18katsscrolling up and down on yahoo.com
18:18jrmuizelkats: ok, it seems like it's broken for some other reason
18:18jrmuizelkats: are you on OS X?
18:18katsjrmuizel: windows
18:19jrmuizelkats: oh, I've never tried to replay on windows
18:19jrmuizelkats: I will though
18:19katsjrmuizel: ok, thanks
18:19jrmuizelkats: are you using 64 bit Firefox or 32 bit Firefox?
18:19katsjrmuizel: 64-bit
18:20jrmuizelkats: ok, I'll see if I can reproduce
18:20katsjrmuizel: let me know if you want the .bin file
18:24katsit doesn't appear to flush, i think
18:33katsjrmuizel: i get the UnexpectedEof error even with flushing, and even in a scenario where firefox exits normally
18:41mrobinsonGankro: Every item has a ClipRegion, but I'm thinking maybe that isn't necessary.
18:41Gankromrobinson: yeah discussion here seems to be having the same conclusion
18:42Gankromrobinson: couldn't you always just use the ClipRegion item seperately?
18:42mrobinsonGankro: You mean the Clip display item?
18:43Gankromrobinson: sorry yeah
18:43mrobinsonSome background: I'm responsible for the clip display item and added it on top of the preexisting ClipRegion stuff which is why it's a bit gross now and in flux.
18:45Gankromrobinson: would it be possible for push_built_display_list to not adjust clip data?
18:45mrobinsonGankro: I'm not sure about that, but jrmuizel might know.
18:45jrmuizelkats: hmm
18:50jrmuizelmrobinson, Gankro: can we replace the per item clip-id, with a set-clip item?
18:52mrobinsonjrmuizel: Hrm. Probably.
18:52jrmuizelmrobinson: that would make things easier for push_built_display_list
18:53mrobinsonjrmuizel: what is the issue?
18:53jrmuizelmrobinson: right now we need to set the clip-id on all of the pushed items
18:54jrmuizelmrobinson: we want to change it so that push_built_display_list just copies bytes
18:55mrobinsonjrmuizel: I guess then you just have to fixup the clip related Items.
18:56jrmuizelmrobinson: I think we may just decree that there can be no clip related items
18:59mrobinsonjrmuizel: ah. Okay. Isn't this method a temporary thing?
19:00jrmuizelmrobinson: it is unclear how temporary it will be
19:09mrobinsonOkay. We should definitely improve it then.
19:10GankroFor now I'm just gonna make it deserialize and reserialize. *shrug*
19:23katsmrobinson: do you know if the size part of the bounds parameter to push_stacking_context is used for anything? because it doesn't conceptually map to anything useful in my mental model
19:23katsstuff inside it can still leak out
19:51Manishearthjrmuizel: is https://dxr.mozilla.org/mozilla-central/source/widget/gtk/nsLookAndFeel.cpp#898 thread safe?
19:51Manishearthand the next function
19:51Manishearthit seems like the g_object_unref fns are safe, but I'm not sure of the pango ones
19:51jrmuizelManishearth: I'd say no
19:52jrmuizelManishearth: I'd be worried about the widget access
19:52jrmuizelManishearth: you'd have to check for the individual things if you want more confidence than my guess
19:53Manishearthhm
19:57Manishearthjrmuizel: so in the gtk stuff it seems we cache the system font
19:58jrmuizelbelievable
19:58Manishearthjrmuizel: xidorn mentioned that we do handle changes to the actual underlying OS settings
19:58Manishearthwhen is this cache invalidated?
19:58Gankromrobinson: oh actually it looks like I need to decouple clips anyway because of how they're built up.
19:59jrmuizelManishearth: I have no idea
19:59Manishearthjrmuizel: know who would?
19:59jrmuizelManishearth: you probably want to talk jfkthames
20:00jrmuizelJonathan Kew
20:00Manishearthyeah
20:00Gankromrobinson: I'm going to add a SetClipRegion display item, and subsequent items will just "have" the last ClipRegion that was set
20:00Manishearthhe's not here now I guess? I was going to ping him first but couldn't fidn him
20:00Manishearthmrobinson: wait are you contracting for us again? sweet
20:03Gankromrobinson: or rather, that's what ClipDisplayItem will do
20:21mrobinsonkats: it's used to calculate the page height at least.
20:21katsmrobinson: is that only true for the root stacking context? or inner stacking contexts as well?
20:22mrobinsonGankro: what do you mean about the need to decouple?
20:22mrobinsonManishearth: yep!
20:23mrobinsonkats: only root stacking context of every pipeline. I'd really like to move it to a parameters of the display list though.
20:23katsmrobinson: that sounds like a good idea
20:24Gankromrobinson: basically the current API has users create_clip_region, and then passing it to an item. However a clip_region has an (implicit) Vec<ComplexClipRegion>. Currently this is handled by the fact that create_clip_region pushes the vec into the aux_list and stores an ItemRange into it.
20:25Gankromrobinson: my design is inlining aux_lists into the main data stream; to do this I need a sentinel in the stream to indicate &quot;hey here comes an aux_list&quot;. I&#39;m making ClipDisplayItem that sentinel.
20:25GankroAnd subsequent items will just be like &quot;hey I&#39;m using whatever the last ClipDisplayItem set&quot;
20:25Manishearthmrobinson: great to have you back! :)
20:26mrobinsonGankro: they need to be able to switch back and forth.
20:26Gankromrobinson: then they will push a new ClipDisplayItem
20:26mrobinsonClipDisplayItem also handles scrolling so they have to be associated to the same clip display item.
20:27mrobinsonGankro: another option is to use a different kind of display item.
20:27Gankromrobinson: so SetClipRegion ?
20:27mrobinsonOne for complex clip regions and one for scrolling.
20:29mrobinsonGankro: Yeah. I guess you&#39;d need something like SetClipRegion either way.
20:30Gankromrobinson: So wait, an item (let&#39;s say text) can have a clip_region and clip_id set to meaningful things?
20:30Gankro(at the same time?)
20:30mrobinsonGankro: Yes.
20:31mrobinsonGankro: clip is used for clipping and positioning based on scroll offsets.
20:31Gankromrobinson: why isn&#39;t the clip_region the one of the Clip its clip_id points to?
20:34mrobinsonGankro: there is no important reason it can&#39;t work like that, but you are looking at the middle of an evolutionary process.
20:35mrobinsonGankro: what I&#39;m working on now though is adding support for items that are clipped by one clip id and positioned by another.
20:36Gankromrobinson: so SetClipRegion will be minimally disruptive to you?
20:36mrobinsonMaybe it makes sense to further make the distinction between scroll and clip.
20:36mrobinsonGankro: Yeah. A bit until next week hopefully.
20:37Gankromrobinson: ok I&#39;ll do that ^ CC jrmuizel
20:37mrobinsonAh. I recall the other reason we can&#39;t repush a duplicated clip: coordinates are relative to the current stacking context.
20:39Gankromrobinson: is it common for a series of items to have the same clipregion?
20:39Gankro(free optimization?)
20:39mrobinsonGankro: Also if you have an idea of what you want to do I can start working in that direction with my current thing
20:40Gankromrobinson: I&#39;ll probably have a prototype by monday
20:41mrobinsonGankro: in servo it&#39;s not common for complex clips at least. It&#39;s only complex when rendering the background of a rounded div.
20:41mrobinsonTBH we can probably ditch clips entirely for most items.
20:42mrobinsonIt is usually just the bounds and taking space in the display list. It used to be important for overflow hidden, but I just fixed that.
20:43mrobinsonI&#39;m all for making it optional and rare (SetClipRegion or SetClipId).
20:55jrmuizelmrobinson: what items would need clips other than Clip?
21:00mrobinsonjrmuizel: hrm. I can&#39;t think of anything at the moment.
21:02jrmuizelmrobinson:
21:05jrmuizelpcwalton: where does servo&#39;s z-sort happen?
21:05pcwaltonjrmuizel: DL building
21:05pcwaltonjrmuizel: let me find the code
21:05jrmuizelpcwalton: on the servo side?
21:05pcwaltonyeah
21:05jrmuizelpcwalton: wonderful
21:06mrobinsonjrmuizel: I think it&#39;s in DisplayListBuildState.
21:06pcwaltonjrmuizel: what mrobinson said
21:08jrmuizelpcwalton: for what it&#39;s worth I think Chrome can iterate over the Frame tree in z-order
21:09jrmuizelpcwalton: that&#39;s a valuable property for incremental display list construction
21:09pcwaltonits multiple passes though, right?
21:09pcwaltonI mean, we could do that too
21:10jrmuizelpcwalton: it may be. I&#39;m not sure
21:10pcwaltonif its regular WebKit painting its multiple passes
21:10jrmuizelpcwalton: if I had to guess I&#39;d say it&#39;s still regular WebKit painting
21:10jrmuizelpcwalton: what are the passes?
21:11pcwaltonI dont recall off the top of my head
21:11pcwaltonhttps://www.w3.org/TR/CSS2/zindex.html#q23.0 is complicated though
21:11pcwaltonthats why we do what Gecko does traverse once, sort later
21:12jrmuizelok
21:13mrobinsonThe nice thing about sorting last is that it opens up the possibility of building in parallel.
21:13mrobinsonIt&#39;s still a bit tricky though.
22 Apr 2017
No messages
   
Last message: 7 days and 4 hours ago