standups: go through webaudio specs and some gstreamer code. instructions unclear; convolved brain.

standups: also go through gecko webaudio code

standups: Started bashing my head against an SMup. github.com/asajeffrey/mozjs/tree/smup

Manishearth: For any normal text run, I think we can reasonably assume that the glyph offsets will be monotonic along one axis (depending on horizontal or vertical layout). Are you aware of any CSS features and/or esoteric languages where relying on that would be a bad idea?

Hello People

I have come here for asking for advice

I;m working on a GUI hobby project

and need your advice regarding interface architecture

we all know that every rendering platform has its quirk be it OpenGL or DIrectX o

......

I guess nobody is up so I should ask ..later on :(

hello

yo!

Wanted to start contributing

What would be a good first issue?

gw: iirc OpenType does glypb buffer reordering here?

hey Manish

gw: र्क्सis an example here the first code point is rendered after the second

hi

Are you on UI team for Servo

not exactlt but i do layout and style stuff sometimes

I need advice from the servo team for my personal GUI Project

as you guys are far more experienced than me.

In my library architecture to make it cross-platform as much as possible

what I want to do is the separate the Drawing Interfaces and Rendering Interfaces

Drwaing Interfaces are concerned with all the nifty calculation stuff and generate a command list

and pass it to the Rendering Interface

which is responsible for implementing those command on the specific platform be it OpenGLa nd DX

or something higher up like X which the GUI library shall not be concerned with

because

These platforms have so many quirks that nomatter how good code you architect sooner or later it becomes a Zombie

Icing on the Cake is : 1.)These things are constantly evolving

2.) backwards complexity

So my question is

Should I design Render Interface as something which exports its inteface(like plot pixe or draw rectangle)

to the Artist-iN-Chief of my GUI Library

or should I design Rendering Interface to just takes commands (CommnadBuffer) from The Artist-In-CHief

and implement it on the concerning platform in the best possible manner.

I incline towards second approach but I wanted to hea from the veterans who tread in the field

*shrug*

:(

gw: anyway, which ordering are you talking about? ordering of code points , or the glyph buffer?

bc the glyph buffer gets reordered

idk if it gets reordered *enough* to maintain this property

ajeffrey: ^ missed a couple things in the new session history

cbrewster: LGTM, especially the test! I wonder what other browsers do...

ajeffrey: good question. I only checked Firefox and it passes the test

cbrewster: the old perennial "what do existing browsers do?"

ajeffrey: “does anyone really know?”

cbrewster: "browser dev as an experimental science".

cbrewster: ajeffrey: Hixie has made a living doing that for a decade :)

Gee Dr Bossy Pants Debugmozjs, I get the message! irccloud.mozilla.com/pastebin/yFdvS710

more than a decade

ajeffrey: I think you might be leaking something... not sure

pcwalton: we're at the mozilla 20th anniversary, so probably two decades.

yeah

cbrewster: do you think so maybe?

the HTML5 parsing algorithm was done by painstakingly reverse engineering IE via experimentation

pcwalton: time flies when you're reverse engineering browser impls.

ajeffrey: I've been comparing the diff model with the list of trees from docs.google.com/document/d/1PDMf2NE…983SPx0/edit#heading=h.4hiubuvpsrtm

Our removal is doing the same thing, but we just look for BrowsingContextIds instead of comparing entire trees

cbrewster: interesting.

bz: ^

bz: context being that servo now has a list-of-tree-diffs implementation of session history, which is closer to the list-of-trees model.

jgraham: what is the polite thing to do about adding WPT tests that are spec-correct (er, we think) but fail on some browsers? servo/servo #20629/commits/787ec4b2093ca1402537e04df572984808e5fa10#diff-a5a5714efbcc52c35a65287121c6dd40

ajeffrey: To add them :)

The idea is that people notice they have failing tests and fix the code

SOme of the infrastructure to make that likely is still in development, however :)

hi there! I need to bump gleam's version from 0.4.29 to 0.4.33, how do I do that? just updating Cargo.toml and running build -d give sme errors

brainlessdeveloper: What sort of errors?

failed to select a version for `gleam` (required by `canvas`): all possible versions conflict with previously selected versions of `gleam`

brainlessdeveloper: Try `cargo update -p gleam`

@mbrubeck owch... I feel bad now, thanks

jgraham: ta

Does anyone want to update this crate to use syn 0.12? searchfox.org/mozilla-central/source/xpcom/rust/xpcom/xpcom_macros

oh wait, my tree was out of date

it's already at 0.13!

thanks to mystor

lol - wasn't me

mbrubeck: I wrote some old patches which were upped to 0.13 & landed

mbrubeck: I suppose they left my commit attribution

mbrubeck: lol

well thanks... eijebong, it looks like?

mystor: I did :)

You wrote the original patch, I wasn't going to steal authorship ;)

mbrubeck: You're welcome :p

*shrug* wouldn't have minded

eijebong: So now we just need to get servo/stylo onto 0.13 :P

mbrubeck: servo/servo #20611

woot!

But I really need help because it broke like 2 000 000 000 tests

oh god

Exactly

