Intended changes in 12.0

[stravinsky]

How about adding the code patches from the aurorora branch (FF13) that are being done to reduce "jank" in the gecko engine? the major problem with the FF code is the high janks on startups and tab opening, which are a major concern for the mozilla developers.

i regularly read the mozilla bug discussions and the mozilla snappy looks very promising. the major changes to the code are from FF13 onwards.
can you incorporate some of these patches in FF12?

[link68759]

As far as Windows 8 Metro Firefox goes; metro apps have their own independent SDK and they work completely differently... I don't think Metro Firefox is going to be a feature of firefox, it's more likely a whole development branch. I don't think you need to worry about following it.

My one concern is I don't see any mention of extension syncing in your first post; is that going to be supported?

[Moonchild]

How about adding the code patches from the aurorora branch (FF13) that are being done to reduce "jank" in the gecko engine? the major problem with the FF code is the high janks on startups and tab opening, which are a major concern for the mozilla developers.

i regularly read the mozilla bug discussions and the mozilla snappy looks very promising. the major changes to the code are from FF13 onwards.
can you incorporate some of these patches in FF12?

If you can point me to the relevant bugzilla bug number, I can have a look. you can use the [bug] BBCode tag on this forum to properly reference it.

Note that 12.0 code has been finalized (code freeze) and is in the soaking phase. Any suggestions at this point will be for a future release.

[Moonchild]

As far as Windows 8 Metro Firefox goes; metro apps have their own independent SDK and they work completely differently... I don't think Metro Firefox is going to be a feature of firefox, it's more likely a whole development branch. I don't think you need to worry about following it.

It's not going to be a separate product, if that's what you think - it will be integrated with the current package, even if it's a separate sub branch - it's no different than the sub branches already in Firefox right now for, e.g., sync.

My one concern is I don't see any mention of extension syncing in your first post; is that going to be supported?

Other changes in Firefox 12 that aren't specifically mentioned have been ported over.

[alan9182]

Note that 12.0 code has been finalized (code freeze) and is in the soaking phase. Any suggestions at this point will be for a future release.

Eagerly awaiting release

Alan

[stravinsky]

How about adding the code patches from the aurorora branch (FF13) that are being done to reduce "jank" in the gecko engine? the major problem with the FF code is the high janks on startups and tab opening, which are a major concern for the mozilla developers.

i regularly read the mozilla bug discussions and the mozilla snappy looks very promising. the major changes to the code are from FF13 onwards.
can you incorporate some of these patches in FF12?

If you can point me to the relevant bugzilla bug number, I can have a look. you can use the [bug] BBCode tag on this forum to properly reference it.

Note that 12.0 code has been finalized (code freeze) and is in the soaking phase. Any suggestions at this point will be for a future release.

i am talking about this : https://wiki.mozilla.org/Performance/Snappy

they are doing a lot of changes to the code of FF aurora 13 (now FF beta 13) related to the janks in browsing. i was hoping that you would add these patches in PM 12 so that the PM users can enjoy some of those benefits before the official code release of FF13. but since you have already codefreezed PM12 , allthese changes will come in FF13/PM 13, so no added benefit for PM users. well....

anyway,the bugs i was referring to were :
https://bugzilla.mozilla.org/buglist.cgi?type1-0-0=equals;list_id=2592903;field0-0-0=status_whiteboard;resolution=FIXED;chfieldto=2012-03-13;query_format=advanced;chfield=resolution;chfieldfrom=2012-01-31;chfieldvalue=Fixed;bug_status=RESOLVED;type0-0-0=substring;value0-0-0=snappy;field1-0-0=target_milestone

these are the bugs for FF13 that are considered resolved.



https://bugzilla.mozilla.org/buglist.cgi?type1-0-0=equals;field0-0-0=status_whiteboard;resolution=FIXED;chfieldto=2012-04-24;query_format=advanced;chfield=resolution;chfieldfrom=2012-03-14;chfieldvalue=Fixed;bug_status=RESOLVED;type0-0-0=substring;value0-0-0=snappy;field1-0-0=target_milestone;list_id=2658432

these are the bugfixes for FF14. maybe you can add them in PM13 ?

Though seripusly hoping you would add the FF13 bugfixes in PM12 release. why dont you make a trial build and see if you notice a subjective "jank reduction" difference. if you are convinced, add these patches. i for one can wait for 1 week more for a better browser , especially if i am getting the benefits of FF13 code now.

[Moonchild]

What you are talking about is a meta subject in Mozilla discussions. Not all of the bugs apply to Pale Moon, to begin with. Some bugs have already been fixed by providing more sane GC defaults in Pale Moon settings. A good number of bugs lumped in there are about telemetry feedback which Pale Moon doesn't use. Pale Moon, by its nature, is already "snappy" compared to Firefox.

