Adam Roach a écrit :
when you look at that document, tell me what you think the parenthetical
phrase after the author's name is supposed to look like -- because I can
guarantee that Firefox isn't doing the right thing here.
In my case it does and displays : Хизер Фланаган
I have the universal c
Benjamin Smedberg a écrit :
it's important for certain kinds of drawing apps especially to have as
much mouse input as possible,
Yes
and I doubt that only receiving mouse input at 60fps would be adequate in
general
I don't know if what I'm saying is stupid, but I think it would be seen
as
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
synchronization between interactive events and what is visible.
- Br
On 08/02/2013 21:53, Brian Smith wrote:
The assumption here seems to be that it would be OK to ship a
significant performance regression for 32-bit users as long as 64-bit
users don't see a regression.
It's not. The assumption is that it will be unavoidable to turn off PGO
for 32 bit builds (a
Dave Mandelin a écrit :
>Approximately 35% of our installs are on Windows XP. Microsoft has said that
>less than 1% of XP installs are 64-bit. About 7% of our users are on Vista.
>Microsoft said Vista's 64-bit percentage is about 11%. Just over 50% of our
>Windows users are on Windows 7. Microsof
Ehsan Akhgari a écrit :
currently we cannot do 64-bit PGO builds because of an internal compiler
error on mozilla-central.
Also with VS2012 ?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Boris Zbarsky a écrit :
On 2/1/13 10:52 AM, Jean-Marc Desperrier wrote:
The trouble with going 64-bits is that the jit would then see some
significant regression, for cache pressure/instruction set related
reasons
Do you have numbers here?
I'm aware of some regressions for things
Nathan Froyd a écrit :
Do you have examples that you can point to? I'm sure the GCC folks
would be interested in hearing about concrete examples...
OK, there was many examples with older GCC versions, but it's not
guaranteed to be still true with the newest GCC which had significant
enhancem
Ehsan Akhgari a écrit :
I don't have a lot of experience with mingw32, but to the best of my
knowledge, it's based on older versions of gcc (4.6?), and lacks 64-bit
support
Ehsan, did you forget that there would be no memory problem with 64-bits
MSVC PGO builds ?
The trouble with going 64-bi
cja...@gmail.com a écrit :
I don't have a lot of experience with mingw32, but to the best of my
>knowledge, it's based on older versions of gcc (4.6?),
>and lacks 64-bit support
Currently the best option for mingw is mingw-w64 for that (besides
what the name suggests) supports both 32 and 64-b
Robert O'Callahan a écrit :
Often, the OS support for a particular
language is really terrible and we can and should do better even if it
means being inconsistent with the OS. This is certainly true for the case
of font shaping, for example.
I've seen the references to font shaping in the start
Norbert Lindenberg a écrit :
This is really basic infrastructure that for native applications is
provided by the OS and for web applications should be provided by the
browser.
And why do you set the aim for the web application to be able to do what
the native application next to it will be una
Axel Hecht a écrit :
Additionally, quite a few users are multilingual. If I look at en-US
usage, only half of that is within the US, followed by India and Indonesia.
Also, OS support usually means support for the language the OS is
running in, not the language we use for Firefox.
Bi-lingual, no
Norbert Lindenberg a écrit :
The ECMAScript Internationalization API [...] provides web applications
with the ability to format numbers, dates, and times and sort strings
according to the rules of the language that the application is using,
not the one that browser and OS default to.
If the OS
Zack Weinberg a écrit :
Does MS have any plan to support the x32 memory model? It needs kernel
as well as compiler support.
Could a shim layer possibly bring x32 to a x64 process under Windows ?
Or else have most of the code handle memory as "offset inside a bucket",
and reduce most pointer
15 matches
Mail list logo
