On 25 April 2013 16:11:59, Justin Lebar wrote:
Which specific proposals should we start with? As you say, there are dozens
of ideas out there, none with any kind of consensus behind them.
If a preponderance of options is actually the only thing standing in
the way of serious and timely work bei
On 18/04/2013 11:02, Ed Morley wrote:
On 17/04/2013 20:51, Ms2ger wrote:
On 04/17/2013 09:36 PM, Gregory Szorc wrote:
It /could/, sure. However, I consider auto clobbering a core build
system feature (sheriffs were very vocal about wanting it). As such, it
needs to be part of client.mk. (Please
Just my opinion on this, I don't care enough to argue it more than this;
rm -rf in response to configure, by default, is *not*
expected, or reasonable behaviour. Rather than having an environment
variable to turn this off, it should be the other way round. I can see
people getting caught out
On 12 February 2013 21:57:53, Clint Talbert wrote:
I agree in part with the assertion about testing - that the existing
reftests will catch most regressions stemming from this. But I think
we also need some measurements around scrolling/responsiveness in
order to verify that off main thread paint
On 12 February 2013 13:05:33, Jean-Marc Desperrier wrote:
Matt Woodrow a écrit :
to improve both performance and responsiveness of the browser, we are
planning on moving painting to happen on a separate thread.
I think you should take some time to consider what impact it has on
the synchroniza
Sounds good, I'd like to help if I can. How would this affect the
display-list optimisation process - would we transfer across the
unoptimised display list and re-optimise and process for each viewport
change? I assume with OMTC, we'd still async scroll like we do now, but
paints would just com
6 matches
Mail list logo
