Hi, this plan looks like a great improvement over the current state of
webgl in servo.
> * WebGL commands are currently run in the WR backend thread which could
> be
> bad for UI latency (see https://github.com/servo/webrender/issues/607)
Yeah, thanks for getting rid of this!
> The connection be
Anyone interested in implementing WebAudio and/or WebRTC (in Gecko
there's some overlap in the underlying infrastructure) should first
spend some time discussing the architecture with Paul Adenot (look for
padenot on irc). Having a competitive or even just decent WebAudio
implementation is more com
I'll add that without fuzzing, it would very hard for us to do things
like switch from a Moz2D backend to another or change the way we do
drawing (like enabling tiling), because these things mean some rounding
happens in slightly different ways and anti-aliasing is particularly
sensitive to this. F
About mozlando, I'm always game for a gfx chat!
Cheers,
Nical
On Tue, Oct 13, 2015, at 02:25 AM, Lars Bergstrom wrote:
> https://github.com/servo/servo/wiki/Meeting-2015-10-12
> ___
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists
Another thing worth thinking about is to have some of the animated
content rendered directly in the compositor without being stored in a
layer. The Blink folks have a project along these lines. If we know that
the portion that is animated is simple enough that we can render it at
60 fps, caching it
t I call
a scenegraph.
On Wed, Nov 12, 2014 at 3:08 AM, Robert O'Callahan
wrote:
> On Wed, Nov 12, 2014 at 2:49 PM, Nicolas Silva
> wrote:
>
>> If you guys ever have the resource to roll your own rasterizer, I would
>> strongly suggest that you don't build an im
Hi, I was a bit surprised to see my name in the meeting minutes. I
sometimes spend some spare time toying with 2d rendering on the gpu but it
is really a side project and nothing like a serious one (Gecko keeps me
busy enough that it's hard to find the will to hack on something else in my
spare tim
A blinking caret in an input text filed, maybe ? It's very common on the
web, the number of pixels that needs to be repainted is very small and it
happens somewhat continuously, so invalidating only the few pixels around
the caret ends up saving a lot over a minute.
Cheers,
Nical
On Tue, Oct 28,
The copy-on-write lock is just an atomic reference count that we put in
shared memory when doing multi-process.
On Wed, Jul 2, 2014 at 5:49 PM, Patrick Walton wrote:
> On 7/2/14 5:51 AM, Nicolas Silva wrote:
>
>> In the "internal buffer" scenario, we don't need to cr
We have two kinds of textures: the zero-copy ones such as Gralloc buffers
on B2G or DXGI textures on D3D11 (we talk about "direct texturing" because
we paint directly into the texture that we use for compositing) and the
ones that have implicitly an internal buffer, for example some shared
memory t
Hi there,
A few words about TextureClient/Host (since it's been mentioned in this
thread):
we have a bit of design doc about it at:
* http://dxr.mozilla.org/mozilla-central/source/gfx/doc/MozSurface.md
* http://dxr.mozilla.org/mozilla-central/source/gfx/doc/SharedMozSurface.md
Basically TextureC
11 matches
Mail list logo
