(RC 1) Charting & Drawing Framework Performance

[LEWJO10@ca.com]

Brendan,

I am just looking for confirmation that work continues on improving rendering times for the charts.

Release Candidate 1 shows a lot of improvement in this regard, but more is needed.

The Flex charts we are replacing show ten series across 90 days in less than 5 seconds.

The attached ColumnChart_PerformanceIssue.txt that has five series across 30 days takes too long as the PerformanceIssueScreenShot.png shows.

Please let me know your thoughts.

By the way does FNR mean fixed next release? In other words, the next release candidate?

Thanks,
John L.

[Colin Alworth]

FNR stands for Fixed, but Not Released - this means you can find the changes in SVN, and they will be available in the next release version.

[BrendanC]

Just clarify I'd like to know more about the environment you are using when you get this warning. Are you using hosted or web mode? What kind of system specs do you have? What specific browser are you using? Thanks.

[LEWJO10@ca.com]

Brendan,

I am running in hosted mode under Eclipse 3.7.0 using FireFox 7.0.

John L

[LEWJO10@ca.com]

Colin,

Just to be sure I understand clearly, FNR means the fix will be in the next release version. The next release version at this point is GXT 3.0 and not necessarily the next release candidate? Do I have that right?

Also, I am guessing that SVN refers to the source code management system you are using?

Sorry for all the questions.

Thanks,
John

[Colin Alworth]

No, in this case, with the release this afternoon of 3.0.0-rc2, most of the current FNRs will be changed to FIXED (see http://www.sencha.com/forum/showthre...-now-available for more details on rc2). Check the specific forum post for details as to whether or not any given issue is marked as fixed - we're reviewing them now.

And yes, we use Subversion internally to track changes to the library. As a support subscriber, you should have access to this if you wish to look at changes or to get the very latest code. Check your support page for details, or PM Brendan or myself.

[Colin Alworth]

As far as performance numbers go, don't count on hosted mode to give an accurate representation of how an application will perform in production. In order to do its job correctly, hosted mode runs just in the JVM where possible, but when dom manipulation is required, it must make calls to the browser plugin, which calls Javascript directly. The return value must the be wrapped up so it can be manipulated in the JVM again. These two different modes of running code can result in some code that is vastly faster than production (running only in the JVM), and some code that is much slower (from crossing between the JVM to JavaScript and back again).

Instead, compile your application to web mode, and test it that way - this will give you numbers that are consistent with what users will feel in production.

[LEWJO10@ca.com]

Colin,

Agreed. I should be testing performance in web mode.

Please see my new posting "(RC 2) Web Mode Charting & Drawing Framework Performance."

Thanks,
John L.