hmmm i might work on near/far plane stuff since i'm only here for another day

ajeffrey: around?

Manishearth: yup

ajeffrey: so we derive projection matrices from near/far plane info. which can be changed by the user

similarly, view offsets can change if IPD changes (oculus quest lets you do this with a slider)

ajeffrey: what should we do so that Session can udpate its Views information on the script thread side?

could just send a message and capture the response, but that may not sync up with the next RAF that well

Manishearth: hmm, this is one of the things we punted isn't it?

so i'm thinking we send an update, and the RAF response contains a vec of extra events we need to take care of, and we apply that to the session

yes but i'm thinking i'll fix it tomorro

and fix some other small things that the api doesn't yet support

do we expect scenarios in which near/far is changing a lot?

or is it something where the changes are infrequent?

infrequent

typically just once

the problem is if it gets changed on the device thread but the script thread doesn't know yet

i guess they're supposed to be applied "on next raf" so we should just add a vec of events onto the raf

Manishearth: should we have a "session parameters have changed" event?

ajeffrey: basically yeah

and a function to just apply it to the webxr_api::Session object

i don't really like this but this is the best i can think of, wanted to make sure you were on the same page

this could incidentally also turn initial_inputs into just inputs() if we want

so at github.com/servo/webxr/blob/17dcfc9…5d68920f1/webxr-api/session.rs#L107

ajeffrey: just another field on the frame

ah, that would work too.

If we do that, can we get rid of github.com/servo/webxr/blob/17dcfc9…d68920f1/webxr-api/session.rs#L111?

ajeffrey: i wonder if r_a_f should also have an Option<(near, far)> argument to avoid having to send things separately

ajeffrey: no, some events can happen outside of raf

actually we can't do this for input events since an raf may not be active

Manishearth: oh that's annoying

er, input source change events

can we make "change the session params" an Event then?

ajeffrey: yes but then it doesn't sync with raf

(I'm trying to avoid having more than one sort of Event

)

Manishearth: won't it? Won't script get the rAF, and immediately drain the event receiver?

oh we won't need Option<(near, far)> since we can rely on the channel containing events in order

ajeffrey: who says script's event receiver will contain something at that point in time?

that's not guaranteed aiui

so any events that are sent before the rAF signal are guaranteed to arrive at the next rAF.

if you send on channel A then on channel B,

then another thread receives on channel B, it'll be guaranteed that the event on A will be there.

this is cross process, with routers involved

i don't think so

argh, the routers might mess that up :(

this sounds like a pickle we want to avoid

you may be right but i don't think it would be a good idea to rely on this kind of thing, it's extremely brittle

I'll add this to the list of things I'm not in love with about our ipc story :/

ipc plus threads plus routers = probably a couple grant-worths of concurrency headaches

indeed.

what we can rely on is if messages are sent through the *same* channel, they happen in order

on the other end

which we already do for set_texture in r_a_f

and we will do the same for a hypothetical set_clip_planes

pity routers are messing up the happens-before relationship that mpsc channels have :/

y'all are giving me concurrent ML flashbacks classes.cs.uchicago.edu/archive/201…300-1/lectures/ConcurrentML/CML.pdf

(slide 41ish)

because ANGLE doesn't use NT handles for share handles, this is going to be unbelievably ugly :\

going to have to write a garbage collector for surfaces

Manishearth: would you think it's good to add `[Default] toJSON` to test binding to test the default toJSON for #23844? 👀

cybai: yes

actually

maybe add a separate one for that?

unsure

we already have a bunch that effectively test this

Manishearth: yeah, I hesitated to ask this because I saw there're some test cases are now PASS-ed 👀 maybe it's fine to test it by those wpt 🤔

thanks!

Manishearth: happy with the removal of the immersive demo? I'd like to land that as soon as the servo control PR merges.

Manishearth: also - you're doing your train ride this week?

paul: yes

paul: yeah go ahead and land that

Manishearth: thanks.

maybe even land that first so both land

standups: Did a new rust-url PR review pass.

SimonSapin: Around?

Task "Servo daily: Linux x64: with Rust Nightly. On failure, ping: SimonSapin, nox, emilio" complete with status 'failed'. Inspect: tools.taskcluster.net/tasks/ADDkFhBjSGCEW__RV_-BFA

standups: Attended day two of ICFP SC.

Another meeting at lunchtime in Berlin.

ferjm: do you know what would be involved with enabling video controls on magicleap?

ajeffrey: good question. AFAICT controls should already be rendered inside the video by setting the `controls` attribute on the media element. However, these controls might not be usable or pretty enough on the ML. So we might want to have some custom controls (i.e. outside of the video window). In that case, we would need something like

ajeffrey: have you tried setting the `controls` attribute? (i.e. <video src="someurl" controls></video>)

Hmm, there is a controls attribute on view-source:https://servo.org/ml-home/rabbit.html

ferjm: but no controls are showing up :/

I see. Did you make any layout changes for the ML?

ferjm: nope

ferjm: is there some feature-detection that decides whether to use the shadow DOM controls?

ajeffrey: No, no feature-detection. This is probably because the media controls layout only works with block elements for now, and the video is inline by default. So you need to add something like "<style> video { display:block; } </style>" to that test page

ferjm: ah! I'll try that when I get in.

ajeffrey: ok, let me know if that works, please

ferjm: Hi! Thanks for the review, I will address the review comments now. I have two questions if you don't mind.

collares: np :) thank you for the PR!