"jank" is still not explained in any of the documentation I've seen. If it refers to desynching with screen refresh when doing pixel-by-pixel scrolling, that is because of the tradeoff made for image rendering. I'd rather have some slight stutter in slow scrolling pages when autoscrolling than having animated gifs clog my CPU, thank you very much

It should be noted that individual bugs will have to be looked at for viability. I will only implement bugfixes that don't pose large risks, because stability and efficiency should not be endangered by what is, in all respects, a luxury/cosmetic problem. Different priorities, if you will.

Pale Moon 12 sees the start of a different release cycle for Pale Moon because honestly, I'm sick and tired of the 6 week carousel forcing me to start from scratch because code merges fail with lumped-together patches (as became clear with Pale Moon 9). You'll have to stop thinking in terms of PM 13 and 14, considering a stable base in PM12 will see incremental implementations of relevant bugfixes on it, similar to 9.2 in lieu of 10, before. Pale Moon's development will become more independent of the staged release cycles @Mozilla from here on out.

[stravinsky]

"jank" is still not explained in any of the documentation I've seen. If it refers to desynching with screen refresh when doing pixel-by-pixel scrolling, that is because of the tradeoff made for image rendering. I'd rather have some slight stutter in slow scrolling pages when autoscrolling than having animated gifs clog my CPU, thank you very much

JANK is the large hangs in the UI (tabs dont respond, cant switch between tabs etc.), sometimes of 500msecs and sometimes to several seconds, occurring during tab loading, startup etc. the biggest examples are cold starts , when you open 6-7 tabs and the whole PM/FF UI simply stops for many seconds.

[ag0044]

Pale Moon, for me, equals the sensible branch of FF.

And then, with this:

Pale Moon 12 sees the start of a different release cycle for Pale Moon ... Pale Moon's development will become more independent of the staged release cycles @Mozilla from here on out.

Pale Moon, for me, equals the sensible and sane branch of FF.

I was so glad to read Moonchild's comment - cited above - that I considered it worthy of registering here to post my support. Thank you.

[Moonchild]

JANK is the large hangs in the UI (tabs dont respond, cant switch between tabs etc.), sometimes of 500msecs and sometimes to several seconds, occurring during tab loading, startup etc. the biggest examples are cold starts , when you open 6-7 tabs and the whole PM/FF UI simply stops for many seconds.

That's funny, because even on my old system (which was really getting up there in age) I never experienced disproportionate pauses. Neither on my crappy netbook for that matter...

If you tell a browser to load 7 sites concurrently, of course you can expect it to be "busy" for a few seconds. Is this another "You want the moon on a stick!" scenario?

[stravinsky]

That's funny, because even on my old system (which was really getting up there in age) I never experienced disproportionate pauses. Neither on my crappy netbook for that matter...

thats funny, because lots of users are reporting similar issues, both in forums and in bugzilla. and the fact that mozilla devs have started a full-fledged project "snappy" for it tells that it really is an issue. i can definitely verify the startup issue.

If you tell a browser to load 7 sites concurrently, of course you can expect it to be "busy" for a few seconds. Is this another "You want the moon on a stick!" scenario?

you certainly expect the browser to be busy for few seconds, but the UI should not suffer in that case. You should be able to switch tabs, open menus etc with no slowdown.
Opera and Chrome already are good at it. their UI remain smooth, no matter how much "busy" the browser is. why defend poorer code , when the competition does it better?

Did you even take a look at this: https://wiki.mozilla.org/Performance/Snappy ?

[Moonchild]

you certainly expect the browser to be busy for few seconds, but the UI should not suffer in that case. You should be able to switch tabs, open menus etc with no slowdown.

I'm sorry, but... what is the point in wanting to switch tabs or use menus when the content isn't loaded yet anyway? And if you want quick and immediate access, why don't you use the "Don't load tabs until selected" option?

Opera and Chrome already are good at it. their UI remain smooth, no matter how much "busy" the browser is. why defend poorer code , when the competition does it better?

Haha, you can slow right down there. Don't put Opera or Chrome on a pedestal, because both have much worse issues than some slight pauses when you work the browser to the max. You have to realize that most of the libraries in the Firefox tree are nor parallelized and as such can only use one CPU core. That is not something you can "fix" with a few patches, but you can work around them, and that is what seems to be done.

Did you even take a look at this: https://wiki.mozilla.org/Performance/Snappy ?

Why do you question me? Of course I have. it's a meta subject @Mozilla that lumps a lot of things together that aren't necessarily related, with umbrella goal to "improve UI responsiveness" for "non-animated elements".

[stravinsky]

I'm sorry, but... what is the point in wanting to switch tabs or use menus when the content isn't loaded yet anyway? And if you want quick and immediate access, why don't you use the "Don't load tabs until selected" option?

