Hi,
I have two different applications , both of them use gecko SDK version 2.0 for
embedded browser. On retina machine , one of the applications shows clear
retina supported text while other browser on other application shows blurred
text on retina machine.
I am not sure what is missing that
On 30.05.14 08:38, bhargava.animes...@gmail.com wrote:
Hi,
I have two different applications , both of them use gecko SDK version 2.0 for
embedded browser. On retina machine , one of the applications shows clear
retina supported text while other browser on other application shows blurred
On Friday, May 30, 2014 8:22:25 AM UTC+3, Matt Woodrow wrote:
Thanks Avi!
I can reproduce a regression like this (~100% slower on
iconFade-close-DPIcurrent.all) with my machine forced to use the intel
GPU, but not with the Nvidia one.
Indeed, and it's not the first time we notice
On Friday, May 30, 2014 1:25:33 PM UTC+3, avi...@gmail.com wrote:
FWIW, IE is able to maintain 100% smooth scrolling on some really complex
pages even on a _very_ low end Atom system (Intel iGPU), while Firefox
doesn't come anywhere near it.
Of course, I'm hoping that APZ and maybe tiling
On (2014年05月29日 23:01), Mike Hoye wrote:
On 2014-05-28, 9:07 PM, Joshua Cranmer wrote:
Two more possible rationales:
1. The administrator is unwilling to pay for an SSL certificate and
unaware of low-cost or free SSL certificate providers.
2. The administrator has philosophical beliefs
On Thu, May 29, 2014 at 12:27 AM, Daniel Holbert dholb...@mozilla.com wrote:
For now, our code isn't clean enough for this sort of static_assert to
be doable. :-/ And we have at least one instance of a refcounted class
that's semi-intentionally (albeit carefully) declared on the stack:
There are likely two causes here.
First, until we have APZ enabled its very unlikely that we can ever maintain a
high frame-rate scrolling on low-end hardware. OMTC is a prerequisite for APZ
(async pan/zoom). Low end hardware is simply not fast enough to repaint and
buffer-rotate with 60FPS.
On 30/05/2014 14:19, Andreas Gal wrote:
Now for Intel hardware being slow there could be a couple reasons, and APZ
might fix them actually. If I remember correctly Atom GPUs are PowerVR based,
which is a tile based rendering architecture. It splits the frame buffer in
small tiles and
On Friday, May 30, 2014 5:06:52 PM UTC+3, Gabriele Svelto wrote:
On 30/05/2014 14:19, Andreas Gal wrote:
If you can point us to some specific hardware we really suck on we can
definitely look into this.
Sure, and the hardware specs are also available at bug 894128 comment 0.
100% smooth
On 30.05.2014 07:28, Matt Woodrow wrote:
I definitely agree with this, but we also need OMTAnimations to be
finished and enabled before any of the interesting parts of the UI can
be converted.
Given that, I don't think we can have this conversation at the expense
of trying to fix the current
On Friday, May 30, 2014 5:48:26 PM UTC+3, avi...@gmail.com wrote:
On all these systems, Firefox is far behind IE on this front, but with
margins getting lower as the systems get stronger (i.e. in order of
presentation - old atom, new atom, i7+hd4000).
And just to complete the picture, the
Summary:
The Loop project aims to create a user-visible real-time communications
service for existing Mozilla products, leveraging the WebRTC platform.
One version of the client will be integrated with Firefox Desktop. It is
intended to be interoperable with a Firefox OS application (not part
On Fri, May 30, 2014 at 5:03 PM, Adam Roach a...@mozilla.com wrote:
Link to standard: N/A
I take it this means there's no web-exposed API?
--
http://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
On 5/30/14 10:14, Anne van Kesteren wrote:
On Fri, May 30, 2014 at 5:03 PM, Adam Roach a...@mozilla.com wrote:
Link to standard: N/A
I take it this means there's no web-exposed API?
That is correct. This is a browser feature, not accessible from content.
--
Adam Roach
Principal Platform
Please read my email again. This kind of animation cannot be rendered with high
FPS by any engine. It's simply conceptually expensive and inefficient for the
DOM rendering model. We will work on matching other engines if we are slightly
slower than we could be, but you will never reach solid
Just as a quick follow-up to this - we're already seeing much lower
checkin-needed backout rates since this change went into affect, so thank you
all for your help!
-Ryan
- Original Message -
From: Ryan VanderMeulen rvandermeu...@mozilla.com
To: dev-b2g dev-...@lists.mozilla.org,
On Friday, May 30, 2014 6:16:53 PM UTC+3, andre...@gmail.com wrote:
Please read my email again.
It was provided as an objective data and subjective assessment - and not as an
opinion, in reply for your request for more info on systems where we suck, if I
understood your request correctly.
On 27/05/14 19:44, Chris Pearce wrote:
Encrypted Media Extensions specifies a JavaScript interface for
interacting with plugins that can be used to facilitate playback of DRM
protected media content. We will also be implementing the plugin
interface itself. We will be working in partnership
On 29/05/14 07:01, Mike Hoye wrote:
It's become clear in the last few months that the overwhelmingly most
frequent users of MITM attacks are state actors with privileged network
positions either obtaining or coercing keys from CAs,
I don't think that's clear at all. Citation needed.
I think
On 28/05/14 17:49, Joshua Cranmer wrote:
* Insufficiently secure certificate (e.g., certificates that violate
CA/Browser Forum rules or the like. I don't know if we actually consider
this a failure right now, but it's a reasonable distinct failure class
IMHO)
We would refuse e.g. a cert
On Tuesday, 27 May 2014 15:12:56 UTC-7, Robert O'Callahan wrote:
On Wed, May 28, 2014 at 6:14 AM, kgil...@mozilla.com wrote:
Is this behavior acceptable or would it be more desirable to always return
the actual scroll position in DOM methods?
All DOM methods that depend on the
On 5/30/2014 12:00 PM, Gervase Markham wrote:
On 28/05/14 17:49, Joshua Cranmer wrote:
We have an excellent chance to try to rethink CA infrastructure in this
process beyond the notion of a trusted third-party CA system (which is
already more or less broken, but that's beside the point). My
Summary: I am implementing support for @autocomplete values other than
off/on for HTMLInputElement.autocomplete. This allows web developers
to indicate how UAs should autocomplete/auto-fill values in the fields
(if they choose to do so) so they don't have to use heuristics to guess
what data
Primary eng emails
caban...@adobe.com, dschu...@adobe.com
*Proposal*
*http://dev.w3.org/fxtf/geometry/#DOMMatrix
http://dev.w3.org/fxtf/geometry/#DOMMatrix*
*Summary*
Expose new global objects named 'DOMMatrix' and 'DOMMatrixReadOnly' that
offer a matrix abstraction.
*Motivation*
The DOMMatrix
I'll defer to the layout folks for this one.
/ Jonas
On Fri, May 30, 2014 at 5:02 PM, Rik Cabanier caban...@gmail.com wrote:
Primary eng emails
caban...@adobe.com, dschu...@adobe.com
*Proposal*
*http://dev.w3.org/fxtf/geometry/#DOMMatrix
http://dev.w3.org/fxtf/geometry/#DOMMatrix*
I'm all for it! :-)
Rob
--
Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa
stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr,
'm aotr atnod sgaoy ,h o'mGee.t uTph eann
I never seem to be able to discourage people from dragging the W3C into
specialist topics that are outside its area of expertise. Let me try again.
Objection #1:
The skew* methods are out of place there, because, contrary to the rest,
they are not geometric transformations, they are just
Since DOMMatrix is replacing SVGMatrix, I don't see a way to implement it
behind a flag.
Should I wait to make that change and leave both SVGMatrix and DOMMatrix in
the code for now?
On Fri, May 30, 2014 at 8:53 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
I'm all for it! :-)
Rob
--
On Fri, May 30, 2014 at 9:00 PM, Benoit Jacob jacob.benoi...@gmail.com
wrote:
I never seem to be able to discourage people from dragging the W3C into
specialist topics that are outside its area of expertise. Let me try again.
Objection #1:
The skew* methods are out of place there, because,
29 matches
Mail list logo
