mozilla :: #gfx

11 Jul 2017
00:04rhuntGankro: hmm, we might be able to
00:05rhuntGankro: I&#39;d be worried about ambiguity, e.g. Foo<Bar<T>,i32> =? Foo<Bar<T,i32>>
00:05rhuntGankro: and also parsing the * const
00:06rhuntGankro: I don&#39;t really know yet though, I haven&#39;t given too much thought to a real implementation
00:06Gankrorhunt: yeah we&#39;ll need a custom parser for like [*const *mut [*const u8; 32]; 40]
00:06GankroBut I don&#39;t think it&#39;ll be *too* bad
00:08Gankrorhunt: what do you think about turning std::option::Option<u32> into namespace rust { namespace std { namespace option { struct Option_u32; } } } ?
00:08rhuntGankro: the ambiguity problem is the reason we require the `type Foo_i32 = Foo<i32>` and don&#39;t just assume they want Foo_i32
00:09rhuntalthough that causes a problem with RawVec then
00:09Gankrorhunt: you can do whatever you want with public: false types
00:09GankroSince no one should be touching them
00:12Gankrorhunt: you&#39;ll have fully qualified paths, so you can always disambiguate my_mod::Foo<T> from your_mod::Foo<T, i32> -- but it&#39;s a question of how nasty you want to mangle the types
00:12Gankronamespaces is one way to get around it
00:21rhuntGankro: hmm yeah, I&#39;ve been planning to convert mod&#39;s into namespaces for some time. I wouldn&#39;t want to mangle types without it
00:24Gankrorhunt: I updated the example output cpp: https://gist.github.com/Gankro/b4aa176f4db24671be66f2a3c57e487b
00:24GankroDoes that match what you&#39;re thinking of?
00:28rhuntGankro: yeah that looks good. just thought of this, but it might be nice to hardcode in some typedefs that match with the standard prelude
00:29Gankrorhunt: I was just writing an &quot;open question&quot; on whether the output should include typedefs for re-exports (the prelude is just a bunch of re-exports)
00:32rhuntGankro: I think that would certainly be nice, but not necessary.And currently cbindgen does not build fully qualified paths for every item, so it&#39;d require a bit of work.
00:33Gankrorhunt: if the output of this command is good enough, I&#39;d hope it should be relatively easy to build this stuff out
00:36rhuntGankro: oh, yeah you&#39;re right. I was thinking of tacking on this feature only for repr(rust) types, but this could replace all of that.
00:36rhuntGankro: it could replace everything except for the extern &quot;C&quot; fn gathering
00:36Gankrorhunt: added open questions to the end of the doc
00:37rhuntGankro: we currently decide what root types are from the types needed for all the extern &quot;C&quot; fn&#39;s
01:39gwGankro: around?
01:39Gankrogw: pong
01:41gwGankro: I&#39;m just starting to look at the text decoration stuff. I&#39;m thinking it may actually fit in simpler to the code if we don&#39;t have the push/pop text shadow - and just do the work in WR now to support the required text decorations. If we went down that path, I&#39;d also extend the text display item to handle glyphs from different fonts. Does that sound like it would cover the use cases we&#39;ve identified?
01:42Gankrogw: you want scoped shadows anyway so that you compute the shadows of multiple textrun fragments at once
01:43gwGankro: even if a single text run primitive is able to express different runs of font / size / glyphs?
01:44gwGankro: actually, this may be moot anyway - I think I can make it work internally the way I&#39;m thinking of with the push/pop interface anyway
01:44gwGankro: I&#39;ll do some prototyping over the next couple of days
01:45Gankrogw: you can theoretically add enough things to text to make it work, but push/pop ends up being the lowest overhead, and very easy for gecko/servo to implement
01:46Gankrogw: I have a fork of gecko that feeds webrender everything you see here: https://gankro.github.io/blah/webtests/text.html
01:46GankroStill cleaning it up, lemme know if you need it for testing
01:47gwGankro: yea, it should be doable, now that I think a bit more about the internals
01:47gwGankro: It&#39;ll probably take me a couple of days to get it hooked up and working - will ping you after that for more test cases :)
01:47Gankrocool beans
01:56gwkvark: Could be worth running this benchmark on various bits of hardware - https://twitter.com/nlguillemot/status/884581084448542722 - see if we can do better than the vertex shader fetching we do now.
01:57kvarkgw: interesting!
01:57kvarkwe aren&#39;t vertex bound though
01:57gwkvark: that&#39;s true, low priority for the future perhaps
02:25gwGankro: ah, now I recall why I was a bit unsure about the push/pop interface. That technically means you can construct a DL where items within the same text shadow group have different clips, scroll layers etc. Which is non-trivial to make work. I can&#39;t imagine situations where you&#39;d want to have that anyway, but it&#39;s unfortunate that the interface would allow that ...
02:25gwGankro: I&#39;ll do a bit more thinking this afternoon about that.
02:26Gankrogw: it would be reasonable to assume that doesn&#39;t happen?
02:27GankroBut also can you have different scroll layers for items in the same stacking context?
02:28gwGankro: you can, yes. I think it is reasonable to assume that it wouldn&#39;t happen in a text-shadow, it&#39;s just a bit of an ugly interface, since you can construct DLs that won&#39;t actually do what the interface suggests
02:28gwGankro: but we might just have to live with that for now, and consider tidying that up later
02:28GankroFair
02:29Gankro(Going to bed, feel free to leave me messages)
06:32pulsebotCheck-in: https://hg.mozilla.org/projects/graphics/rev/e15ab8769c15 - Timothy Nikkel - Don&#39;t clobber the value of mWillBuildScrollableLayer when we are building a display list for event handling.
14:14rhuntjrmuizel: how is ord derived for struct(u32, u32)?
14:15jrmuizelrhunt: presumably compare first member first and then the second member
14:15jrmuizelrhunt: https://doc.rust-lang.org/std/cmp/trait.Ord.html#derivable
14:17rhuntjrmuizel: oh duh. so are you proposing generating a way to call the derived Ord rust method? or just generating our own derived Ord C++ method?
14:18jrmuizelrhunt: basically adding the c++ comparison operator overloads to the generated c++ type
14:20rhuntjrmuizel: okay. we currently have a annotation for that, /// cbindgen:derive-lt
14:21jrmuizelrhunt: ah
14:21rhuntjrmuizel: but it doesn&#39;t work for more than one field member with < or <=
14:21rhuntjrmuizel: easy fix though
14:22jrmuizelrhunt: is it difficult to replace the annotation with a check for Ord being derived on the rust type?
14:23rhuntjrmuizel: probably not, i think that would be a good idea
15:25Gankro(checking if I broke something) -- does scroll-wheel scrolling not work if you enable webrendest right now? (keyboard arrows work fine)
15:43GankroAlso: who was the one who wanted consultation on all TextLayer changes?
16:19GankroBas: ^ ?
16:19BasGankro: You don&#39;t need to consult me on changes, just don&#39;t rip it out, and David Anderson might be interested.
16:20GankroBas: do you care if I rip out WebrenderTextLayer?
16:20BasNope
16:21GankroBas: do you care if nsDisplayText needs to do some extra conversions in the TextLayer path (with Webrender layerless being optimized for?)
16:21BasGankro: &#39;Not really
16:21GankroBas: cool, thanks!
16:22GankroBas: also do you know anything about the nsDisplayText::TryMerge? The code seems to be riddled with assertions that it&#39;s not actually being used?
16:23BasGankro: Nope, Matt Woodrow wrote that.
16:24kvarkgw: I&#39;m seeing the fastest route being Fied-Function AoS, which is good (read: expected)
16:25Gankromattwoodrow|away: ping -- I&#39;m making changes to nsDisplayText which necessitates a rewrite of TryMerge -- but I&#39;m seeing strange assertions about it not being used (MOZ_ASSERT(mMergedFrames.IsEmpty());) -- do you know what the situation is there?
18:11gerard-majaxlsalzman, ping
18:12gerard-majaxlsalzman, you should have received the tarball for bug 1378828 :)
18:12firebothttps://bugzil.la/1378828 NEW, nobody@mozilla.org Missing main titles on Wikipedia
18:12gerard-majaxlsalzman, as I said on the bug, I only see the issue on my laptop running Ubuntu 17.04, not on my desktop that runs Debian Sid
18:21lsalzmanyeah, i need to do some forensics on your fontconfig setup now to try and repro it
18:21lsalzmanthe main thing that jumped out at me is in the inspector screenshot
18:21lsalzmanit shows LinLibertineOB
18:21lsalzmanwhereas i see &quot;Linux Libertine O&quot;
18:22lsalzmanin both nightly and 54
18:22lsalzmanthat in itself is puzzling
18:22lsalzmansince none of the fonts i have analyzed with fc-query have that name
18:23lsalzmando you have any other sources of Linux Libertine fonts on your system than the fonts-linuxlibertine package?
18:24lsalzmanlike local font configs hanging around in your home directory?
19:50dvandermilan: lo and behold, turns out hang reporting doesn&#39;t work in the gpu process since it&#39;s structured differently than normal telemetry data. as in, we capture that hangs occur, but nothing can collect the data
20:39milandvander: not the best
20:41dvandermilan: no, im filing a bug. should it get some quantum triage flag?
20:42milanI&#39;d at least want cpeterson to know about it
20:50dvandermilan: ok, its bug https://bugzilla.mozilla.org/show_bug.cgi?id=1380144
20:50firebotBug 1380144 NEW, nobody@mozilla.org Collect hang information from the compositor process
21:07Gankromstange: http://smallcultfollowing.com/babysteps/blog/2017/07/11/non-lexical-lifetimes-draft-rfc-and-prototype-available/
21:33gwGankro: do you foresee any issues with adding a local_rect and local_clip param to your push_text_shadow interface? (this would allow supplying a clip region for a text shadow, and require user to submit a local bounding rect, which is already required for normal text items)?
21:34Gankrogw: should be fine, I think? should be the same as the text, possibly expanded and offset?
21:35gwGankro: should be the union of all the text items you&#39;re adding to this shadow, which is trivial to calculate, and is just the text rect in the common case.
21:35gwGankro: WR can internally do the expand based on the blur radius
21:35Gankrogw: ah yeah sure, I was thinking in gecko terms where we start with the &quot;full&quot; text bounds
21:36gwGankro: ok, cool. that simplifies the implementation greatly :)
21:36Gankrogw: about to submit a PR for the servo changes
21:36gwGankro: cool
21:36Gankrogw: should I just make it match my current API, and you can tweak it for the desired props?
21:37Gankro(I think everything you want is in the BaseDisplayItem)
21:37gwyep, that should be fine
23:58Gankrogw: kvark: data point on my weirdly small emoji being a subpixel/snapping thing: on a hidpi display they look perfect (I couldn&#39;t tell I was using webrender!)
12 Jul 2017
No messages
   
Last message: 12 days and 23 hours ago