Trevor and VE folks more broadly, is this something
you have now scheduled
to work on? We're currently planning to have VE for tablets in stable and
launch the automatic mobile redirect for tablets on June 17, and I'm
curious about the likelihood of tackling the performance issues from the VE
side of things before then.
On Thu, May 1, 2014 at 3:53 PM, Trevor Parscal <tparscal(a)wikimedia.org>wrote;wrote:
The issues on load I believe we are having have
to do with "shields".
Shields are transparent 1x1 gif images we inject into the DOM to simulate
selecting over objects which are made up of complex HTML structures. They
originally also protected the HTML structure from being clicked on directly
(hence the name "shield"). More recently other techniques such as
"phantoms", "highlights" and "relocatable markers" have
taken over the
click blocking functionality. This technique was invented by Inez/Christian
of Wikia, and is regarded as creative and effective but inefficient.
Without doing much profiling, here is my best guess about what is going
on.
First we traverse DOM structures, looking for elements which might be
able to display outside their parent's bounding box, such as position:
absolute, or floats. This can be quite expensive because we have to do a
lot of CSS computed style checks and measurements, and the code isn't fully
optimized to use direct DOM methods so there's a little jQuery overhead.
Second we then insert the transparent images into the DOM structures, and
there could be hundreds of these pretty easily.
Trying to solve this problem we can optimize the first step a bit.
However, the traversal and measurement stuff will hit a limit pretty
quickly. The technique we use to fake the selection may have alternative
solutions, but I'm not sure about their performance impacts, especially on
mobile devices.
Overall, the shield/phantom/highlight/marker systems need to converge
into a simpler and more performant solution, and I have a few general ideas
and the intention to do this, but haven't yet sized it up or scheduled it.
I'm hoping we can surface this as a more pressing issue now that mobile VE
is hitting this wall, and get going on it soon.
- Trevor
On Thu, May 1, 2014 at 12:15 PM, Jon Robson <jrobson(a)wikimedia.org>wrote;wrote:
I was tasked with investigating why on large
pages, mobile takes
longer to load a page then VE.
To do this I loaded a template heavy page in both mobile and desktop
and ran JavaScript profiling on both.
In desktop7.9% of time was spent in jQuery.extend.css - this was the
most heavy function. In mobile it was also the most heavy - however in
mobile a whopping 23.76% of time was spent in jQuery.extend.css
In mobile 14360 calls were made to by both desktop and mobile to get
the value of float.
Looking closer at what was calling these I found it was related to
phantom element.
So it looks like fixing the following bug:
https://bugzilla.wikimedia.org/show_bug.cgi?id=64709
will help improve performance in mobile drastically.
I imagine the slowdown is related to the fact that on desktop existing
content is replaced with VisualEditor interface but on mobile there
are more DOM elements as VisualEditor is opened in an overlay on top
of the content.
Specifically the calls inside this callback that hog the most are:
1) $this.css( 'float' );
2) node.$.context.importNode( $shieldTemplate[0], true )
_______________________________________________
Mobile-l mailing list
Mobile-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l
--
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687