Let's get rid of it.
Patrick
On Jan 29, 2018 4:22 PM, "Paul Rouget" wrote:
> AFAIK the CEF port is not used by anyone, is not maintained, and is
> not tested. I'm not even sure it works.
>
> I believe the CEF port should be a 3rd party project, and it should
> not rely on Glutin.
>
> Dropping C
Works for me.
Patrick
On Oct 25, 2017 12:38 PM, "Josh Matthews" wrote:
Actually, I'm considering adding cocoa-rs to the mix as well, since it
relies on core-graphics. Why not merge core-foundation-rs, core-text-rs,
and core-graphics-rs into the cocoa-rs repository (while keeping the crates
sepa
Super excited to see this. Awesome!
Patrick
On Sep 20, 2017 9:03 AM, "Till Schneidereit"
wrote:
> Hello friends of Servo!
>
> We're happy to announce the availability of a pre-alpha version of
> libservo, a Rust embedding API for Servo.
>
> You can find documentation for the API and a tutorial
These seem like exactly the goals I'd come up with, as an occasional
contributor to the DOM. +1!
Patrick
On Wed, Dec 14, 2016 at 9:03 AM, Josh Matthews
wrote:
> Hey everyone! It's time to make plans for 2017, so here are my thoughts on
> the subject. I think we should focus on the following hig
Thanks everyone! Based on the feedback, I've submitted a PR to do this:
https://github.com/servo/servo/pull/13590
Feel free to leave comments on it.
Patrick
On Thu, Sep 29, 2016 at 6:26 PM, Patrick Walton wrote:
> Hi,
>
> Given stshine's fantastic work implementing fle
Hi,
Given stshine's fantastic work implementing flexbox, I'm wondering whether
it's worth turning it on by default now. At the very least, I think turning
it on should be easier than flipping nearly a dozen preferences. :)
Flexbox is getting pretty important in rendering the Web (see [1] for an
e
> The current openssl bindings are not good. Take a look at Servo's
openssl related bugs for some examples. As far as I know the Rust
community is not super interested in fixing this, or at least it
hasn't happened yet. With most of the big players abandoning openssl
in general, it is easy to see w
> In my opinion, web compatibility should be a goal of Servo.
I agree. However, it's worth noting that layout and DOM bugs and missing
functionality currently prevent far more than 7% of Web sites from working.
In these areas, it will take significant time to get to 90%+ Web
compatibility. (Grante
> rusttls doesn't seem to support TLS 1.1, which seems like a
non-starter. We'll probably want to dig up some data on how much of
> the web relies on that.
> libwebpkix does not yet support revocation checking.
They don't support those things now, but will they support them on Servo's
timeframe?
First of all, thanks for putting this together!
I'm in agreement with Brian that *ring* and rustls seem like the way to go
first. Second, I would suggest rust-native-tls as a backup if it doesn't
work out.
*ring* *is* BoringSSL -- at least the crypto primitives from it -- wrapped
into a nice Rust
It's not a stupid question :) I actually think we should gather all script
and layout threads together into one process. Maybe two, one for
high-security sites and one for all other sites.
Patrick
On Aug 2, 2016 6:47 PM, "Paul Rouget" wrote:
> On Tue, Aug 2, 2016 at 6:47 PM, Jack Moffitt wrote
Note that WR is now keeping the DOM up to date with the current scroll
offset (or at least as close to "up to date" as you can be with APZ) so
this could reasonably be done DOM-side, I imagine.
Patrick
On Jun 17, 2016 4:02 AM, "Josh Matthews" wrote:
> While listening to the Gecko platform talk a
Display lists are serializable, so it seems difficult to store futures
there. The Fragment seems like the natural place for them. I concur with
mbrubeck that some kind of future seems like the right solution here.
Patrick
On May 25, 2016 6:35 PM, "Matt Brubeck" wrote:
> In ancient double-digit-i
I'm pretty sure auto fallback would be doable.
Patrick
On Wed, May 4, 2016 at 1:31 PM, Jack Moffitt wrote:
> > So is the idea that people without the ability to use webrender would
> need
> > to use the -c flag? The linux machine I use for Servo development yields
> the
> > "GL context creation
I think we may not be doing cross-thread GL context flushing correctly.
Without that we're pretty much guaranteed to have every GL test be an
intermittent.
Patrick
On Apr 22, 2016 2:55 AM, "Ms2ger" wrote:
> Hey folks,
>
> I just disabled the WebGL conformance test suite. Too many of them are
> h
Keep in mind that Servo without WR doesn't do dirty rects and invalidation
either. (I had patches to do it but they weren't complete and bitrotted.)
The question in my mind is whether it'd be better to build the CPU fallback
on top of WebRender or whether it's best to build it on top of Skia. Ther
Exciting, thanks a ton for your work here!
I'm guessing that number_of_pseudo_contexts exists so that when a new
pseudo-SC is created we know what index to assign it?
Patrick
On Jan 24, 2016 8:46 AM, "Martin Robinson" wrote:
> Hello Servo people! I've been working on a proof of concept for a ne
Well, the idea here is to test the case in which the object isn't layerized
for some reason--say, the object was moving by animating "margin-left" in
JavaScript and it had complex Z-ordering constraints that caused whatever
layerization heuristics the browser had to fail, causing a full repaint of
I usually use two groups, but I'm about ready to give up, since it seems
impossible to maintain without tool support. Count me in for one group.
Patrick
On Aug 25, 2015 8:52 AM, "Jack Moffitt" wrote:
> > I’m in favor of a single alphabetical-order group.
>
> Nicholas's points are all valid, and
I'm personally totally fine with reusing C++ code here. I suspect that
rewriting the shader validator in Rust is lower-priority than, say,
rewriting image decoders in Rust, and we can't avoid shipping a shader
validator.
Patrick
On Mon, Aug 10, 2015 at 2:06 PM, Emilio Cobos Álvarez
wrote:
> Hi
Alex Crichton tells me that Cargo can do debug+opts, with debug=true in a
custom profile.
On Jul 27, 2015 4:22 PM, "Robert O'Callahan" wrote:
> Why can't you debug with sandbox enabled?
>
> Seems to me Rust needs to be able to build with optimizations and debugging
> diagnostics both enabled, and
nual
serialization and deserialization code, worry about OS primitives, or even
write in a separate "serialization" or "protocol description" language, as
the compiler integration handles all of this for you.
Thanks for helping Servo become a multiprocess engine!
Patrick
On Sun
y
> curious if you have a sense for how long it will take to get this landed
> and whether there’s anything we or the Rust team can do to speed things
> along.
> - Lars
>
>
> On Jul 24, 2015, at 11:03 PM, Patrick Walton wrote:
>
> Oh, I forgot to mention 2D canvas and We
Oh, I forgot to mention 2D canvas and WebGL. This implies a moratorium on
all new canvas or WebGL functionality.
Patrick
On Fri, Jul 24, 2015 at 8:45 PM, Patrick Walton wrote:
> As most people know by now, I'm having a lot of trouble getting
> multiprocess Servo landed :) Much of
As most people know by now, I'm having a lot of trouble getting
multiprocess Servo landed :) Much of the trouble here is that changes keep
coming in that are not multiprocess safe, and as multiprocess tends to
trigger random test failures it ends up being a never-ending losing battle
to keep up wit
k
On Jun 19, 2015 8:34 AM, "Andrew McCreight" wrote:
> On Fri, Jun 19, 2015 at 3:21 AM, Robert O'Callahan
> wrote:
>
> > On Fri, Jun 19, 2015 at 7:10 PM, Patrick Walton
> > wrote:
> >
> > > In theory you can use cmsg on POSIX systems to send channels
-channels working again, but I think it won't be more than a
week's worth of work to do things the clean way.
Patrick
On Jun 18, 2015 11:04 PM, "Robert O'Callahan" wrote:
> On Fri, Jun 19, 2015 at 12:45 PM, Patrick Walton
> wrote:
>
>> It's fine to
It's fine to pass channels over channels as long as those channels don't
cross process boundaries. In that case, the paint task lives in the chrome
process (since it has access to the GPU), so you're fine. The problematic
cases are essentially {script,layout} <-> (anything else).
Patrick
_
Hi everyone,
I'm rebasing my multiprocess patch and found that many of the new features
that have landed were implemented in a way that was incompatible with
multiprocess Servo. In particular:
* WebDriver passes channels over channels between script and the chrome
process.
* Canvas relies on pas
On Wed, Mar 25, 2015 at 12:19 PM, Josh Matthews
wrote:
> Second, but not less !important: How difficult could layerizing the canvas
>> and sharing the textures be, and where should I start looking at? The
>> initial idea is to start using a readback strategy, but I don't want to
>> discard other
We always know which properties are to be updated for all CSS transitions,
so will-change doesn't make things any better. will-change can help us
decide when to layerize elements, however, which can allow us to start the
animation faster if the element wasn't already layerized.
Patrick
On Sat, Ma
, 2015 at 8:03 AM, Patrick Walton
> wrote:
>
>> A hypothetical requestAsyncAnimationFrame() API whose callback had no
>> general access to the DOM and window object (though you could, for
>> example,
>> pass specific DOM objects in to mutate their styles) would solve t
is just wasted cycles
> and memory.
>
> Cheers,
>
> Nical
>
> On Sat, Mar 21, 2015, at 07:27 PM, Patrick Walton wrote:
> > Hi everyone,
> >
> > I've been thinking about ways that Servo's architecture can result in
> > user
> > experience im
ged from isolated JS contexts (i.e. JS contexts that would be safe
to run off the main thread).
Patrick
On Mar 21, 2015 11:50 AM, "Josh Matthews" wrote:
> On 2015-03-21 2:27 PM, Patrick Walton wrote:
>
>> One remaining issue is how to deal with jQuery-style animations that a
Hi everyone,
I've been thinking about ways that Servo's architecture can result in user
experience improvements in common Web patterns today. One particularly
relevant thing that's becoming clear is that Web pages often animate CSS
properties that require reflows in current Web browsers. Google ha
Sure, I agree that if you're doing custom layout languages (Cassowary,
etc.) Houdini is a win—the comment was more directed toward use of Houdini
to reimplement layouts that can already be described with CSS. For those
use cases, without seeing any numbers, I'm unconvinced of the performance
benefi
also
allow us to do things like layerize individual element backgrounds based on
heuristics. But it may not be a high-priority optimization for real content.
Patrick
On Mar 14, 2015 10:34 PM, "Patrick Walton" wrote:
> Well, I don't know how to without sacrificing incremental
ext affects the rendering, fall
back to readback. This is a performance hazard, of course, but I suspect it
wouldn't trigger on much if any real-world content.
Patrick
On Mar 14, 2015 10:21 PM, "Robert O'Callahan" wrote:
> On Sun, Mar 15, 2015 at 6:10 PM, Patrick Wal
We can only layerize stacking contexts, since we have no FrameLayerBuilder.
So we have to promote canvases to stacking contexts if we want to layerize
them. WebKit does the same thing.
Patrick
On Mar 14, 2015 10:08 PM, "Robert O'Callahan" wrote:
> On Sun, Mar 15, 2015 at 6:38
So readback is definitely the easiest way to get started, but obviously it
won't work long-term.
The right way is to create a new type of layer, a CanvasLayer, that
encompasses a native shared surface shared between the WebGL task and the
compositor. A "native shared surface" is the same OS-specif
> 2) UIWorker: some kind of JS worker that receives callbacks during
composition; each callback can take inputs such as time and scroll
position(s) as inputs and can update certain CSS properties (e.g.
transforms, opacity) on elements that the compositor then uses.
>
>
How should we explain the CSS
One important thing to consider is that in order to be multiprocess-safe we
cannot be passing around channels. Instead we need to either (a) use
request IDs and stream everything over one (or a small number of) file
descriptors or (b) pass file descriptors over IPC using the OS-specific
APIs in ord
On 11/12/14 12:04 PM, Andreas Gal wrote:
We should experiment with parallel software rendering. Using skia on
many cores might be faster than using D2D in practice, for example.
Andreas
Glad to hear you say that, because the first part of that experiment
(parallel CPU rendering) is already don
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, and display text.
No. SVG, border-radius (rounded borders plus
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, and display text.
No. SVG, border-radius (rounded borders plus
On 11/9/14 4:31 PM, Josh Matthews wrote:
I don't have any experience with these matters, but would this impact
our ability to support the will-change CSS property? As I understand it,
in Gecko the property basically means "layerize this".
`will-change` creates a new stacking context per the spe
Some other things that come to mind:
* This approach makes it trivially possible to incrementalize display
list construction at the granularity of stacking contexts. Which,
admittedly, is not a great level of granularity for many common
scenarios, but it would at least handle stuff like settin
Hi everyone,
My initial work on the implementation of `opacity`, as well as
discussions with Martin Robinson last week, have begun to make me wonder
whether we should modify Servo's layerization/display list model
somewhat. Currently, the output of layout (i.e. what layout sends to the
painti
On 11/8/14 11:09 PM, Simon Sapin wrote:
Could you add the caveats at the top of the spreadsheet itself, for
people coming from Twitter?
Done.
Additional caveat: just because a property has high usage doesn’t mean
we should implement it in Servo.
For example, the 'zoom' property is non-standa
Hi everyone,
I've created a simple chart of Servo CSS property support vs. usage
(taken from Chromium's usage charts at [1]). This may be useful if
you're looking for something to implement :)
https://docs.google.com/spreadsheets/d/1CxLS8w8GwK-2euVErrqpUUb76PiZa6w5h5EnGsL9KFs/edit?usp=sharing
On 10/28/14 2:40 PM, Robert O'Callahan wrote:
OK, but I still have the general question of how your overflow-based
invalidation handles reflows. The basic problem is style changes to
element A can result in geometry changes to element B where B is not a
descendant of A. For example suppose conta
On 10/28/14 1:46 PM, Robert O'Callahan wrote:
For example, suppose I have a regular document that's shorter than the
whole window and I append some text to the bottom. The height of the
grows. Depending on the styles on the , e.g. the value of
'border-radius' and certain 'background' values, you
Hi everyone,
Conversations last evening with roc got me to thinking about
invalidation some more. Currently, Servo repaints the whole displayport
on every change. This is obviously not going to work in the long run. At
the same time, we actually benefit in some ways from not doing
invalidatio
On 10/27/14 9:11 PM, Simon Sapin wrote:
This means using results (for a subtree) of our third traversal in the
first traversal. Can we do that without compromising parallel layout?
Not really (at least, not easily), but if it's just for a rare case
involving mixed-writing-mode documents, I'm h
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 be
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, b
On 10/6/14 7:14 PM, Josh Matthews wrote:
Could you clarify how CSS animations and transitions are related here?
Sure. For optimum performance, browsers with accelerated and
off-main-thread compositing have traditionally run a subset of CSS
animations/transitions (those that require no complex
On 10/6/14 5:17 PM, Martin Robinson wrote:
There isn't a lot in the way to extend this model to
overflow:scroll. The layout code would simply need to make a layer for
the content inside the scrolling flow and a layer for the scrolling
root. The two main dependencies for this would be:
a. Adding
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 with SpiderMonkey in its current state is to use
JSString for your string type. You cannot safely grab the c
On 9/28/14 9:30 AM, Josh Matthews wrote:
Right, but that's predicated on the existence of Web Components which is
going to be a gigantic project in all likelihood. I'm just seeing how
useful some small form control code written in Rust ends up being, but
I'm stuck on the layout bits.
So I guess
On 9/28/14 8:12 AM, Josh Matthews wrote:
I started trying to implement really basic form controls, and I've
become stuck on my under-developed layout knowledge. HTMLInputElement is
special, because it has no DOM children and instead needs to perform
layout based on its value attribute (which cont
On 8/29/14 5:27 AM, Lars Bergstrom wrote:
In general, I'd be a little wary of adding global locks into Servo
unless it's really necessary (i.e., if it turns out we can't
architect away the race condition Cameron brought up in any other
way). Since we haven't found a good way to do any concurrent
I believe the answer today is "nothing"--i.e. it's a Servo bug. Clark's work
doubles as a nice way to fix it :)
Patrick
On August 28, 2014 7:18:27 PM PDT, Robert O'Callahan
wrote:
>On Fri, Aug 29, 2014 at 2:10 PM, Patrick Walton
>wrote:
>
>> It might
ng that layout still can’t occur
>unless forced by script.
>
>Cameron
>
>On Aug 28, 2014, at 7:10 PM, Patrick Walton
>wrote:
>
>> It might happen if layout is flushed from outside the script task;
>window resizing/device rotation being what immediately comes to mind,
>
It might happen if layout is flushed from outside the script task; window
resizing/device rotation being what immediately comes to mind, as today in
Servo those events go straight from compositor to layout without hitting the
script task at all. (As an alternative design, we could route such eve
On 8/28/14 6:06 PM, Cameron Zwarich wrote:
I assumed that was the case, but was going to wait for his response before the
obvious follow-up question. We did a similar thing with iOS WebKit: a recursive
mutex that was only released on the turn of an event loop. It was universally
regarded as be
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 be higher, even in the uncontended case.
Is it strictly enforced that the script task neve
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 OS I/O primitives and Rust channels, and the
problem of having a task that processes events from b
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?
http://llvm.org/docs/LangRef.html#llvm-lifetime-start-intrinsic
Use of lifetime markers is
On 7/10/14 9:46 PM, Nicholas Nethercote wrote:
Does Rust have any stack-measuring capabilities?
It doesn't; let's definitely file a Rust issue on that.
The reason why Rust stacks don't go through jemalloc and instead mmap
directly is because of the desire to place guard pages, I believe.
Hi
On 7/9/14 2:48 PM, Robert O'Callahan wrote:
If you think so, then I think we *should* be considering GC+CC for Servo.
Crazy idea: could it even make sense for JS GC to use a traced nursery
and a refcounted+CC tenured space?
This is more or less how RC-immix works, right?
http://users.cecs.anu
On 7/8/14 1:23 PM, smaug wrote:
In general issues with GC handling are security bugs, but in CC they
lead to leaks.
This is not the case in Servo, though; we should be foolproof for both.
I'm definitely not willing to compromise on memory safety. :)
Blink doesn't have a collector for refcou
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 sti
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 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
On 7/2/14 5:51 AM, Nicolas Silva wrote:
In the "internal buffer" scenario, we don't need to create a new shmem or
swap back and forth between the front and back textures if the compositor
is done uploading the texture. So we have a lock that the content thread
takes when painting and that is rele
On 6/30/14 6:20 PM, Robert O'Callahan wrote:
Yes. But if you haven't got robust support for D3D10 and Android gralloc
and Windows Media Foundation accelerated video decoding and all that
sort of thing, you probably don't have the design right unless you're
cleverer and luckier than the rest of us
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 interfaces
correct across many platforms with multi-process and robustness in the face
of crashes and platform quirks has proven to be
On 5/29/14 8:39 AM, Simon Sapin wrote:
I’m aware that every style struct must contain either only inherited
properties, or only reset (non-inherited properties). Other than that,
what’s the guiding principle to decide how many structs to have, and
which properties go where? Why not have every lon
On 5/27/14 11:04 AM, Simon Sapin wrote:
On 27/05/2014 18:14, Patrick Walton wrote:
On 5/26/14 3:11 PM, Simon Sapin wrote:
I’m fine with that, but I’m more interested in the signature than the
naming. That is, which of these (or others) to have, for each private
field?
fn(&self) -> T
On 5/26/14 3:11 PM, Simon Sapin wrote:
I’m fine with that, but I’m more interested in the signature than the
naming. That is, which of these (or others) to have, for each private
field?
fn(&self) -> T
fn(&mut self, T)
fn(&'a mut self) -> &'a mut T
Hmm. My gut tells me the first and the third.
On 5/26/14 2:52 PM, Patrick Walton wrote:
(In general, I find that single-letter abbreviations read better when
squished up next to the word they go with, without underscores. Just
personal preference, I guess.)
Compare e.g. "xrange" in Python versus a hypothetical "x_range&quo
On 5/26/14 2:44 PM, Simon Sapin wrote:
Unlike C++, Rust does not have method overloading so the accessors are
much more verbose.
`nscoord ISize(WritingMode aWritingMode) const` overloaded with
`nscoord& ISize(WritingMode aWritingMode)` becomes
`get_i_size(&self, mode: WritingMode) -> T` and
`set_
On 5/7/14 11:16 AM, Josh Matthews wrote:
In the worst case, you have a GC hazard that is conceivably exploitable
if the stars are in alignment.
How would you create a `JS` on the stack? I would think that they
aren't cloneable and the constructor for them is appropriately private.
Patrick
_
On 5/3/14 12:30 PM, Josh Matthews wrote:
Learn to love it. When you find a type error where something is asking
for a JSRef and you're not providing it, that's a potential GC hazard
that the compiler is rejecting.
Kudos! This is a major milestone.
Patrick
_
On 4/23/14 6:06 PM, Boris Zbarsky wrote:
On 4/23/14, 8:53 PM, Brian Anderson wrote:
We're assuming nobody is going to be attacking Rust symbols though
Oh, right, that's the other worry.
We've had security issues in the past due to things like being treated as a file input by some parts of th
On 4/19/14 11:20 PM, Boris Zbarsky wrote:
On 4/19/14, 2:38 PM, Patrick Walton wrote:
Any thoughts?
I agree that the speculation described will typically succeed.
The only worry I have is that the idea of doing stuff for an element
then redoing it again if we discover it wasn't right set
Hi everyone,
I had an idea for how to handle block formatting contexts impacted by
floats in a way that doesn't sacrifice parallelism, with some
speculation. I'd like to get feedback on people's intuitions as to (a)
whether this is likely to pay off; (b) whether this works :)
Recall that blo
On 4/16/14 1:11 AM, Simon Sapin wrote:
On 15/04/2014 06:00, Patrick Walton wrote:
Hi everyone,
I'm considering using 32-bit fixed-point (16 bits for the fraction, 16
bits for the integer portion) for percentages in CSS. The reason is that
we can use the following four SSE4/AVX instructio
Hi everyone,
I'm considering using 32-bit fixed-point (16 bits for the fraction, 16
bits for the integer portion) for percentages in CSS. The reason is that
we can use the following four SSE4/AVX instructions on x86 to compute
two sides at once:
; xmm0 contains the style values (percentag
On 3/31/14 3:10 AM, Niko Matsakis wrote:
Interesting thought. You could also use an embedding involving either
coded no-ops at the start of each instruction and/or an unconditional
jump over some meta-data. This would reduce coupling at the cost of
somewhat more memory. Naturally you'd want to me
On 3/29/14 7:22 PM, Patrick Walton wrote:
On a related note, I have been tossing around ideas today for using
SIMD to match multiple selectors that have the same "shape" in
parallel. For example, if we have ".foo #a" and ".bar #a" it may be
possible to use the pac
ll). So I'm filing it into the "potentially interesting
project, not a high priority" mental bin. Could be neat though.
Patrick
On March 29, 2014 6:55:41 PM PDT, Boris Zbarsky wrote:
>On 3/29/14 8:23 PM, Patrick Walton wrote:
>> This is just 29 bytes of code when assembled. Thi
Hi everyone,
I've been discussing this idea with a few people in person over the past
week, and nobody told me it was completely insane. ;) So I thought I'd
send this idea around.
By now many people have heard of WebKit's CSS JIT. It's a surprisingly
small amount of code. One of the issues t
On 3/24/14 1:41 PM, Patrick Walton wrote:
That's what we're doing. "flow-based" was an inaccurate description.
I should elaborate: what I was planning on doing is to have frame
construction's notion of a DOM node be an abstraction that's either a
real DOM node
On 3/24/14 1:40 PM, Robert O'Callahan wrote:
We have multiple layers support. I reworked because it was bogus, but it's
a hard problem with iframes in multiple threads
Would it be helpful to explain how multiprocess layer trees work in Gecko?
Sure, any info is helpful.
Very different than
As a follow-up, I profiled a synthetic approximation of selector
matching on the AMD Kaveri (AMD A10-7850K 3.70 GHz quad-core CPU +
Radeon R7 8-compute-unit GPU). This is a new "APU", released in Q1 this
year, which has an integrated CPU and GPU on the same die and
cache-coherent memory accesse
Hi everyone,
Over the weekend I created a small repo to play around with selector
matching on the GPU:
https://github.com/pcwalton/selectron
There's a rough prototype of selector matching in there, with CPU,
OpenCL (GPU and CPU), and CUDA versions. I've only tried it on my MBP's
GeForce GT
On 3/6/14 11:13 PM, Henri Sivonen wrote:
I think the biggest unknown is memory management.
Is this the only thing that's blocking compilation
Unfortunately it's not. Some other problems I ran into:
OK. It looks like writing a new parser directly in Rust (possibly
using a translated Tokeniz
On 3/4/14 8:32 PM, Josh Matthews wrote:
I was actually thinking that we could rewrite methods that look like this:
fn TakesANode(node: &JS)
to read as follows:
fn TakesANode(node: &JS) {
let node: JS = NodeCast::from(node);
That would enable passing any Node-derived type as a parameter;
un
1 - 100 of 205 matches
Mail list logo
