Re: [Jmol-users] Fwd: Chrome: rotation unusable in JSmol

[Robert Hanson]

Just to be clear, what is happening is that a recent feature of Chrome is
that if a mouse event triggers a setTimeout, the system is monitored for
how long it takes to process, and if that process time exceeds some
threshold, then from that time forward setTimeout processing is given a
lower priority. In our case, it means that all updating of the display is
put off until the mouse is let go. From

https://code.google.com/p/chromium/issues/detail?id=568725

#20 
alexcla...@chromium.org 

As much as possible chrome tries to do scrolling and animation on the
compositor thread to try and make them smooth even when the mainthread
is very unresponsive.   Various things that can't be done by the
compositor, e.g, running the layout pipeline (which has to be done on
the main thread).

In the context of this patch, a 'frame' is generated when the
compositor asks the main thread to run the layout pipeline by posting
a task to run BeingMainFrame. If animations stop and no more frames
are needed the compositor will tell the main thread by calling
BeginFrameNotExpectedSoon.  When that happens the scheduler stops
trying to optimize for fps.

Under some circumstances Chrome will block loading and or timer tasks,
if it thinks there's more important work pending.  The details of this
are complicated (I hope to document this properly in a public
doc/blogpost), and it's quite possible it's not working well in all
cases.

What would be really useful is a link to the web application (even a
cut down version) or a trace.  Then we can investigate and potentially
make fixes if the scheduler is doing the wrong thing.

PS the scheduler team is now out till January, but I will be sure to
follow up if you can send us anything more.



​
--
___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Re: [Jmol-users] Fwd: Chrome: rotation unusable in JSmol

[Robert Hanson]

See my other message -- 14.4.1 fixes this.

On Sun, Dec 13, 2015 at 10:13 AM, Robert Hanson  wrote:

> Just to be clear, what is happening is that a recent feature of Chrome is
> that if a mouse event triggers a setTimeout, the system is monitored for
> how long it takes to process, and if that process time exceeds some
> threshold, then from that time forward setTimeout processing is given a
> lower priority. In our case, it means that all updating of the display is
> put off until the mouse is let go. From
>
> https://code.google.com/p/chromium/issues/detail?id=568725
>
> #20 
> alexcla...@chromium.org 
>
> As much as possible chrome tries to do scrolling and animation on the 
> compositor thread to try and make them smooth even when the mainthread is 
> very unresponsive.   Various things that can't be done by the compositor, 
> e.g, running the layout pipeline (which has to be done on the main thread).
>
> In the context of this patch, a 'frame' is generated when the compositor asks 
> the main thread to run the layout pipeline by posting a task to run 
> BeingMainFrame. If animations stop and no more frames are needed the 
> compositor will tell the main thread by calling BeginFrameNotExpectedSoon.  
> When that happens the scheduler stops trying to optimize for fps.
>
> Under some circumstances Chrome will block loading and or timer tasks, if it 
> thinks there's more important work pending.  The details of this are 
> complicated (I hope to document this properly in a public doc/blogpost), and 
> it's quite possible it's not working well in all cases.
>
> What would be really useful is a link to the web application (even a cut down 
> version) or a trace.  Then we can investigate and potentially make fixes if 
> the scheduler is doing the wrong thing.
>
> PS the scheduler team is now out till January, but I will be sure to follow 
> up if you can send us anything more.
>
>
>
> ​
>



-- 
Robert M. Hanson
Larson-Anderson Professor of Chemistry
Chair, Department of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
--
___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Re: [Jmol-users] Fwd: Chrome: rotation unusable in JSmol

[Robert Hanson]

This is a very nasty and recently identified Chromium bug that was
discussed just yesterday . I have added a comment at

https://code.google.com/p/chromium/issues/detail?id=568725

Bob
--
___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Re: [Jmol-users] Fwd: Chrome: rotation unusable in JSmol

