My current issue is that I have a loading bar animation on my web-based app that is shown (obviously) when the whole page or specific things are loading up. It is supposed to look like one of those Samsung TV Apps so it needs to be quite polished with the UX.
What me and my team are doing right now is a mix between creating an element for it and I assumed it gets cached in the local device which is an issue. I've known of a few ways that I can go around this like adding a Math.random() query at the end of the src url but I'd rather not follow that route for now.
I also saw a way that I believe involved simply setting the element.src = 'theSameUrl.gif' URL to be the same and I assume forcing the device to reload the file instead of using the cached one.
I would also be open to trying new file types that could make this a lot easier but I must keep in mind that this app will work on a LOT of different hardware, from Samsung TV's to BT Boxes or even Virgin Media Tv Boxes, amazon firestick etc.
At this point I'll take anything :P
You can "force it" to reload by wiping it source: img.src = ""
Then you set it again: img.src = "your_src_path"
This way your .gif will start from zero, at least on Edge, Chrome and Firefox, it should work the same way on a TV.
I am writing single page application which displays lot of images.
I have problem with consumption of memory by browser because he still remember images which I deleted from DOM (and img objects destroyed) from page.
In development toolbar I can still see in Resources the images which are not displayed yet.
Test it in Chrome and Safari.
Is there any way how to release these images?
Hi I'm following a tutorial in using easelJS for writing browser based games. And the tutorial is going fine but I've noticed some problems whilst playing the animations on chrome.
Chrome runs the animations slower and once played through once the same animation will not play again unless I reload the page.
Running in Firefox it doesn't have any of these problems.
Here's the link: (use inspect element for code)
http://david.blob.core.windows.net/easeljstutorials/easelJSSpritesTutorial03.html
I've heard there are some caching problems in chrome so I thought this might be the problem.
Manually deleting the cache does in fact allow the animation to play again without a page reload, but it still runs slowly (compare it to firefox).
As I want to code for cross browser compatibility is there a supported way in chrome to combat these problems? Such as blocking storing the images in cache or something? (A last resort I hope)
Thanks in advance,
Kyohei
EDIT: It seems the speed of the animation is the same on ie10 so not sure what speed it should be you know.
The reason this will not work after a "reset" is that you are relying on the image load events to kick off the animation. This will work the first time, but the second time, the image is already loaded, and therefore you will never get an onload event from the images (meaning no "startGame()".
Since this is a simple example, maybe the best approach is to create new Images each time. Just move these lines into your init:
function init() {
var imgMonsterARun = new Image();
var imgMonsterAIdle = new Image();
// Other stuff
}
i read an article Fix your Timestep it will help you , just need to convert it to javascript , read it carefully .
i have a problem in iPad Safari. when i use Javascript to append image to div using elm.appendChild(img) the images don't appear until the screen is touched. the same code works perfect on IE,Firefox,Chrome,and android browsers.
i have uploaded video that shows the problem. http://www.youtube.com/watch?v=nBN9fThDik8
is it related to the device ? or there some special code for loading images in iPad safari?
or any solution ?
iPad (more so than iPhone as far as I've experienced, although that's just a gut feeling) is notorious for avoiding loading and rendering large resources unless it decides the user is going to see them.
How about faking the user input required to trigger the render, ie the scroll, after appending the image? Sample code here, may work:
function scroll(){
var body = document.body;
var xy = [body.scrollLeft, body.scrollTop];
window.scrollTo(xy[0],xy[1]+1);
window.scrollTo(xy[0],xy[1]);
};
To be called immediately afterwards, eg:
appendImg();
scroll();
Suppose in Javascript that you assign the SRC to an IMG tag. It is a large SRC and you want to cancel it before it has finished loading. Assigning the SRC to another image will not stop the data from loading.
That is, in the middle of the load you can assign the SRC to another smaller image and the smaller image will be loaded and appear in your browser. However, the original SRC still continues downloading.
Similarly, deleting the IMG node will not prevent the SRC from continuing to download. No guesses please, look at the repro steps.
REPRO
Load this URL in Chrome in Windows: http://68.178.240.17/imgLoadTest/imgLoadTest.htm
Open up the developer panel by pressing CTRL-SHIFT-J
On the top row of icons in the Chrome developer panel click the Network icon to watch network activity.
On the web page loaded in Step 1 click the Load Image button and watch the developer panel as a large (32meg) image starts loading.
On the web page click the Try To Cancel button to load a different image.
A small image loads, but watch the network in the developer panel and notice that the large image continues to download.
Quick answer
Setting the src attribute of the img tag to the empty string will interrupt the current download, even on Chrome.
Details
Nowadays most of browsers implemented that out-of-standard mechanism thought in the old answer to programmatically abort the connection. This is not achieved through a protocol request, but with a client-side in-memory operation. Keep in mind that is not a standard behaviour, but most of vendors courtesy. That is, it could not work on every browser.
I've prepared a jsfiddle showing this mechanism in action (keep an eye at the network panel of the inspector).
Old answer (2011)
Your browser asks for that image with a specific HTTP GET request, as specified in HTTP protocol. Once it asks for it, the http server starts the transfer.
So, it is between the browser (as http client) and the http server.
Since http protocol does not takes into account the option to abort a transfer, the browser should implement a out-of-standard mechanism to programmatically abort the connection. But since this is not specified in any standard, i think you won't find any way to do that with javascript or any client side code.
Cancel with transparent base64 encoded GIF to avoid additional requests and double page load on android:
var img = new Image();
img.src = 'http://google.com/favicon.ico';
img.src = 'data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEAAAAALAAAAAABAAEAAAI=;'
Although I can't find the bug report now, I believe this is a long-standing logged WebKit bug. Firefox (and IE I think) have more sane behavior. I'm going back a bit in my brain, but if I recall on those browsers, resetting the img.src will in fact cancel outstanding downloads. I am positive that Firefox does this when a download is "waiting in line" for a chance at an open HTTP connection, and I seem to recall that it will actually force close connections sometimes.
I've never found a way to coax WebKit based browsers into cancelling an img download in progress, whether it is just queued or already actively downloading.
This really sucks if you're making something like a mapping client and need more fine grained control over images.
Setting the .src property to an empty string should cancel the load:
//load image from url
var img = new Image();
img.src = 'http://somedomain.com/image.jpg';
......
//cancel load
img.src = '';
Yes, page is downloaded twice on Android when an img tag has an src="" attribute.
This still occurs on recent Android versions.
I have not found any other browser that does that.
But I found a solution: use an img tag without src attribute.
The ultimative answer is web workers.
Load the image inside an webworker and stopping the web worker will stop the image loading.
You can get the idea from this code:
https://github.com/NathanWalker/ng2-image-lazy-load
this work for me:
imageVarName.src = '';
imageVarName.onload = null;
imageVarName.onerror = null;
the src property must be a valid non-empty URL
So null or empty string are not legal (even though they sometimes work).
Use:
img.src='http://xxxx';
img.onerror=null;
(see here)
Sadly, setting src to an empty string does not work in WebKit-based browsers like Safari. Here is the link to the bug report which Stella mentioned.
https://bugs.webkit.org/show_bug.cgi?id=6656