Shouldn’t the focus be on power rather than raw performance?
In terms of the work that has to be performed for rendering web pages, GPUs
should be more power efficient than CPUs, especially with some of the mobile
GPU architectures. There is a question of whether all of the layers of
abstractio
> On Nov 11, 2014, at 4:55 PM, Andreas Gal wrote:
>
> Does anyone have profiling numbers that Azure on top of Skia has a measurable
> performance overhead?
The overhead referred to here is administrative overhead. We pull in other
pieces of Gecko outside of Azure proper in order to use Azure i
On Nov 11, 2014, at 1:19 PM, Patrick Walton wrote:
>
> On 11/11/14 1:02 PM, Robert O'Callahan wrote:
>> https://github.com/servo/servo/wiki/Workweek-rasterization
>>
>> We talked about writing our own rasterizer, which makes sense because web
>>> pages only render solid colored rectangles, image
On Nov 11, 2014, at 1:21 PM, Robert O'Callahan wrote:
>
> https://github.com/servo/servo/wiki/Workweek-alt-js
>
> I'm pleased with the "Table discussion until mid 2015" outcome :-).
>
> It might make sense at some point to have a "super secure Servo" build
> where you plug in a JS interpreter a
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
On Oct 6, 2014, at 3:49 PM, Boris Zbarsky wrote:
>> Is there any particular place where you feel there is tension between the
>> goals of memory usage and performance?
>
> I don't know yet. I mean, for charAt, sure. ;)
JS engines have been using ropes for quite some time now, which means tha
On Oct 6, 2014, at 2:49 PM, Boris Zbarsky wrote:
> On 10/6/14, 10:27 AM, Cameron Zwarich wrote:
>> This is an increase in memory usage over all existing engines
>
> Is it an increase over Gecko?
If Servo used UTF-8 strings in the DOM, then it wouldn’t be able to use
JS_NewEx
On Oct 6, 2014, at 9:00 AM, Simon Sapin wrote:
>> For me, absent evidence, it's much easier to believe that using WTF-8
>> instead of potentially ill-formed UTF-16 would be a win for the JS
>> engine than to believe that using WTF-8 instead of UTF-8 in the DOM
>> would be a win.
>
> So you’re su
On Oct 5, 2014, at 7:49 PM, Boris Zbarsky wrote:
> On 10/5/14, 7:51 PM, Cameron Zwarich wrote:
>> Are there any plans to eliminate the copies in Gecko?
>
> No. Measurement showed that in practice the cost of copying short strings,
> which most of these are, is very low. For
On Oct 5, 2014, at 3:08 PM, Boris Zbarsky wrote:
> On 10/5/14, 2:27 PM, Cameron Zwarich wrote:
>> I am opposed to anything that requires string copies between the DOM and JS
>
> The only way to do that with SpiderMonkey in its current state is to use
> JSString for your
On Oct 5, 2014, at 3:13 PM, Patrick Walton wrote:
> On 10/5/14 3:08 PM, Boris Zbarsky wrote:
>> On 10/5/14, 2:27 PM, Cameron Zwarich wrote:
>>> I am opposed to anything that requires string copies between the DOM
>>> and JS
>>
>> The only way to do that wi
On Oct 5, 2014, at 2:05 PM, Ms2ger wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/05/2014 08:27 PM, Cameron Zwarich wrote:
>> If JS can’t handle WTF-8 natively, then what’s the benefit of
>> using it? I am opposed to anything that requires string c
If JS can’t handle WTF-8 natively, then what’s the benefit of using it? I am
opposed to anything that requires string copies between the DOM and JS, unless
there’s some really great overriding reason.
Cameron
On Oct 5, 2014, at 9:26 AM, Simon Sapin wrote:
> We’ve discussed using UTF-8 interna
I filed both of the issues discussed on this thread:
https://github.com/servo/servo/issues/3187
https://github.com/servo/servo/issues/3188
Cameron
On Aug 28, 2014, at 7:20 PM, Patrick Walton wrote:
> I believe the answer today is "nothing"--i.e. it's a Servo bug. Clark's work
> doubles as a n
On Aug 28, 2014, at 5:45 PM, Clark Gaebel wrote:
> Running this on Firefox takes 500 ns/iteration. Chrome takes 700 ns/iteration.
>
> Servo before [1] lands took 8100 ns! That's paying a lot (some would say too
> much) for a parallel architecture, when simple queries experience a 10x
> slowdow
;Callahan
> wrote:
> On Fri, Aug 29, 2014 at 12:56 PM, Cameron Zwarich
> wrote:
>
> Is it strictly enforced that the script task never sees inconsistent views
> of layout? This came up in the other thread about threading, but what
> prevents this incorrect scenario?
&g
On Aug 28, 2014, at 6:00 PM, Patrick Walton wrote:
> On 8/28/14 5:56 PM, Cameron Zwarich wrote:
>> It’s nice that it’s so close to the competition. It would be interesting to
>> see numbers on ARM as well, since the relative cost of the atomic
>> instructions might b
It’s nice that it’s so close to the competition. It would be interesting to see
numbers on ARM as well, since the relative cost of the atomic instructions
might be higher, even in the uncontended case.
Is it strictly enforced that the script task never sees inconsistent views of
layout? This ca
On Aug 26, 2014, at 8:39 PM, Patrick Walton wrote:
> On 8/26/14 4:25 PM, Cameron Zwarich wrote:
>> Cons:
>> - Still requires an abstraction layer for features that differ across
>> platforms, unless we fix a target platform.
>> - There is a semantic gap between
Due to the recent news from the Rust workweek regarding the pending removal
libgreen from the standard distribution (and any support in related libraries
like I/O, locking, etc. that goes with it) there has been a bunch of discussion
about Servo’s use of threads and tasks. This discussion has ta
Are we going to move mozilla/servo to servo/servo?
Cameron
On Jul 21, 2014, at 9:31 AM, Simon Sapin wrote:
> Hi all,
>
> The mozilla-servo "organization" on GitHub was just renamed to "servo".
> GitHub automatically sets up web and git redirects for the repositories, so
> everything should J
On Jul 11, 2014, at 2:15 PM, Patrick Walton wrote:
> On 7/11/14 12:54 PM, Cameron Zwarich wrote:
>> These giant numbers aren’t too surprising, since LLVM isn’t that
>> great at optimizing stack space. Is Rust inserting the lifetime.start
>> and lifetime.end markers?
>&g
On Jul 11, 2014, at 12:04 PM, Brian Anderson wrote:
> Rust does have 2MB stacks by default. These giant numbers are surprising.
These giant numbers aren’t too surprising, since LLVM isn’t that great at
optimizing stack space. Is Rust inserting the lifetime.start and lifetime.end
markers?
http
On Jul 9, 2014, at 2:48 PM, Robert O'Callahan wrote:
> On Wed, Jul 9, 2014 at 8:23 AM, smaug wrote:
>
>> In general issues with GC handling are security bugs, but in CC they lead
>> to leaks.
>>
>> I could note that max median CC times have been lower than max GC slice
>> times at least since
On Jul 7, 2014, at 7:11 PM, Robert O'Callahan 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:
https://www.webkit.org/blog/3271/webkit-css-selector-jit-compiler/
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 structure, but popular JS
benchmarks are pretty sensitive to string performance.
Camer
On Jul 7, 2014, at 6:39 PM, Robert O'Callahan wrote:
>> 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 sc
ompositor without copies early
> on, since it is rather hard to retro-fit the constraints of shareable
> textures into the rendering code after the fact, and that as long as there
> are textures being copied, they will show up in profiles.
>
> Sorry for the long email, don't he
We discussed this a bit on #servo, but it isn’t obvious from your diagram if
every Layer will have child layers, or if that will be reserved for specific
container layers.
CoreAnimation takes the former approach, but I think the latter might be more
applicable for Servo, since it would give a b
On Jun 30, 2014, at 6:20 PM, Robert O'Callahan wrote:
> On Tue, Jul 1, 2014 at 11:46 AM, Patrick Walton
> wrote:
>
>> On 6/30/14 4:44 PM, Robert O'Callahan wrote:
>>
>>> BTW have you or anyone else working on Servo looked at
>>> TextureClient/TextureHost in Gecko? Getting buffer management int
This might be an interesting benchmark for Servo:
https://www.webkit.org/blog/3395/speedometer-benchmark-for-web-app-responsiveness/
Cameron
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
31 matches
Mail list logo
