I am drawing many frames on a canvas using KineticJs library.
I am creating a new javascript Image object with the relevant image source for every frame and setting the new image on the canvas after the image loaded.
I see that it takes about 22ms on chrome and about 600ms on ipad safari ... that's a big difference, has anyone experienced such a behavior and does anyone have any insight on how we can overcome this issue? For example maybe I can force the ipad to use its gpu.
Any response will be highly appreciated.
This page says that iPad cuts off loading images at 6.5mb. I'm not sure if this is still true but I've definitely noticed throttling before 6.5 mb.
Since I'm using a photo scroller, what I've done is load the image names in a hidden html field and then load the next image in a hidden image tag 2.5 seconds before the scroller displays the next image. Of course, you could also load the image names in a JavaScript array. I can provide code snippet if still interested...
Related
On my website, I have several images with an onload and onerror callback
<img onload="imgCallback()" onerror="imgCallback()" class="article-img" src=":assets:/price/12-2.jpg" alt="A chart showing vitamin and mineral content of liver, kidney, spleen, heart, broccoli, kale, banana and apple" />
Some initialization is only done after all images have loaded because I need the full height of the container element after all images are shown.
This works fine on my desktop, however, it seems to not work on some mobile browsers. I have tested this on my Android Chrome browser and it seems to only load images lazily after I scroll far enough down, delaying page initialization that is expected to happen on the initial loading of the website.
I can't really think of any other way of solving this as I need the full width of the container post image loading, something I don't know statically, therefore I am asking if there is a way to signal to the browser that it should eagerly load images?
Found an answer here.
I simply had to add loading="eager" to my image tags.
I'm building an app using Vue 2. There's a page that contains a simple image gallery that contains about 20 images and one large page background image.
The background image of the page itself is actually contained in a fixed div element that is position: fixed;, has 100% width and height and uses background-size: cover; to display the image.
All of the ~20 items in the gallery as well are using div elements with background-size: cover; displayed in a 3-column grid and the images are displayed using the dynamically generated background-url CSS property using a Vue computed property. The image paths are never being changed so they aren't being recomputed constantly AFAIK.
The performance of this page in Chrome is abysmal, loading takes forever (those are some high resolution images, though, 4K in width) and once the images are loaded I can somewhat interact with the page but everything is extremely laggy and sometimes the page stops responding completely.
On the other hand, in Firefox and Edge everything is basically buttery smooth, both during the loading of the images and during the scrolling/rendering. The interaction with the app is never blocked.
What I remember trying to fix this is replacing the div elements with regular img tags and loading up images using those. Also, I've tried caching the images, I've tried using static image URLs for testing purposes - the same thing happens every time - other browsers handle it well, Chrome is choking on it.
Here's a screenshot of the performance summary in ~30 seconds, from the moment I click the page URL to the moment that basically everything is loaded and the browser is still struggling to render anything and process any interaction with the page. Obviously the painting phase is an issue here:
Any advice? Thanks!
This question is hard to answer as it is a very specific problem.
You can analyze what is causing this behaviour in chrome by using the developer tools:
Open the developer tools in chrome by pressing "Ctrl+Shift+I".
Go to the tab "Performance".
Hit the record button and do the action which has low performance.
Hit stop and you get a breakdown what happened in the background.
If you don't find the issue with above suggestion, you can post a detailed screenshot of the performance breakdown here, I might be able to help you with it.
I am trying to make a website with a minimalist feeling to it, so I put a fullscreen image on the background as background-image of body. I have a transition: background-position 1s set as a CSS rule for body and an easing function, to create a smooth scrolling effect when going to other pages in the same HTML file (I have no actual scrollbar, just navigation elements). The thing I noticed was that once I started scrolling, the memory reserved by the page went from a small 77MB to over 500MB! I tested this in Firefox, but it doesn't seem to happen (either because pages have no separate processes or memory allocation works differently, I imagine). Why does this happen in Google Chrome and not in other browsers? And how can I reduce the enormous amounts of memory reserved by my page?
To give some information on what I am using:
Browser: Google Chrome
RAM: 8GB The page uses javascript with the
following plugins:
jQuery
Bootstrap
Background image dimensions are: 1440 x 540
A few possible causes of the problem:
The image is too big to be rendered with a transition and an easing function.
I should not use background-image for this, but create a new <img/> as a background.
I somehow only checked it with developer tools open in Chrome, increasing the memory allocated.
It's not the image causing the problem, but the web fonts I scroll simultaneously with the background image, also using transition and an easing function.
And I want to add that maybe this is not even a problem after all, it's just that I have never seen a page go over 300MB with memory allocation.
Not sure if this should be posted as a comment instead, however:
Nothing you can do about that. Chrome trades RAM for performance.
For instance each chrome tab runs on its own process for that purpose.
I had cases when a single youtube tab took over 1.5gb memory & virtual memory.
Even a blank tab takes 45mb memory for me.
So there is no issue with your code at all.
I'm using Skrollr.js to animate an image sequence. I took inspiration from how the http://moto.oakley.com site handles image sequences, and built some scripts to help me automate writing a series of images into the DOM. Then, I use Skrollr to change the display:none; to display:block at key scroll positions. My script preloads all the images before dispatching a complete event, and then I initialize Skrollr and allow interaction.
So, basically I have a <div> containing that has a bunch of these:
<img src="seq-000.png" data-0-top="display:block;" data-50-top="display:none;">
<img src="seq-001.png" data-0-top="display:none;" data-50-top="display:block;" data-100-top="display:none;">
<img src="seq-002.png" data-50-top="display:none;" data-100-top="display:block;" data-150-top="display:none;">
...
Now, this is working just fine in Chrome and FireFox (naturally), but Internet Explorer 11 seems to have problems rendering the images during the first scroll through the page. In other words, when I first load the page and scroll the images blink into place like they have not be preloaded, but subsequent scrolls the animation is perfectly fine. It's like IE11 hasn't rendered the images into memory, so the draw speed to the screen has a delay the first time any image is displayed.
I don't think Skrollr is the problem. Perhaps there's some magic CSS setting I should using.
Does anybody have any tips for making image sequences so they look ultra smooth everytime even in Internet Explorer?!?
Thanks!
I've got an issue similar to this one:
iPad/iPhone browser crashing when loading images in Javascript
... but I'd like to clarify that my issue is caused by the same memory issue, and if so, what I can do about it.
I understand the proposed workaround of loading "tiny.gif" images for img elements that aren't in view, but the thing is, I'm not using loads of img elements. I'm using four. Three in a sliding div that slides in the next/prev image, and one that displays the current image while the sliding div is doing its sliding thing. It's a little hard to explain the mechanism, but the point is, there's only four image elements and I'm just continually swapping their src.
So what I don't get is.. if there's only four img elements in memory, how am I running up against the memory issue? If slide_one is an image with a src of one.jpg, and I change its src to two.jpg, surely one.jpg is cleaned out of memory, right?
Just a little background: I'm running a HTML page through a UIWebView as an iPad app. The behaviour I'm seeing is that I can load about 25 of these roughly-250kb-per-image JPEGs, and then it stops loading them (the src attribute is updated but the image stays blatantly unchanged). This sounds suspiciously similar to the 6MB limit I've heard mentioned, but I'm not seeing any warning or crash (at least, not in the iPhone Simulator where I'm debugging this).
Any advice gratefully received... :)
FWIW, I solved this by swapping bg image on the containing div rather than using an img element and swapping its src.
So either it's a bug that memory management doesn't allow more than x MB of images loaded, or it's a bug that bg images don't count towards that total.
Ho-hum.