Re: Single- vs. double-precision FP in gfx types

[Robert O'Callahan]

On Wed, Nov 25, 2015 at 11:59 AM, Nicholas Nethercote <
n.netherc...@gmail.com> wrote:

> On Mon, Nov 23, 2015 at 8:14 PM, Robert O'Callahan 
> wrote:
> >>
> >> One major remaining Moz2Dification step is the conversion of thebes
> >> types such as gfxSize, gfxPoint, gfxRect, and gfxMatrix to their Moz2D
> >> equivalents.
> >
> > I think for now we should focus on replacing usage of gfxContext with
> > DrawTarget. I think that's more important than unifying those types.
>
> Why is that more important? (Not doubting, just curious.)
>

It actually reduces run-time overhead. Also, the gfxContext API is
significantly different to the DrawTarget API so eliminating it reduces the
knowledge burden significantly.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Single- vs. double-precision FP in gfx types

[Nicholas Nethercote]

On Mon, Nov 23, 2015 at 8:14 PM, Robert O'Callahan  wrote:
>>
>> One major remaining Moz2Dification step is the conversion of thebes
>> types such as gfxSize, gfxPoint, gfxRect, and gfxMatrix to their Moz2D
>> equivalents.
>
> I think for now we should focus on replacing usage of gfxContext with
> DrawTarget. I think that's more important than unifying those types.

Why is that more important? (Not doubting, just curious.)

Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Single- vs. double-precision FP in gfx types

[L. David Baron]

On Wednesday 2015-11-25 12:49 +1300, Robert O'Callahan wrote:
> On Wed, Nov 25, 2015 at 11:59 AM, Nicholas Nethercote <
> n.netherc...@gmail.com> wrote:
> 
> > On Mon, Nov 23, 2015 at 8:14 PM, Robert O'Callahan 
> > wrote:
> > >>
> > >> One major remaining Moz2Dification step is the conversion of thebes
> > >> types such as gfxSize, gfxPoint, gfxRect, and gfxMatrix to their Moz2D
> > >> equivalents.
> > >
> > > I think for now we should focus on replacing usage of gfxContext with
> > > DrawTarget. I think that's more important than unifying those types.
> >
> > Why is that more important? (Not doubting, just curious.)
> >
> 
> It actually reduces run-time overhead. Also, the gfxContext API is
> significantly different to the DrawTarget API so eliminating it reduces the
> knowledge burden significantly.

Presumably it's equally important to replace the remaining
nsRenderingContext usage with DrawTarget?

(nsRenderingContext was the previous API before gfxContext.)

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: Digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Single- vs. double-precision FP in gfx types

[L. David Baron]

On Tuesday 2015-11-24 18:21 -0800, L. David Baron wrote:
> Presumably it's equally important to replace the remaining
> nsRenderingContext usage with DrawTarget?
> 
> (nsRenderingContext was the previous API before gfxContext.)

Er, never mind; I guess that's sort of a stupid question at this
point, since nsRenderingContext has mostly been gutted.

It still seems like, where possible, we should switch from passing
around an nsRenderingContext or a gfxContext to passing around a
DrawTarget.  (Presumably starting from leaf functions and moving
up.)

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: Digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Question: "Chrome file doesn't exist: ..." in |make mozmill| log by running DEBUG versions of C-C TB

[ISHIKAWA,chiaki]

On 2015/11/24 20:21, Philip Chee wrote:

On 22/11/2015 03:20, ISHIKAWA,chiaki wrote:



   35 Chrome file doesn't exist:
/NREF-COMM-CENTRAL/objdir-tb3/dist/bin/chrome/toolkit/skin/classic/global/icons/information-64.png

information-64.png only exists in the osx theme
http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/themes/osx/global/jar.mn#104
http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/themes/osx/global/global.css#58

Windows should use:
"chrome://global/skin/icons/information-32.png"

Linux should use:
"moz-icon://stock/gtk-dialog-info?size=dialog"

This appears to be a problem only in Thunderbird and Instantbird.
http://mxr.mozilla.org/comm-central/search?string=information-64.png

There appears to be a informationGhosted-64.png that isn't used by
anything. Suggest rm
http://mxr.mozilla.org/comm-central/find?string=informationGhosted-64.png=comm-central=

Phil


Thank you. I will look into this.

Less cluttered log file is much nicer!

CI


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Single- vs. double-precision FP in gfx types

[Robert O'Callahan]

On Wed, Nov 25, 2015 at 3:24 PM, L. David Baron  wrote:

> On Tuesday 2015-11-24 18:21 -0800, L. David Baron wrote:
> > Presumably it's equally important to replace the remaining
> > nsRenderingContext usage with DrawTarget?
> >
> > (nsRenderingContext was the previous API before gfxContext.)
>
> Er, never mind; I guess that's sort of a stupid question at this
> point, since nsRenderingContext has mostly been gutted.
>
> It still seems like, where possible, we should switch from passing
> around an nsRenderingContext or a gfxContext to passing around a
> DrawTarget.  (Presumably starting from leaf functions and moving
> up.)
>

Yes.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Announcing MozillaBuild 2.1.0 Release

[Ryan VanderMeulen]

I am pleased to announce the final release of MozillaBuild 2.1.0. All users
are encouraged to upgrade as soon as possible due to many improvements in
Mercurial since the last release.
http://ftp.mozilla.org/pub/mozilla.org/mozilla/libraries/win32/MozillaBuildSetup-Latest.exe

Important changes since version 2.0.0:
* Updated Mercurial to version 3.6.1.
* Enabled the Mercurial clonebundles extension to greatly speed up
repository cloning.
* Minor updates to various included components.

Full changelog:
http://hg.mozilla.org/mozilla-build/pushloghtml?fromchange=MOZILLABUILD_2_0_0_RELEASE=MOZILLABUILD_2_1_0_RELEASE

To upgrade:
1. Remove your current installation. If you can't remove the existing
installation, you probably have a terminal open or ssh-agent running.
Terminate it and try again.
2. Install MozillaBuild 2.1.0.
3. Run |./mach mercurial-setup --update-only| to ensure that the
version-control-tools repository is current. Extension bustage is likely
otherwise.
4. Clobber (remove the object directory of) any trees you have. Build
errors may occur otherwise.
5. If you previously enabled minTTY, you will need to do so again by
setting USE_MINTTY=1 at the top of start-shell.bat.

Please file any problems you come across in mozilla.org::MozillaBuild.

-Ryan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Does the sdk/page-worker are loading pages off-main thread? and running code in another thread?

[Dave Townsend]

Current release versions will load page-workers in the main process,
nightly has been updated to load in a child process if e10s is
enabled.

On Mon, Nov 23, 2015 at 10:59 PM, 罗勇刚(Yonggang Luo)
 wrote:
> pageWorker = require("sdk/page-worker").Page({   contentScript:
> "console.log(document.body.innerHTML);",   contentURL: "
> http://en.wikipedia.org/wiki/Internet; });
>
> --
>  此致
> 礼
> 罗勇刚
> Yours
> sincerely,
> Yonggang Luo
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Announcing MozillaBuild 2.1.0 Release

[Gregory Szorc]

On Tue, Nov 24, 2015 at 9:56 AM, Ryan VanderMeulen <
rvandermeu...@mozilla.com> wrote:

> I am pleased to announce the final release of MozillaBuild 2.1.0. All users
> are encouraged to upgrade as soon as possible due to many improvements in
> Mercurial since the last release.
>
> http://ftp.mozilla.org/pub/mozilla.org/mozilla/libraries/win32/MozillaBuildSetup-Latest.exe
>
> Important changes since version 2.0.0:
> * Updated Mercurial to version 3.6.1.
> * Enabled the Mercurial clonebundles extension to greatly speed up
> repository cloning.
> * Minor updates to various included components.
>
> Full changelog:
>
> http://hg.mozilla.org/mozilla-build/pushloghtml?fromchange=MOZILLABUILD_2_0_0_RELEASE=MOZILLABUILD_2_1_0_RELEASE
>
> To upgrade:
> 1. Remove your current installation. If you can't remove the existing
> installation, you probably have a terminal open or ssh-agent running.
> Terminate it and try again.
> 2. Install MozillaBuild 2.1.0.
> 3. Run |./mach mercurial-setup --update-only| to ensure that the
> version-control-tools repository is current. Extension bustage is likely
> otherwise.
> 4. Clobber (remove the object directory of) any trees you have. Build
> errors may occur otherwise.
> 5. If you previously enabled minTTY, you will need to do so again by
> setting USE_MINTTY=1 at the top of start-shell.bat.
>
> Please file any problems you come across in mozilla.org::MozillaBuild.
>

I can't emphasize the importance of upgrading Mercurial enough, no matter
what platform you are on. There have been some major performance
improvements in the previous few releases and more are in the pipeline for
3.7 (to be released February 1).

Because it is so beneficial to run a modern release, hg.mozilla.org will
soon print a warning to people who push with a Mercurial client older than
3.5. There are no plans to enforce a modern client at this time. Install
instructions are at
https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/installing.html
.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Question: "Chrome file doesn't exist: ..." in |make mozmill| log by running DEBUG versions of C-C TB

[Philip Chee]

On 22/11/2015 03:20, ISHIKAWA,chiaki wrote:


>   35 Chrome file doesn't exist: 
> /NREF-COMM-CENTRAL/objdir-tb3/dist/bin/chrome/toolkit/skin/classic/global/icons/information-64.png

information-64.png only exists in the osx theme
http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/themes/osx/global/jar.mn#104
http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/themes/osx/global/global.css#58

Windows should use:
"chrome://global/skin/icons/information-32.png"

Linux should use:
"moz-icon://stock/gtk-dialog-info?size=dialog"

This appears to be a problem only in Thunderbird and Instantbird.
http://mxr.mozilla.org/comm-central/search?string=information-64.png

There appears to be a informationGhosted-64.png that isn't used by
anything. Suggest rm
http://mxr.mozilla.org/comm-central/find?string=informationGhosted-64.png=comm-central=

Phil

-- 
Philip Chee , 
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Startup cache and resource:// urls

[Nicolas B. Pierron]

The concerns that I have is that the start-up cache proved to be
useful in multiple experiments made by 3 different persons, and at
different occasions and for different purposes:
 - Bug 813324 - Compiled JS cache for Firefox
 - Bug 1101386 - Missing bytecode cache causes SpiderMonkey to be 6x
slower than JSC at 2nd (or consecutive) execution of
TypeScript-compiled code
 - Bug 1164389 - Allow certified applications to load XDR bytecode

So these numbers only highlight that using a bytecode cache is better
than not using any, but they do not compare the caching the
jschar-source against bytecode cache, and I would really appreciate to
have this kind of information before doing these changes.
Also note that in the previous tests, the bytecode cache only got used
for caching the full bytecode, while today we are capable of saving a
sparse version of the bytecode which only contains function used
during the last execution, which reduces the bytecode cache size by
30%.

So my concern is, that we are moving away from a system that we do not
use optimally yet.


On Tue, Nov 24, 2015 at 7:42 AM, Aaron Klotz  wrote:
> On 11/23/2015 10:22 PM, Mike Hommey wrote:
>>
>>Can the perf team look into this? Note the startup cache only matters
>>on the first startup for a given build, and that might be a reason why
>>we fail to track its performance impact.
>>
>>
> We can get rid of it if we properly encode JS source in the omnijar. Unless
> something has changed in SpiderMonkey, the last time I looked we convert the
> JS source in the omnijar to jschars at parse time. Eliminating that
> conversion step would cancel out the benefit of the startup cache.
>
> I seem to remember NBP expressing concern with this plan in Whistler.
> Nicolas, do you recall what your concerns were?



-- 
Nicolas B. Pierron
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform