I am building an one page app, that can load contents dynamically by using ajax and typeset the content using MathJax.
I noticed when used the MathJax to dynamically typeset the contents, even the same contents are refreshed in one region of the page(there is no any other contents inserted), the browser's memory keeps going up.
So I am guessing the typeset done by the MathJax isn't recycled, even when the typesetted part of the page is refreshed.
Is there any way to force recycling the typeset objects created by MathJax, in order to optimize the memory it uses?
Related
In my hybrid Android app I use inline SVG to display images that are large (of the order of 2Mb) and complex (several hundred SVG elements per image). When I need to change the image I do the following
var puzzle = document.createElementNS(SVGNS,'svg'),
kutu = document.getElementById('kutu');
puzzle.id = 'puzzle';
puzzle.setAttribute('preserveAspectRatio','none');
puzzle.setAttribute('width','100vw');
puzzle.setAttribute('height','85.5vh');
puzzle.setAttribute('xmlns',SVGNS);
puzzle.setAttribute('xmlns:xlink',XLINK);
puzzle.setAttribute('fill-rule','evenodd');
puzzle.setAttribute('clip-rule','evenodd');
puzzle.setAttribute('stroke-linejoin','round');
puzzle.setAttribute('stroke-miterlimit','1.414');
puzzle.setAttribute('viewBox','0 0 1600 770');
puzzle.innerHTML = SVG;
//SVG here is the SVG image content shorn off the outer <svg>..</svg>
if (0 < kutu.children.length) kutu.children[0].remove();
//remove old image, iff any
kutu.appendChild(puzzle);
//append the new image
While this is working the process of displaying the new image is slow. I suspect it is because of the innerHTML assignment above. Recreating through a sequence of createElementNS, puzzle.àppendChild would require me to first parse the incoming raw SVG content etc. Is that the way to go or would there be a faster way to display the content.
Once again for clarity - SVG here is the content of the new SVG image to be displayed shorn of its outer <svg>...</svg> wrrapper.
Just a side note it would probably be better to use setAttributeNS in place of setAttribute for consistency purpose since createElementNS is used, though it might not make a difference in speeding up the SVG image change.
In the case of a native app, a tool like the Android Profiler if using Android Studio 3.0 and higher can be used to analyze performance bottleneck. However since your app is a hybrid app, some sort of performance profiler that's applicable to the hybrid app (Whether it's Ionic or Cordova, etc.) can help to pinpoint where your performance bottleneck is.
Since your app is a hybrid, without knowing the resource capacity of your android app session, the guess is it seems to be a possible cause that it calls something like .setAttribute to set session-level attributes on the fly during the change of the image and the session resource might not be enough, and also the DOM has to perform .innerHTML and appendChild, which are dynamic operations. DOM manipulation is known to be slow.
Conversion of attributes of all the SVGs and store the result in some sort of storage or cache, and when needed, call it from the persistent storage or cache might be helpful.
Or consider using AngularJS to do the SVG change beforehand and preload the SVG images, refer to easily preload images in your Angular app. Here is another similar code to yours except it's using AngularJS to add SVG for starters.
Another simpler way, without changing your code, if you could minify the incoming SVGs beforehand, is to use SVG Optimizer or SVGO, a node.js open source project to compress your SVGs. Quoted from the SVGO link it says:
"SVG files, especially those exported from various editors, usually contain a lot of redundant and useless information. This can include editor metadata, comments, hidden elements, default or non-optimal values and other stuff that can be safely removed or converted without affecting the SVG rendering result." Although the performance gain might not be obvious going this route.
I understand that the background page of a Chrome extension is never displayed. It makes sense to me that a background page should contain only scripts. In what situations would HTML markup ever be needed?
At https://developer.chrome.com/extensions/background_pages there is an example with an HTML background page, but I haven't been able to get it to work (perhaps because I am not sure what it should be doing).
Are there any examples of simple Chrome extensions which demonstrate how HTML markup can be useful in a background page?
Historical reasons
The background page is, technically, a whole separate document - except it's not rendered in an actual tab.
For simplicity's sake, perhaps, extensions started with requiring a full HTML page for the background page through the background_page manifest property. That was the only form.
But, as evidenced by your question, most of the time it's not clear what the page can actually be used for except for holding scripts. That made the entire thing being just a piece of boilerplate.
That's why when Chrome introduced "manifest_version": 2 in 2012 as a big facelift to extensions, they added an alternative format, background.scripts array. This will offload the boilerplate to Chrome, which will then create a background page document for you, succinctly called _generated_background_page.html.
Today, this is a preferred method, though background.page is still available.
Practical reasons
With all the above said, you still sometimes want to have actual elements in your background page's document.
<script> for dynamically adding scripts to the background page (as long as they conform to extension CSP).
Among other things, since you can't include external scripts through background.scripts array, you need to create a <script> element for those you whitelist for the purpose.
<canvas> for preparing image data for use elsewhere, for example in Browser Action icons.
<audio> for producing sounds.
<textarea> for (old-school) working with clipboard (don't actually do this).
<iframe> for embedding an external page into the background page, which can sometimes help extracting dynamic data.
..possibly more.
It's debatable which boilerplate is "better": creating the elements in advance as a document, or using document.createElement and its friends as needed.
In any case, a background page is always a page, whether provided by you or autogenerated by Chrome. You can use all the DOM functions you want.
My two cents:
Take Google Mail Checker as an example, it declares a canvas in background.html
<canvas id="canvas" width="19" height="19">
Then it could manipulate the canvas in background.js and call chrome.browserAction.setIcon({imageData: canvasContext.getImageData(...)}) to change the browser action icon.
I know we could dynamically create canvas via background.js, however when doing something involving DOM element, using html directly seems easier.
Suppose I want the browser to load an image right on the first connection it makes to my website. How do I do that, considering that by default the image loads later on when it's actually called for?
Also, after the whole page finishes loading, suppose I want to load more objects (say images) that aren't required yet but are just for buffer. How do I do that? Help me people, I've been at it for quite a long time.
I'm somewhat successful with the first problem by adding a script tag while actually calling an image at the beginning of my index.php's html head part which goes like:
<script src="http://www.mysite.com/my/image/url.png"></script>
But this I realize is bad scripting.
As for "Why would you want to do that?", it's for educational purposes and also because when someone visits my site, I need to load and display certain things before other things get loaded.
For preloading you probably could start with
<body onLoad="Preload('image1.jpg', 'image.gif', 'image.png', ...)">
And preload is a JavaScript function which adds each of the array of images to DOM like
document.imageArray[i].src = args[i];
I often see that websites use more than one page to display their information, while I've always preferred to use a single page which automatically changes its content by means of a PHP script.. Won't it be faster and simpler to have only one page that changes every time using a webpage argument, instead of having multiple copies of the same layout?
For instance:
... <body> ... <?php insert_requested_content(); ?> ... </body> ...
should be simpler than having a bunch of pages with the same header, footer, navbar, etc..
When I create a website, I usually have one index.php page and then the content pages, which are included into the index.php by the script, when they are requested by an argument such as:
http://mywebsite.com/?content=news
So: why people still use many different pages? Is there any particular need of doing this, or it's just a matter of choice?
Do spiders encounter any difficulties when trying to access the content of a website created with this design?
Your program structure is usually made easier by having multiple pages to reflect your different content while maintaining a common header/footer and css that can be inserted as you stated above. Placing all of your content in one page and dynamically trying to determine what the user is requesting and display it properly can become a nightmare of if/else statements if your site gets much more than three or four pages of content.
I want to create a custom ./config/unavailable.php page using the layouts and styling used by the rest of my application. I could just copy the generated HTML that one of these pages renders, but then if I ever change the layout or style I would have to re-copy.
How can I render the unavailable.php page the same way I render the views?
I am using symfony 1.4.
unavailable.php is called when symfony is busy clearing its cache. You might want not to disturb it too much at this moment, that's why plain php is used. Copying html could be done by a cron task though, so if I were you I would try to combine cron, wget and sed to achieve this.
I'd suggest keeping it as manual HTML, a simple page. Whatever you need to do to copy over layouts/templates (which contain stuff that Symfony needs to execute to generate) isn't worth unless you plan having your app unavailable for most of the time. It's just easier to copy things over manually if you ever decide to make big CSS changes.