mbrubeck: Also taskcluster doesn't like my branch name :/

Oh and I can't even try to run them locally because servo doesn't compile, right...

emilio: ping ?

eijebong: pong-ish

(On phone)

emilio: Have you seen servo/osmesa-src #27 ?

eijebong: whoops, nope

emilio: :p

eijebong: looking now :)

emilio: :)

eijebong: I assume it was just running the update-mesa script, maybe to a given revision?

eijebong: rs=me if so

emilio: Yeah, I did and changed the version in Cargo.toml to match the mesa one

eijebong: awesome, thanks!

And I just ran it without specifyng a revision (sometimes after my patch to fix the build landed...)

Cool :) That should fix the build for me

eijebong++

eijebong: now I can go to run llvm trunk again :P

:D

Going to open a PR to update it in servo (but when I accidentally did, it broke the mac build :/

cbrewster: cool, #20629 landed.

Amongst other things, this means we now have a test for eager update of history.length.

standups: Got the smup to build with rustc 1.25 and a more recent bindgen. github.com/asajeffrey/mozjs/tree/smup

nox, I changed the commit message, can you please review? servo/rust-mozjs #422

standups: cbrewster and I are kicking the hornet's nest of session history again. whatwg/html #1454#issuecomment-380873532

standups: MR work week local organization.

ajeffrey++

emilio: build.servo.org/builders/mac-rel-wp…uilds/8386/steps/compile/logs/stdio :(

nox: marmistrz: one thing I have to address in the near future is that fitzgen's smup-smup-smup (which is the basis of my smup) is now quite far behind rust-mozjs.

eijebong: probably lacks a `#define`, but I don't have a mac to test / build

emilio: Me neither

This is related to where the master mozjs_sys and mozjs crates should live: m-c or github?

ajeffrey: cbrewster: do you know why the history of iframes includes the initial about:blank load?

fabrice: it shouldn't as of yesterday!

#20579 should cause the first "real" document to be loaded with replacement enabled.

ajeffrey: ok... in blink it's also there, which is fun because when you navigate in an iframe back to about:blank it actually blanks the parent

fabrice: hmm, that shouldn't happen! Hopefully the new shiny session history will be what you want.

cbrewster++

\o/

stop worries me in the case of reloading a discarded document

cbrewster: "stop"?

ajeffrey: see #20634

we technically go into an invalid state while reloading the document and back to a valid tree once or finishing loading

cbrewster: is there a "stop" in whatwg?

ajeffrey: haven’t looked

cbrewster: I think there's just the idea of pausing a page, putting it in the background, etc.

ajeffrey: yeah a quick search doesn’t show anything. But it’s something we would want to allow an embedded to do right?

cbrewster: it's something browsers do, so yes I guess so.

ajeffrey: unfortunately

cbrewster: ah! html.spec.whatwg.org/multipage/window-object.html#dom-window-stop

cbrewster: so stop() causes the page load to abort, which the constellation handles here github.com/servo/servo/blob/e4472f7…onstellation/constellation.rs#L1871

ajeffrey: ahh exposing that to the embedded should be easy then

cbrewster: we're not quite handling that right though :/

the spec html.spec.whatwg.org/multipage/browsing-the-web.html#abort-a-document says to cancel any fetches,

which we're only doing for immature documents, we should be doing it for mature ones too.

ajeffrey: oh interesting, not sure what that would entail

cbrewster: cancelling any ongoing loads, not sure what should happen if the user navigates to it.

That is presumably what the salvageable flag is for... html.spec.whatwg.org/multipage/brow…b.html#concept-document-salvageable

although there's no mention of unsalvageable documents in html.spec.whatwg.org/multipage/brow…sing-the-web.html#history-traversal

cbrewster: ah, when a document is unloaded, if it is unsalvageable then it is discarded: html.spec.whatwg.org/multipage/brow…sing-the-web.html#unload-a-document step 14.

ajeffrey: makes sense

cbrewster: and the current document is unloaded when the session history is updated: html.spec.whatwg.org/multipage/brow…e-session-history-with-the-new-page

in particular if it is traversed away from.

cbrewster: phew, so it looks like the session history part isn't so bad, we just need to track the "salvageable" flag for each pipeline.

if you like you can put scare quotes round "just".

ajeffrey: can probably mark this E-Easy

cbrewster: :)

cbrewster: E-Like-Anything-To-Do-With-Session-History-Is-Easy

Wish I would’ve known 2 years ago

cbrewster: you wanted to back out from all of this?

KiChjang: haha no, I enjoy it. Just had no clue the size of the yak I was shaving

cbrewster: E-Yak

cbrewster: a problem so E-easy I had to write a mechanized proof of correctness for it.

and even then that was just dealing with the "easy" case!

cbrewster: at some point we might want to revisit that arXiV paper and see if we can get it to cope with document unloading, discarding etc.

still haven’t even finished the History API which was the original goal

ajeffrey: yeah I think that would be good, also I would like to address Gecko’s implementation and the new diff one

cbrewster: yes, we should at least point out that the model is implementable as a list-of-diffs, and we can do a handwaving comparison to the list-of-trees model.

ajeffrey: sounds good