On 7/7/14 6:17 AM, Manish Goregaokar wrote:
Teepee is the replacement for rust-http but it's progressing rather slowly
right now. It's also over-engineered (as Simon puts it), but it seems to
fix most of rust-http's problems. I guess we'll eventually be switching
over to Teepee.
That's not a
... and like magic, they have just appeared!
https://github.com/rust-lang/cargo#installing-cargo
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
Sorry about this; I didn't realize how far behind we were on posting
meeting minutes.
https://github.com/mozilla/servo/wiki/Meeting-2014-06-09 - (prebuilt
Rust status; next Servo workweek; Servo logo)
https://github.com/mozilla/servo/wiki/Meeting-2014-06-17 (Weekly
statuses; approval workflow
jack: We also had questions about replacing Azure with a thinner layer for
disk/memory reasons. We talked to Bas about our options. He has some ideas
already about what he wants to build as a new browser-focused graphics API
from scratch. But that would be a multi-year, multi-person project
- jack: can we avoid width recalc when changing vertical height?
pcwalton: that will break with vertical writing modes, among other
things. not sure it's a good optimization.
I'm not sure what jack had in mind exactly, but one very important
incremental layout case is appending
Sorry, I only just got to the workweek graphics meeting notes :-).
Servo will need to support 2D canvas, and it requires something like Moz2D.
So I think you're stuck with it or something like it.
I'll talk to Bas etc about fixing some of the resource management issues
your notes allude to in
On Jul 7, 2014, at 7:11 PM, Robert O'Callahan rob...@ocallahan.org wrote:
zwarich: JITting will give a huge benefit.
Are there experimental results showing this? Because I haven't seen any
yet, and I'd like to :-).
There is this blog post:
On 7/7/14 7:11 PM, Robert O'Callahan wrote:
Difficult, definitely. Performance problem ... now that we have incremental
CC and bunch of other optimizations, I feel like it isn't. At least
compared to any other viable GC approach, all of which have their own
performance pitfalls. Safety problem
On Mon, Jul 7, 2014 at 7:51 PM, Cameron Zwarich zwar...@mozilla.com wrote:
Are UTF8-backed (as opposed to Latin1-backed) JS strings with random access
going to be a real possibility in SpiderMonkey? It’s obviously possible to
make random access work with an appropriate indexing data
On Tue, Jul 8, 2014 at 2:51 PM, Cameron Zwarich zwar...@mozilla.com wrote:
Are UTF8-backed (as opposed to Latin1-backed) JS strings with random
access going to be a real possibility in SpiderMonkey? It’s obviously
possible to make random access work with an appropriate indexing data
On Mon, Jul 7, 2014 at 8:03 PM, Robert O'Callahan rob...@ocallahan.org wrote:
If you want to brainstom about getting to absurdly low memory targets like
32MB, I suggest talking to Nick Nethercote. This is where he lives.
I've already been asked about whether SpiderMonkey could be made to
work
On Tue, Jul 8, 2014 at 2:55 PM, Cameron Zwarich zwar...@mozilla.com wrote:
There is this blog post:
https://www.webkit.org/blog/3271/webkit-css-selector-jit-compiler/
I’m friends with the author and have anecdotal confirmation that the
improvements also occur on real web pages.
Good. I
On 7/7/14 8:07 PM, Robert O'Callahan wrote:
The pragmatist in me loves it :-).
There's probably a principled way to implement ForgetSkippable in a way
that's automatically checkable.
Having said all that, I'm not necessarily advocating GC+CC for Servo. It
is a hard and complex approach. I'm
On Tuesday 2014-07-08 13:46 +1200, Robert O'Callahan wrote:
- jack: can we avoid width recalc when changing vertical height?
pcwalton: that will break with vertical writing modes, among other
things. not sure it's a good optimization.
I'm not sure what jack had in mind
14 matches
Mail list logo
