mozilla :: #gfx

7 Aug 2017
17:28pcwaltonnical: just FYI, Im starting on the OpenGL port of Pathfinder 2 the prototype is done and working to my satisfaction. Ill be testing the OpenGL port with a WebGL based demo
17:29nicalpcwalton: nice! what technique did you settle for?
17:30pcwaltonnical: I have a couple of options one is supersampling with Loop Blinn, the other is a MLAA-inspired technique where (1) I draw a non-antialiased scene first with Loop Blinn; (2) perform edge detection and stencil out edges; (3) use exact area coverage with the shoelace formula to precisely antialias the edges
17:31pcwaltonnical: Im pretty excited about the second technique, because its the first thing Im aware of that gives exact area coverage but avoids cracks where two shapes meet on subpixel boundaries
17:31pcwaltonits quite fast too
17:32nicalI like the idea of only performing aa for stuff that is actually visible
17:32pcwaltonyes, its a huge win
17:32nicalquite often you spend time doibng aa for your fill shape and you stroke it with something opaque right after
17:33pcwaltonconceptually its the same as Pathfinder 1, but uses absolute coverage instead of delta coverage (because we have a mesh we can do this), and it avoids branching in the shader by using the shoelace formula (Greens Theorem) instead of as bunch of ad hoc area calculations
17:33pcwaltonbecause its absolute coverage we dont need the compute shader anymore
17:33pcwaltonand because it uses Loop-Blinn for the prepass and computes Bezier curve intersections in the fragment shader it doesnt need tessellation either
17:34pcwaltonin fact Im pretty sure its WebGL 1 (plus widely supported extensions) compatible :)
17:34nicalso you are using a monotone tessellator which separates out quadratic bziers ?
17:34nicalwhat does your geometry look like?
17:35pcwaltonyeah, its based on trapezoids where the legs are quadratic beziers
17:35pcwaltonB-quads Im calling them
17:37nicalby the way, you have a TODO about the representation of Point2D<f32> and the thing you use for ffi
17:37nicaleuclid types are repr(C)
17:37pcwaltonIm about to nuke BTW
17:37pcwaltonoh, ok
17:37pcwaltongreat :)
17:37nicalso you your are guaranteed to have the rigth layout
17:38pcwaltonLoop Blinn was a great idea, thank you for that
17:38pcwaltonit makes the Dutch rail map way faster
17:38pcwaltonin fact its near 60 FPS now
17:39nicalI have been itching to try to implement something like this for about two years, but it&#39;s just two much for my brain after a day of work and just a few hours to spare
17:39pcwaltonyeah, its simple in retrospect but getting here was hell :)
17:39pcwaltonI feel embarrassed that its taken so long but thats how it always goes
17:40nicalI spent a bit of time looking into the details of fastuidraw btw
17:40nicalit is interesting to look into because they spend a great deal of effort into culling
17:40pcwaltonon CPU?
17:41nicalyeah, all of the geometry is baked into tiles and batches are builtuploaded lazily
17:41pcwaltondo they use the Z buffer?
17:41nicalI don&#39;t think that they use the z buffer the way we do (they use it for clipping without aa)
17:42nicalbut I am not 100% sure about that
17:42pcwaltonwe used to spend a lot of effort doing that kind of thing in WR and it always ended up being a net loss because its almost impossible to beat the Z buffer on CPU
17:42pcwaltonbut it may well be worth continuing to try
17:42nicalI think that they do well at memory management
17:43pcwaltongw said that he finally got WR GPU bound on most web pages for the first time (yay!)
17:43nicalI don&#39;t know how much memory the dutch rail map ends up occupying, but their approach would scale well even if you don&#39;t have a lot of memory available
17:43pcwaltonit would be nice for the Dutch rail map because the Dutch rail map is actually vertex bound
17:43pcwaltonit has ~2 million vertices
17:43pcwaltonthe reason why I havent done it yet is that it doesnt help when youre zoomed out
17:44pcwaltonit helps when youre zoomed in to reduce the number of vertices but zooming out is still slow because the whole thing is visible
17:44pcwaltonwhat might help is switching to some form of triangulation to avoid creating so many Steiner vertices
17:44pcwaltonbut Im not smart enough to make that work right now :)
17:45nicalone thing at a time :)
17:45pcwaltonits so much faster than the CPU though that Im not going to let the perfect be the enemy of the good
17:45pcwaltonPathfinder is ridiculously faster than Core Graphics
17:45pcwaltonat this point
17:46nicalanother thing that I found refreshing is seeing that fastuidraw nudges coordinates to avoid cases where the tessellator breaks down due to floating point precision
17:47nicalsince precision bugs have been the thing I spent the most time on at this point
19:25lizzardcan anyone here give a quick review to bug 1386263 ?
19:25firebot NEW, Perma failure when 56 merges to beta application crashed [@ nsLayoutUtils::SurfaceFromElement(mozil
19:48RyanVMjgilbert: hola!
19:52jgilbertRyanVM, hey!
19:52RyanVMso, Canada&#39;s on strike^H^H^H^Hholiday today
19:53jgilbertohh, right
19:53RyanVMhow chafed do you think Milan would be if we landed that pref flip with his review pending? :)
19:54jgilbertI think it should be fine
19:54jgilbertsince it&#39;s just a pref change and it can unblock beta
19:54RyanVMagreed, can always flip it back if/when the issues get sorted out
19:55RyanVMlizzard: ^
19:57RyanVMjgilbert: I&#39;m debating resolving that bug vs. leaving it open for the follow-up work that&#39;s needed on trunk
19:58jgilbertlet&#39;s file a new bug for getting it working again
19:58RyanVMjgilbert: thanks for digging in on that :)
20:44pulsebotCheck-in: - Miko Mynttinen - Use correct frame for nsDisplayTableBackgroundImage bounds calculations
20:44pulsebotCheck-in: - Miko Mynttinen - Removed unused nsDisplayItem::mHasSavedState
21:09gwnical: jrmuizel: regarding the crazy texture cache memory usage, I recall nical saying somewhere that gecko doesn&#39;t re-use image keys across frames. If that&#39;s true, that&#39;s probably likely to explain the issues of the texture cache size?
21:09jrmuizelgw: we don&#39;t reuse for blob images
21:09jrmuizelgw: or rather blob images that change
21:09gwjrmuizel: ok. but image masks do get re-used?
21:10jrmuizelgw: I believe they do though I could be mistaken
21:11gwjrmuizel: ok. might be worth checking the number of Image Templates listed in the WR on screen profiler next time we look at the texture cache memory - see if that&#39;s growing each frame.
21:11jrmuizelgw: we&#39;re working on fixing things to update instead of add/remove
21:11gwjrmuizel: cool
21:13nicaljrmuizel gw: gecko appears to be allocating silly big masks
21:14gwnical: jrmuizel: I thought that might be the case - silly big masks are bad for memory, but also force things into the alpha pass instead of the opaque pass, so disable any Z optimizations too...
21:14gwnical: So it&#39;ll be a double win if we fix those :)
21:15nicalI haven&#39;t looked into it yet, by I suppose we used to clip drawing (and therfore masks) to the visible region and now we generate masks of the size of the display item or something silly like that
21:16nicalthe big masks are definitely an issue on gecko&#39;s side
21:21nicalgw: do you know a good heuristic to catch pcwalton on irc ?
21:22gwnical: I haven&#39;t found one with better success than random()
21:22tomprincejrmuizel: Do you have any idea what might be causing ?
21:22firebotBug 1385950 NEW, dom/media/tests/mochitest/test_peerConnection_captureStream_canvas_webgl.html fails on updated docke
21:23nicalgw: ha :) well if you see him first, you can let him know than fastuidraw is also writing into the depth buffer while drawing. it&#39;s a bit hard to tell from apitrace if they are drawing opaque stuff front to back like we do but I don&#39;t see why they would write onto the z buffer otherwise
21:24gwnical: ok, will pass that one
21:24nicalwe were wondering about that earlier today
8 Aug 2017
No messages
Last message: 14 days and 8 hours ago