This applies to xp without acceleration:
1. Fx 15: grayscale aa in the urlbar
https://bugzilla.mozilla.org/show_bug.cgi?id=828073
2. Fx 18: bad cleartype (gamma?) on selected menu items
https://bugzilla.mozilla.org/show_bug.cgi?id=828192
3. Fx 27: grayscale aa in menus
https://bugzil
On Fri, Oct 11, 2013 at 10:23:20PM -0400, Kyle Huey wrote:
> Are you sure? I thought we killed pluggable decoders a while back.
Indeed. https://bugzilla.mozilla.org/show_bug.cgi?id=513681#c7
Mike
___
dev-platform mailing list
dev-platform@lists.mozilla
On 10/11/13 10:23 PM, Kyle Huey wrote:
Are you sure? I thought we killed pluggable decoders a while back.
Hmm. I didn't realize that. In that case, I'm not sure. :(
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists
Are you sure? I thought we killed pluggable decoders a while back.
- Kyle
On Fri, Oct 11, 2013 at 7:48 PM, Boris Zbarsky wrote:
> On 10/11/13 7:42 PM, Zack Weinberg wrote:
>
>> On 2013-10-11 1:08 PM, Ralph Giles wrote:
>>
>>> On 2013-10-10 12:28 PM, Steve Fink wrote:
>>>
>>> It seems like th
On 10/11/13 7:42 PM, Zack Weinberg wrote:
On 2013-10-11 1:08 PM, Ralph Giles wrote:
On 2013-10-10 12:28 PM, Steve Fink wrote:
It seems like the optimal efficiency vs surface exposure vs frequency
of use tradeoff would be to do everything but the top formats (JPG,
PNG, GIF?) in JS.
That's wha
On 2013-10-11 1:08 PM, Ralph Giles wrote:
On 2013-10-10 12:28 PM, Steve Fink wrote:
It seems like the optimal efficiency vs surface exposure vs frequency
of use tradeoff would be to do everything but the top formats (JPG,
PNG, GIF?) in JS.
That's what we do today. We support those three image
On 2013-10-10 12:28 PM, Steve Fink wrote:
> It seems like the optimal efficiency vs surface exposure vs frequency
> of use tradeoff would be to do everything but the top formats (JPG,
> PNG, GIF?) in JS.
That's what we do today. We support those three image formats with
native code, and others
On 13-10-10 4:25 PM, John Hopkins wrote:
>
> Project branches are cutting over to the new win64-rev2 build machines.
Project branch builds have run overnight on the new build machines and
are looking good.
We will continue migrating more branches next week.
John
> On 13-10-09 5:22 PM, John Hop
On Fri, Oct 11, 2013 at 2:47 PM, David Rajchenbach-Teller
wrote:
> I'd be happy if we could progressively kill FileUtils.jsm and make
> nsIFile [noscript]. Don't know if this qualifies as "platform feature",
> though.
Given that this is privileged functionality and not web-exposed, I
don't think
I'd be happy to mentor someone to rewrite them using OS.File.
On 10/11/13 3:28 PM, Axel Hecht wrote:
> Both are heavily used in the js build system for gaia, fwiw.
>
> Axel
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lis
On 10/11/13 2:47 PM, David Rajchenbach-Teller wrote:
I'd be happy if we could progressively kill FileUtils.jsm and make
nsIFile [noscript]. Don't know if this qualifies as "platform feature",
though.
Cheers,
David
Both are heavily used in the js build system for gaia, fwiw.
Axel
__
2013/10/11 Nicholas Cameron
> The advantage to me is that we have a single shader and avoid the
> combinatorial explosion when we add more shaders for things like SVG
> filters/CSS compositing.
[...snip...]
>
> I have not recently been discussing new shaders, perhaps you are thinking
> of msta
I'd be happy if we could progressively kill FileUtils.jsm and make
nsIFile [noscript]. Don't know if this qualifies as "platform feature",
though.
Cheers,
David
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listi
On Wed, Oct 2, 2013 at 10:33 PM, Erik Rose wrote:
> What features do you most use in MXR and DXR?
String search. Then identifier search. In this order, because I don't
trust the latter to recognize all identifiers. It would help to be
able to trust.
> What keeps you off DXR?
Main reason I've st
On Wed, Oct 9, 2013 at 7:01 PM, Gervase Markham wrote:
> * XSLT (Chrome have already announced they will remove it:
They said they'd remove H.264, too. I'm not a fan of XSLT, but we
shouldn't be the first one to remove it. I once had to fix a bug,
because XSLT was being used in Chrome Experiments
On Fri, Oct 11, 2013 at 10:24 AM, Matthew Gertner
wrote:
> On Thursday, October 10, 2013 7:23:44 PM UTC+2, Boris Zbarsky wrote:
>> Seems unlikely.
>
> Indeed, I completely misdiagnosed the issue. Upon further investigation it
> turns out that the external script is trying to set a property on a c
On Friday, October 11, 2013 5:50:05 AM UTC+13, Benoit Girard wrote:
> On Thu, Oct 10, 2013 at 7:59 AM, Andreas Gal wrote:
>
>
>
> > Rationale:
>
> > switching shaders tends to be expensive.
>
> >
>
>
>
> In my opinion this is the only argument for working on this at moment.
>
I think alm
On Thursday, October 10, 2013 7:23:44 PM UTC+2, Boris Zbarsky wrote:
> Seems unlikely.
Indeed, I completely misdiagnosed the issue. Upon further investigation it
turns out that the external script is trying to set a property on a chrome
object and that __exposedProps__ does not allow this. So co
18 matches
Mail list logo
