Re: [dev-servo] WTF-8 encoding for DOM strings and HTML parsing
On Tue, Oct 7, 2014 at 3:57 PM, Henri Sivonen wrote: > > UTF-8 strings will mean that we will have to copy all non-7-bit ASCII > strings between the DOM and JS. > > Not if JS stores strings as WTF-8. I think it would be tragic not to > bother to try to make the JS engine use WTF-8 when having the > opportunity to fix things and thereby miss the opportunity to use > UTF-8 in the DOM in Servo. UTF-16 is such a mistake. > When I added Latin1 to SpiderMonkey, we did consider using UTF8 but it's complicated. As mentioned, we have to ensure charAt/charCodeAt stay fast (crypto benchmarks etc rely on this, sadly). Many other string operations are also very perf-sensitive and extra branches in tight loops can hurt a lot. Also, the regular expression engine currently emits JIT code to load and compare multiple characters at once. All this is fixable to work on WTF-8 strings, but it's a lot of work and performance is a risk. Also note that the copying we do for strings passed from JS to Gecko is not only necessary for moving GC, but also to inflate Latin1 strings (= most strings) to TwoByte Gecko strings. If Servo or Gecko could deal with both Latin1 and TwoByte strings, we could think about ways to avoid the copying. Though, as Boris said, I'm not aware of any (non-micro-)benchmark regressions from the copying so I don't expect big wins from optimizing this. But again, doing a Latin1 -> TwoByte copy is a very tight loop that compilers can probably vectorize. UTF8/WTF8 -> TwoByte is more complicated and probably slower. Jan ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Is bors asleep?
For some reason a single PR caused buildbot not to receive updates. I've temporarily closed that PR and it seems to have restored operation. I'll debug the PR that failed tomorrow morning. jack. On Tue, Oct 7, 2014 at 7:09 PM, Gilles Leblanc wrote: > In the build queue there are 5 approved but there doesn't to be any one of > those which are actually building right now or that have received any > ping-back comments from bors in the GitHub pull requests. > ___ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] WTF-8 encoding for DOM strings and HTML parsing
On Tue, Oct 7, 2014 at 6:57 AM, Henri Sivonen wrote: > On Mon, Oct 6, 2014 at 8:27 PM, Cameron Zwarich > wrote: > >> So you’re suggesting Servo could get away with UTF-8 in the DOM? I > hadn’t considered it. I remove my proposal at the start of this thread, I’d > like us to try this instead. > > > > UTF-8 strings will mean that we will have to copy all non-7-bit ASCII > strings between the DOM and JS. > > Not if JS stores strings as WTF-8. I think it would be tragic not to > bother to try to make the JS engine use WTF-8 when having the > opportunity to fix things and thereby miss the opportunity to use > UTF-8 in the DOM in Servo. UTF-16 is such a mistake. > I agree. There's an opportunity here to improve speed and memory usage while simplifying the overall engine design by having the whole engine use *TF-8 except for JS. We believe we can fix JS performance with a bounded amount of work, and we don't even have to do that work up-front since copying strings between JS and DOM is a viable solution for now. Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] The current scrolling model
On Mon, Oct 6, 2014 at 7:49 PM, Patrick Walton wrote: > On 10/6/14 7:44 PM, Boris Zbarsky wrote: > >> Just to check, what's the plan for doing "overflow: sticky"? And does >> this model handle position:fixed things that end up both above and below >> pieces of a single position:static thing? >> > > I'd have to page `position:sticky` information back into my brain, but I > can answer the second one, because it was needed for Acid2. When building > display lists, we keep track of display items that were supposed to go on > top of `position:fixed` and layerize them. This matches what WebKit does. > Note that we don't implement pseudo-stacking contexts correctly (and > neither does WebKit). > You can get away with that for position:fixed, but I don't think you can get away with that for overflow:auto/scroll. We find in Gecko many real situations where scrolled content for a given scrollable container has to be split into multiple layers because content from the container is interspersed in z-order with content that's not scrolling. Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] The current scrolling model
On 10/8/14 10:51 PM, Robert O'Callahan wrote: You can get away with that for position:fixed, but I don't think you can get away with that for overflow:auto/scroll. We find in Gecko many real situations where scrolled content for a given scrollable container has to be split into multiple layers because content from the container is interspersed in z-order with content that's not scrolling. Samples of such content would be really interesting to take a look at and make sure we handle. In general our approach is functionally identical to WebKit's, so I suspect that whatever WebKit does we can just copy. Patrick ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] WTF-8 encoding for DOM strings and HTML parsing
On Oct 8, 2014, at 10:48 PM, Robert O'Callahan wrote: > On Tue, Oct 7, 2014 at 6:57 AM, Henri Sivonen wrote: > >> On Mon, Oct 6, 2014 at 8:27 PM, Cameron Zwarich >> wrote: So you’re suggesting Servo could get away with UTF-8 in the DOM? I >> hadn’t considered it. I remove my proposal at the start of this thread, I’d >> like us to try this instead. >>> >>> UTF-8 strings will mean that we will have to copy all non-7-bit ASCII >> strings between the DOM and JS. >> >> Not if JS stores strings as WTF-8. I think it would be tragic not to >> bother to try to make the JS engine use WTF-8 when having the >> opportunity to fix things and thereby miss the opportunity to use >> UTF-8 in the DOM in Servo. UTF-16 is such a mistake. >> > > I agree. There's an opportunity here to improve speed and memory usage > while simplifying the overall engine design by having the whole engine use > *TF-8 except for JS. We believe we can fix JS performance with a bounded > amount of work, and we don't even have to do that work up-front since > copying strings between JS and DOM is a viable solution for now. I would be in favor of using UTF-8 in the DOM in Servo if SpiderMonkey would be willing to accept the maintenance burden of having a UTF-8 (WTF-8?) code path that is not used by Gecko. This doesn’t mean that they would have to implement it, just that if an implementation was produced they would be okay with maintaining it. I don’t think it would be good to choose UTF-8 in the DOM in Servo if SpiderMonkey is realistically never going to support it without copies. Cameron ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
