mozilla :: #gfx

13 Sep 2017
01:02Lenzakjgilbert: https://bugzilla.mozilla.org/show_bug.cgi?id=1372806
01:02firebotBug 1372806 NEW, nobody@mozilla.org Mr.doob's Magic Dust (WebGL) demo doesn't show any particles (Intel HD 520)
07:24jyais the compositor device always only used in the parent process?
07:25jyaI mean when is DeviceManagerDx::CreateCompositorDevice called on the various process (parent, content and gpu) ?
08:18jyawhat's the deal about having the D3D11DeviceStatus being sent over IPDL, yet, it's being reconstructed within the GPU (I mean DeviceManagerDx::CreateCompositorDevice always re-create a D3D11DeviceStatus object, ignoring whatever was sent though ipc)
08:21jyaor is it the other way, and it's only sent from GPU process down the parent one
08:21jyahmmmmm
09:01jyaok, so my understanding was incorrect. it goes GPU -> Parent, not the other way round. weird hwoever that gfxInfo isn't initialized while in the GPU process, you would think it's the most logical place to do it
09:37jyamattwoodrow|away: any particular reason gfxInfo isn't initialized in the GPU process (i need it to get the video driver version), and it need not be, how can I retrieve the driver version in the GPU process ?
09:38jyais see an ipdl for nsIGfxInfo, but I'm not sure if that's usable
13:07sewardjCan someone help me with class CanvasLayer in gfx/layers/Layers.h ?
13:21nicalsewardj: what's up ?
13:36sewardjnical: CanvasLayer::CanvasLayer(LayerManager*, void*) doesn't give an initial value for mSamplingFilter
13:37sewardjnical: and I think it should, because SetSamplingFilter() tests it
13:38nicaltrue that
13:38* nical wishes C++ would just not let you do that
13:40sewardjnical: I think that one effect is, that the call from SetSamplingFilter() to Mutated() is now random (whether or not it happens is random), for the first call to SetSamplingFilter
13:40sewardjnical: so .. ok .. what's the correct initial value? SamplingFilter::GOOD ?
13:41nicallooking at most of the places we use it I think that ::GOOD is the best default
13:43nicalsewardj, if you want to make a patch for it I'll give it the r+
13:43sewardjnical: ok, I'll file later this afternoon, then r? you\
13:43nicalthanks
13:45dvanderjya: which nsIGfxInfo call do you need?
13:45jyadvander: the driver version
13:46jyaso adapterDriver
13:47jyadvander: but maybe I'll go at it a different way, rather than determining if I can use a feature in the GPU process, I'll determine it in the parent one, and pass it to the GPU child at construction
13:47jyaseems weird however that the nsIGfxInfo not be available from the GPU process...
13:47dvanderjya: that's ideal... we might be able to let nsIGfxInfo initialize in the gpu process, but i'm not 100% sure if the sandbox will allow the calls we use to read the adapter version
13:48dvanderit is a bit weird
13:48jyadvander: the sandbox on the GPU process is less strict than the one on the parent process at this stage
13:48dvanderheh
13:50jyadvander: https://wiki.mozilla.org/Security/Sandbox#Current_Status sandbox level is 0 in the GPU process
13:50jyawhile at it, how does gfxInfo manages different drivers , how does it even check which one reported is related to the card in use?
13:50jyaseems to be using the first one it finds
13:51dvanderjya: iirc it reads fields out of the registry. it's different on every platform.
13:51dvanderhttp://searchfox.org/mozilla-central/source/widget/windows/nsWidgetFactory.cpp#228
13:52dvanderif you add Module::ALLOW_IN_GPU_PROCESS then nsIgfxInfo should become available
13:52dvanderyou'd have to change Linux/mac/android widgets too
13:52jyaawesome thanks !
13:53dvanderthe windows retrieval code (if that's what you're interested in) is here: http://searchfox.org/mozilla-central/source/widget/windows/GfxInfo.cpp#759
13:53jyayes, I read that code manytimes :)
13:54jyais there any potential downside on attempting to retrieve gfxInfo in the gpu process?
13:55dvanderprobably not? ithink it should have no startup cost. you just might hit an assertion or something and have to fix it
13:56jyaok... I'll try that then
14:34sewardjnical: filed
14:49nicalr+
15:00Gankrolsalzman: off the top of your head, do you know if apple's emoji font also uses variation info? Investigating a bug where emoji are sometimes smaller in webrender.
15:24gw280mattwoodrow: when are you here until
15:34Gankronical: ok if I wait for your refactor/rewrite PR to land before r+'ing the one based on it? Want to test locally that it fixes it.
15:39mattwoodrowgw280: Saturday afternoon
15:39gw280mattwoodrow: ugh you suck
15:39gw280mattwoodrow: ok, lunch tomorrow or friday?
15:39gw280which works best
15:39gw280or today I guess can work
15:39gw280LET ME KNOW
15:40mattwoodrowgw280: tomorrow?
15:40gw280mattwoodrow: ok, what time?
15:40mattwoodrowanytime! 12ish?
15:40gw280sounds good
15:41gw280bring chocolate or i stab you
15:41gw280<3
15:48pulsebotCheck-in: https://hg.mozilla.org/projects/graphics/rev/937bee9d2830 - Matt Woodrow - Make sure we remove RealDisplayItemData for StoreList
15:52jrmuizeldbaron: ping
15:56nicalGankro: sure!
15:57pulsebotCheck-in: https://hg.mozilla.org/projects/graphics/rev/09a67aab8e7c - Miko Mynttinen - Backed out changeset 2fcc09a13dae
15:58jyadvander: that got to be the world fastest review ever
15:58jyathanks
16:29dbaronjrmuizel: pong
17:04Gankromchang: can you check out this page? debugging emoji rendering https://gankro.github.io/blah/webtests/text.html
17:08Gankromchang: re-re-repeat: https://gankro.github.io/blah/webtests/text.html
17:28Gankrojfkthame: what version of macos are you?
17:28jfkthameGankro: i&#39;m on 10.12
17:28GankroDang, same
17:28jfkthameweird
18:17Gankrojfkthame: any idea what StyleContext()->IsTextCombined() is about?
18:18lsalzmanGankro: i don&#39;t know at all, you&#39;d have to use the same hack we used to figure out if the bold fonts were
18:19lsalzmanGankro: it would be worth trying just to see
18:19Gankrolsalzman: totally fair
18:19Gankrolsalzman: how far off is your patch? (pretty sure I can wait, it&#39;s an incredibly minor bug)
18:25lsalzmanwell, i have the basics in place enough to test with
18:25lsalzmanbut i don&#39;t know if it actually works yet
18:25lsalzmanif you were a brave sort, i could kinda bundle it up and you could try it
18:25lsalzmanit builds... not like that is much of a guarantee
18:30Gankrolsalzman: It&#39;s fine, it was more idle curiousity :)
18:30lsalzmanwell, still, would at least be good to know if the variation stuff is breaking other fonts than just bold
18:34jfkthameGankro: offhand i don&#39;t know, looking to see if anything about it jogs my memory....
18:35Gankrojfkthame: for whatever reason emphasis marks take a completely different path for it, seemed interesting
18:37jfkthameGankro: it&#39;s for a special CJK thing: in vertical writing mode, there&#39;s a convention where digits (including pairs, sometimes up to 4) can be written horizontally
18:37jfkthameso they appear orthogonally to the rest of the text line they&#39;re in
18:37jfkthameso it makes sense that if text-emphasis marks are applied to such a run, they&#39;d need special treatment
18:38jfkthame(not sure what the proper result is offhand - i&#39;d guess maybe they appear beside instead of above, or something)
18:41jfkthameGankro: example, data:text/html;charset=utf-8,<div style=&quot;writing-mode:vertical-rl;text-emphasis:&#39;*&#39;&quot;>%E4%BD%A0%E5%A5%BD<span style=&quot;text-combine-upright:all&quot;>12</span>%E4%BD%A0%E5%A5%BD
18:41Gankrojfkthame: neato
18:41jfkthamehere, the run &quot;12&quot; is &quot;combined&quot;, and gets a single emphasis mark beside, whereas otherwise you&#39;d have expected a mark above each digit
19:12Gankrojfkthame: emphasis marks are supposed to have shadows, right?
19:14jfkthamei would assume so
19:15jfkthameGankro: but apparently they don&#39;t
19:15jfkthameGankro: i guess that&#39;s a bug, unless there&#39;s some special rule i&#39;m not aware of
19:16Gankrojfkthame: yeah that&#39;s basically where I&#39;m at, just double-checking
19:16jfkthamei&#39;d suggest filing a bug and cc xidorn, he may know more about it
19:19Gankrojfkthame: oh weird, it looks like maybe the shadow isn&#39;t factoring them into the clip?
19:20jfkthamei wondered if it might be something like that
19:20jfkthameso we&#39;re trying to draw shadows but clipping them away?
19:21Gankrojfkthame: data:text/html;charset=utf-8,<div style=&quot;writing-mode:vertical-rl;text-emphasis:&#39;*&#39;;text-shadow:-2px 2px 3px red;&quot;>%E4%BD%A0%E5%A5%BD<span style=&quot;text-combine-upright:all&quot;>12</span>%E4%BD%A0%E5%A5%BD
19:21Gankro(zoom in)
19:21jfkthamesure looks like it
19:22Gankrofiling
19:22jfkthamesounds like it might be an easy fix, if we&#39;re lucky
19:23jfkthameanyhow, /me goes to eat dinner :)
19:25Gankrojfkthame: the bug doesn&#39;t affect webrender, since we take a wildly different path for shadows, so not a priority for me. I just noticed while tracking down transparent text bugs for wr :)
19:26jfkthamecool - we should still fix for regular gecko, though
20:05Gankrogw: could I tempt you into looking into https://github.com/servo/webrender/issues/1373 ?
20:06gwGankro: yep - I&#39;ll look at it today :)
20:07Gankro
20:19pulsebotCheck-in: https://hg.mozilla.org/projects/graphics/pushloghtml?startID=705&endID=706 - 2937 changesets - Merge with mozilla-central
20:54milanjfkthame, Gankro: the &quot;bug doesn&#39;t affect webrender...&quot; and &quot;we should still fix for regular gecko...&quot; - do we have a bug for this? If not, can one you drop it in? This is good information, don&#39;t want to lose it in IRC history :)
20:55Gankromilan: yeah my last filed bug, text:layout
20:56Gankro(On phone, hard to look up)
20:57Gankromilan: text-emphasis is really experimental though; chrome doesn&#39;t even impl it yet
21:03milanGankro: thanks!
23:31daoshengmujgilbert, I look forward your review https://bugzilla.mozilla.org/show_bug.cgi?id=1383907. Hope it can be on the ff57 train in time.
23:31firebotBug 1383907 NEW, dmu@mozilla.com Enable WebVR tests on macOS
14 Sep 2017
No messages
   
Last message: 7 days and 4 hours ago