also applies when you have opened some tabs in the background and are scrolling/navigating on the current page. the whole UI hangs and there are huge slowdowns. the user doesnt want that the current tab should suffer in any situation.

Haha, you can slow right down there. Don't put Opera or Chrome on a pedestal, because both have much worse issues than some slight pauses when you work the browser to the max. You have to realize that most of the libraries in the Firefox tree are nor parallelized and as such can only use one CPU core. That is not something you can "fix" with a few patches, but you can work around them, and that is what seems to be done.

as i understood, major works are being done in the incremental garbage collector and the cycle collector as well. along with work in socket creation, animation of the UI and DOM elements that can cause major slowdowns of UI.
there is some work being done to add OpenCl/webCL in gecko, but it tis not even pre-preliminary stage.

Why do you question me? Of course I have. it's a meta subject @Mozilla that lumps a lot of things together that aren't necessarily related, with umbrella goal to "improve UI responsiveness" for "non-animated elements".

you appear as if these changes are not important. any particular reason why ? you appear to be almost content with the current code and the performance of the code.
may i know what is the point you are trying to make? that browser improvements / perceived improvements are not OK/not needed?

[stravinsky]

on a separate note, any plans to get a AVX capable CPU and build an AVX build ?
IIRC, you said in a post that AVX could potentially speed up almost all aspects of the browser.
I'm itching to try that build.

i dont know enough about the source code to hazard a guess. what do you think about AVX , would that improve performance ?

[Moonchild]

you appear as if these changes are not important. any particular reason why ?

These changes are less important if the browser is already more "snappy". There is less to mitigate.
The changes are also of less importance as long as they are works in progress and not thoroughly tested. Pale Moon's approach is and will remain to work from release-grade code only, with only rare exceptions.

any plans to get a AVX capable CPU and build an AVX build ?

Are you paying for a development-grade system with an AVX capable CPU?
I've recently looked at trying a non-profiled build with AVX on a non-AVX system out of curiosity and to test if building with AVX would warrant a separate (experimental) release build or not, but the Firefox source tree relies heavily on being able to run all executables created as part of the build process (including internal tools for the build itself). In a way, it would be cross-compiling for CPU architecture, and cross-compiling is terribly broken in Firefox because of this dependence.

[stravinsky]

The changes are also of less importance as long as they are works in progress and not thoroughly tested. Pale Moon's approach is and will remain to work from release-grade code only, with only rare exceptions.

agreed. no more talks of integrating patches.

These changes are less important if the browser is already more "snappy". There is less to mitigate.

dont agree here.

Are you paying for a development-grade system with an AVX capable CPU?

maybe you can get some funding from Intel, say "INTEL AVX enabled browser optimized ti run only on Intel Sandy Bridge ivy bridge (tm) (r) (c) " , they might give you some funds.

cross compiling PM possible only on linux ,right? i was reading GCC 4.7 optimisation documentation , and when avx is used, the compiler tries to convert all SSE instructions and loops to AVX.
i believe that would automagically make PM 200% faster

maybe you can ask for volunteers with AVX enabled systems who can build PM for you, which you can test etc ?

[stravinsky]

the "submit performance data" check box , where does it send the data to ? mozilla devs or you?

[Moonchild]

the "submit performance data" check box , where does it send the data to ? mozilla devs or you?

Neither, telemetry is not included.

[Moonchild]

maybe you can get some funding from Intel, say "INTEL AVX enabled browser optimized ti run only on Intel Sandy Bridge ivy bridge (tm) (r) (c) " , they might give you some funds.

AVX is not limited to Intel CPUs, AMD Bulldozers (and later) also include the instruction set.
As-is, it would only be for an experimental build, and I doubt Intel would be even interested in listening to such a request. Really.
AVX is not going to create world-shocking differences either, so it would be for (1) a very very small group of people having supported systems and (2) on systems where there will be no perceptual difference between the SSE2 and AVX builds (because the systems supporting AVX are going to be very fast either way).

These changes are less important if the browser is already more "snappy". There is less to mitigate.

dont agree here.

You can disagree but it boils down to human perception. If the base optimization of Pale Moon (currently looking at 33% in JS according to the latest Dromaeo results on the version 12) pushes responsiveness of the (largely JS-based) GUI outside of human perception range, then anything more won't make the browser more "snappy", and the patches involved will therefore become less relevant and lower priority, and purely the domain of theoretical comparison of numbers or at most compound responsiveness. Does it matter if you have 30 (without patch) or 35 (with patch) fps on something, when human perception doesn't go much past 25 fps? Nope.

[Moonchild]

Locking this topic, considering the release of v12 tomorrow and going off on a tangent - any further development discussion: please make a new thread.