1) I noticed I misread a couple of test outputs and some looping tests are failing. I then noticed I don't really relay the loop parameters to servo-media :) Should I do it via messages whenever SetLoop{,Start,End} gets called, or is it done automatically?

2) You mentioned we already receive "when" in AudioScheduledSourceNodeMessage, but AudioScheduledSourceNode processes that message and discards (truncates to a tick) the parameter. Is there a way to process the same message again? If not, I think I will leave the removal of the second when parameter to the ASSNode follow up

(Speaking of this, my juvenile side must link to github.com/WebAudio/web-audio-api/blob/master/index.bs#L3963 )

I can ask these questions in the PR if you want (even though ignoring looping parameters completely is a bit embarrassing :P)

collares: 1) Oh right. No, they are not passed automatically. Although they are probably given on node construction as well. I can check later

2) AFAICT there is no way to process the same message again, so let's leave it to the follow-up. lol... it took me a second to understand what you meant with ASSNode

ASSNode is the official spec term, as you can see :P

Thanks for the answers!

emilio: When is the new stable landing in stylo?

ajeffrey: can you try the thing on the ML with the two triangles with alpha values today?

Manishearth: OK, which URL should I look at?

nox: you mean rust stable right? bugzilla.mozilla.org/1574275 tracks it I guess it should land soon-ish

emilio: IIRC that's the first version with explicit enum discriminants wherever we want.

nox: oh even in ADTs?

emilio: Yes.

emilio: Never mind. rust-lang/rust #60553

TIL that MacOS freezes command-line processes if it goes into its screensaver,

so you can end up with builds taking 19hrs.

Manishearth: hmm, no gh-pages branch of github.com/manishearth/webgl-to-webxr?

SimonSapin: Btw, your alias mach=./mach trick,

I saw an interesting take on that,

it was about adding .git/trusted/../.. to $PATH, and then you do touch .git/trusted in repos you trust, or something like that. I thought it was cute.

cute indeed

though mine is not just an alias, it’s a script where I can export env variables

Manishearth: could you enable appveyor on servo/media?

I don't have admin access to the repo

ferjm: I already did

the next pull request should have it working

jdm: awesome, thanks!

SimonSapin: I appreciate how automated you made the process to create new windows build AMIs

jdm: it can still be improved but yeah I’m pretty happy about it

Just fixed -5 issues on servo/media, yay!

-6, actually, since the original PR didn't correspond to a filed issue

standups: More setting up ipc experiments.

emilio: aren't we trying to remove all visited-specific styling anyway since it's a tracking vector? or did I hallucinate that

standups: Get the video controls to appear on the demo video.

standups: 1:1s; investigating linker errors with new UWP rustc target; rebuilding windows AMIs with msbuild installed.

oho!

if I build with the existing x86_64-pc-windows-msvc target using lld-link.exe, no linker errors. if I build with that target and link.exe, linker errors. if I build with x86_64-uwp-windows-msvc and link.exe, a very similar set of linker errors.

ERROR: Cannot find llvm-objdump

does anyone know about this issue?

trying to build via ./mach build -d

running on archlinux

pylbrecht: Probably need to install some llvm stuff ?

eijebong: just installed llvm, currenlty building

eijebong: do your latest changes of servo/servo #23936 build?

pylbrecht: IIRC it did yeah

eijebong: alright, then I know that if my build fails, I messed something up. thanks

pylbrecht: I might have pushed some WIP

Oh yeah, to show raqote how I was using the PathBuilder::from

I think you need to cargo update -p raqote for it to build

(I was using a local one)

Clone not implemented for azure_hl::Path

but the PR got merged yesterday, right?

pylbrecht: Yeah but that's the azure backend. That one doesn't build for sure, I changed some signatures after fixing it

And you need to cargo update -p rust-azure I guess

eijebong: so I don't have to `git rebase master`, if I update raqote and rust-azure?

pylbrecht: Yeah I think it should be enough

And then add some mut in the azure backend if you want to fix it

Oh and you're probably building with the wrong feature name

yeah, that's the other error that came up when building

Which is why I guess you're getting azure errors which you shouldn't see if you were building the raqote backend

mhh, is there any way to speed up building?

pylbrecht: cargo install sccache && echo 'export RUSTC_WRAPPER="sccache"' >> ~/.zshrc

That helps a bit with full rebuilds I think

eijebong: uuhh, thank you

ajeffrey: was there a webxr-enabled three.js rollercoaster demo at some point, or am I dreaming?

jdm: the one I used was webvr not webxr.

standups: started to implement element.scrollIntoView needed for testdriver.js

standups: New ANGLE/D3D code for Servo WebGL is now written. This should allow us to fix flickering issues properly, while making future WebXR integration straightforward on Windows. On to debugging it.

pcwalton++

each EGLDisplay is now in a thread local, and the core transferable surface handle is a D3D share handle

they're reference counted, and there's a thread-local mapping from each EGLDisplay/EGLSurface pair to the D3D share handle

this basically gives Servo a Surface type that it can share freely among threads and bind to a texture on any thread and it should "just work"