[Robert Hanson]

​Chrome Version 47.0.2526.80 m is a total disaster, even at
http://chemapps.stolaf.edu/jmol/jsmol/jsmol.htm

This is very unfortunate.

Eric, perhaps you can spearhead a bug report to Chrome.
--
___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Re: [Jmol-users] Fwd: Chrome: rotation unusable in JSmol

[Robert Hanson]

Don't forget that there is a WebGL option with JSmol. See
http://chemapps.stolaf.edu/jmol/jsmol/jsmolgl.htm

There are many limitations, but it might work fine for simple applications.

On Thu, Dec 10, 2015 at 6:37 PM, Paul PILLOT  wrote:

> Dear Eric,
> I’ve noticed the same problems, especially on older computers where each
> scene repaint can be perceived (white background flashing between each
> frame). One of my pages has other concerns related to javascript event
> listeners that make the whole experience even worse, by adding other
> calculations to the webpage on top of JSmol. My students noticed that
> firefox is better too.
> I have a simpler webpage with only buttons for interactions that doesn’t
> have the same drawbacks (animations are quirky, but user interactions are
> satisfactory).
>
> As this situation has been quite frustrating, I’ve decided to give WebGL a
> try using 3dmol.js. I am in the process of rewriting a single page
> application around a viewer, but it’s like reinventing the wheel as this
> library capabilities are far from being on par with JSmol and rely on a
> totally different mechanism of interaction (David Koes, its main
> developper, is very helpful in this process). Most Jsmol features lack form
> this library which focuses on rendering. I’ll see if it nonetheless could
> suit my teaching needs in biochemistry…
>
> -Paul
>
> Le 10-12-2015 à 17:55, Eric Martz  a écrit :
>
> In April 2014, Chrome gave the best performance of JSmol: smoothest
> rotation and few if any long (~ one minute) pauses during loading of some
> modest PDB files (pauses seen in Firefox). I configured FirstGlance in
> Jmol, when using JSmol, to recommend Chrome over Firefox. Safari was good.
> Internet Explorer was unusably slow with JSmol.
>
> Recently I began to notice jumpier rotation in Chrome, while Firefox and
> Safari continue to perform well.
>
> Today I found Chrome to be unable to rotate any molecule (even caffeine)
> in JSmol. Although there are brief moments when rotation can be seen, these
> are broken by long freezes (> 5 sec) when no rotation can be accomplished.
>
> The problem is worst when the mouse is moved quickly. The molecule freezes
> until the mouse is stopped. If you keep moving the mouse, the molecule may
> freeze for more than 10 sec. The molecule does rotate with very slow
> movements of the mouse.
>
> The problem occurs in OS X, where Chrome has updated to version 47.
>
> Rotation is still quite good in Chrome version 46, which happens to remain
> in my Windows 7 and 10 machines, despite version 47 becoming the stable
> release on December 1 (
> 
> http://googlechromereleases.blogspot.com/search?updated-max=2015-12-01T12:43:00-08:00=10).
> Presumably my Windows Chrome will shortly auto-update to 47 and then I will
> be very curious about performance.
>
> I tested the OS X beta version of Chrome, version 48, in hopes the problem
> would be fixed -- but it remains in Chrome 48 in OS X.
>
> Since Chrome stopped supporting Java on September 1, 2015, Chrome is now
> useless for JSmol websites.
>
> We can hope this is a mouse-related bug in Chrome that will be fixed, but
> as I mentioned, a fix is not present in the current beta version 48.
>
> This is a sad turn of events! Comments? Suggestions? Insights?
>
> -Eric
>
>
>
> --
> ___
> Jmol-users mailing list
> Jmol-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-users
>
>
>
>
> --
>
> ___
> Jmol-users mailing list
> Jmol-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-users
>
>


-- 
Robert M. Hanson
Larson-Anderson Professor of Chemistry
Chair, Department of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
--
___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Re: [Jmol-users] Fwd: Chrome: rotation unusable in JSmol

[Angel Herráez]

There is some documentation on how to use the WebGL modality of Jmol, 
features, limitattions, at
http://wiki.jmol.org/index.php/Jmol_JavaScript_Object/WebGL

You are welcome to report there about your experience.

On 11 Dec 2015 at 11:33, Robert Hanson wrote:
> Don't forget that there is a WebGL option with JSmol. See 
> http://chemapps.stolaf.edu/jmol/jsmol/jsmolgl.htm


--
___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Re: [Jmol-users] Fwd: Chrome: rotation unusable in JSmol

[Paul PILLOT]

Dear Eric,
I’ve noticed the same problems, especially on older computers where each scene 
repaint can be perceived (white background flashing between each frame). One of 
my pages has other concerns related to javascript event listeners that make the 
whole experience even worse, by adding other calculations to the webpage on top 
of JSmol. My students noticed that firefox is better too.
I have a simpler webpage with only buttons for interactions that doesn’t have 
the same drawbacks (animations are quirky, but user interactions are 
satisfactory).

As this situation has been quite frustrating, I’ve decided to give WebGL a try 
using 3dmol.js. I am in the process of rewriting a single page application 
around a viewer, but it’s like reinventing the wheel as this library 
capabilities are far from being on par with JSmol and rely on a totally 
different mechanism of interaction (David Koes, its main developper, is very 
helpful in this process). Most Jsmol features lack form this library which 
focuses on rendering. I’ll see if it nonetheless could suit my teaching needs 
in biochemistry…

-Paul

> Le 10-12-2015 à 17:55, Eric Martz  a écrit :
> 
> In April 2014, Chrome gave the best performance of JSmol: smoothest rotation 
> and few if any long (~ one minute) pauses during loading of some modest PDB 
> files (pauses seen in Firefox). I configured FirstGlance in Jmol, when using 
> JSmol, to recommend Chrome over Firefox. Safari was good. Internet Explorer 
> was unusably slow with JSmol.
> 
> Recently I began to notice jumpier rotation in Chrome, while Firefox and 
> Safari continue to perform well.
> 
> Today I found Chrome to be unable to rotate any molecule (even caffeine) in 
> JSmol. Although there are brief moments when rotation can be seen, these are 
> broken by long freezes (> 5 sec) when no rotation can be accomplished.
> 
> The problem is worst when the mouse is moved quickly. The molecule freezes 
> until the mouse is stopped. If you keep moving the mouse, the molecule may 
> freeze for more than 10 sec. The molecule does rotate with very slow 
> movements of the mouse.
> 
> The problem occurs in OS X, where Chrome has updated to version 47.
> 
> Rotation is still quite good in Chrome version 46, which happens to remain in 
> my Windows 7 and 10 machines, despite version 47 becoming the stable release 
> on December 1 ( 
> http://googlechromereleases.blogspot.com/search?updated-max=2015-12-01T12:43:00-08:00=10
>  
> ).
>  Presumably my Windows Chrome will shortly auto-update to 47 and then I will 
> be very curious about performance.
> 
> I tested the OS X beta version of Chrome, version 48, in hopes the problem 
> would be fixed -- but it remains in Chrome 48 in OS X.
> 
> Since Chrome stopped supporting Java on September 1, 2015, Chrome is now 
> useless for JSmol websites.
> 
> We can hope this is a mouse-related bug in Chrome that will be fixed, but as 
> I mentioned, a fix is not present in the current beta version 48.
> 
> This is a sad turn of events! Comments? Suggestions? Insights?
> 
> -Eric
> 
> 
> --
> ___
> Jmol-users mailing list
> Jmol-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-users

--
___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

[Jmol-users] Fwd: Chrome: rotation unusable in JSmol

[Eric Martz]

In April 2014, Chrome gave the best performance of JSmol: smoothest 
rotation and few if any long (~ one minute) pauses during loading of 
some modest PDB files (pauses seen in Firefox). I configured FirstGlance 
in Jmol, when using JSmol, to recommend Chrome over Firefox. Safari was 
good. Internet Explorer was unusably slow with JSmol.


Recently I began to notice jumpier rotation in Chrome, while Firefox and 
Safari continue to perform well.


Today I found Chrome to be unable to rotate any molecule (even caffeine) 
in JSmol. Although there are brief moments when rotation can be seen, 
these are broken by long freezes (> 5 sec) when no rotation can be 
accomplished.


The problem is worst when the mouse is moved quickly. The molecule 
freezes until the mouse is stopped. If you keep moving the mouse, the 
molecule may freeze for more than 10 sec. The molecule does rotate with 
very slow movements of the mouse.


The problem occurs in OS X, where Chrome has updated to version 47.

Rotation is still quite good in Chrome version 46, which happens to 
remain in my Windows 7 and 10 machines, despite version 47 becoming the 
stable release on December 1 
(http://googlechromereleases.blogspot.com/search?updated-max=2015-12-01T12:43:00-08:00=10). 
Presumably my Windows Chrome will shortly auto-update to 47 and then I 
will be very curious about performance.


I tested the OS X beta version of Chrome, version 48, in hopes the 
problem would be fixed -- but it remains in Chrome 48 in OS X.


Since Chrome stopped supporting Java on September 1, 2015, Chrome is now 
useless for JSmol websites.


We can hope this is a mouse-related bug in Chrome that will be fixed, 
but as I mentioned, a fix is not present in the current beta version 48.


This is a sad turn of events! Comments? Suggestions? Insights?

-Eric


--
___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Re: [Jmol-users] Fwd: Chrome: rotation unusable in JSmol

[J. Bays]

I see it too. I am running OSX 10.11.2 the latest with Chrome 47, the
latest.

J. Philip Bays
Emeritus Professor of Chemistry
Saint Mary's College
Norte Dame, IN

Sent from my iPad

On Dec 10, 2015, at 5:58 PM, Eric Martz  wrote:

In April 2014, Chrome gave the best performance of JSmol: smoothest
rotation and few if any long (~ one minute) pauses during loading of some
modest PDB files (pauses seen in Firefox). I configured FirstGlance in
Jmol, when using JSmol, to recommend Chrome over Firefox. Safari was good.
Internet Explorer was unusably slow with JSmol.

Recently I began to notice jumpier rotation in Chrome, while Firefox and
Safari continue to perform well.

Today I found Chrome to be unable to rotate any molecule (even caffeine) in
JSmol. Although there are brief moments when rotation can be seen, these
are broken by long freezes (> 5 sec) when no rotation can be accomplished.

The problem is worst when the mouse is moved quickly. The molecule freezes
until the mouse is stopped. If you keep moving the mouse, the molecule may
freeze for more than 10 sec. The molecule does rotate with very slow
movements of the mouse.

The problem occurs in OS X, where Chrome has updated to version 47.

Rotation is still quite good in Chrome version 46, which happens to remain
in my Windows 7 and 10 machines, despite version 47 becoming the stable
release on December 1 (

http://googlechromereleases.blogspot.com/search?updated-max=2015-12-01T12:43:00-08:00=10).
Presumably my Windows Chrome will shortly auto-update to 47 and then I will
be very curious about performance.

I tested the OS X beta version of Chrome, version 48, in hopes the problem
would be fixed -- but it remains in Chrome 48 in OS X.

Since Chrome stopped supporting Java on September 1, 2015, Chrome is now
useless for JSmol websites.

We can hope this is a mouse-related bug in Chrome that will be fixed, but
as I mentioned, a fix is not present in the current beta version 48.

This is a sad turn of events! Comments? Suggestions? Insights?

-Eric


--

___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users
--
___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users