We Keep Coding

Flickering Images despite preload

I am trying to simulate a video by switching image-frames via javascript. This works perfectly in Chrome while in Firefox (and IE/Edge) the background is shown while updating the frame. This occurs only the first time the image-source is rendered. It seems like the images are not in cache, however the network console shows that they get preloaded correctly.
The way the images are being replaced doesn't seem to matter. I tried changing the source from images/divs as well as controlling them via display, visibility, opacity and even by rearranging the z-index. The way I apply the css to it via jQuery (hide/show, animate, css) also seems to be indifferent. It doesn't even matter if other visible frames are "below" the current frame, it always flashes the background.
I managed to recreate the error:
https://jsfiddle.net/kL54ckLp/

Force image to reload in Javascript on Chrome?

I have two totally separate images called lock-icon.png and lock-unlock-icon.png. On a certain event, I change an image's source in Javascript with
document.getElementById("element").src = "/images/lock-unlock-icon.png";
This always works immediately on Firefox, but because I'm displaying a live HD video stream on the page that requires WebGL hardware acceleration, I need to use Chrome.
It sometimes works on Chrome, but pretty much never immediately; it seems like a random delay of at least a few seconds, at most never. If I examine the current "image location" of the icon after it should've changed, the url is the new, correct URL (which is obviously expected, because it's just querying the src property of the element).
What else should I be doing to force this image to reload in Chrome?

Load both images in separate divs, then just set display:inline on the currently viewable one, and display:none on the other. Then you can just toggle the two images by changing the CSS display property.

CSS changing background of TD causes flickering in Firefox

I have a page with an image gallery. Previously the images were contained in an HTML IMG tag and when swapping them, I changed the source of the IMG with Javascript. Now I need the images to be shown as background images of a TD. I then use the same script as before but I let Javascript change the CSS background property of the TD instead:
document.getElementById('galleryimage').style.backgroundImage="url('" + galleryArray[0] + "')";
In Firefox, this causes flickering (actually showing the background behind the TD for a millisecond) between the swaps. All images are preloaded properly and when I use the same images but with the previously used IMG tag, they swap without any flickering. The flickering does not occur in up-to-date versions of Safari, Opera, Explorer and Chrome.
Check it out:
http://www.siroccomosaique.se/SLUTTEST/galleri_.cls
I have hereby ruled out that the preloading is causing the flickering and I thereby deduct that the CSS background property of the TD is causing it. I have read a lot about thiese issues but haven't found anything that fits my situation. I have also tried to strip the page down so that basically only the tables where the actual images are shown remains but this doesn't make a difference (that was for ruling out that any of the underlying DIV's was causing the problem).

Difference in performance between img tag elements vs divs with background images?

Are there any differences in performance or load/caching behavior when displaying images in img tags vs divs with image backgrounds?
My example:
I have a site with many overlapping images, some of which I will need to load dynamically with javascript. One issue is that I need to anchor the images to the right of the element, so that I can do a nice wipe-to-right effect. Because of this I was using a div with background image positioned right. Couldn't figure out how to do this with img but since divs are working for me I didn't know if this would matter...

AFAIK, browsers cache images the same whether they're in a DIV or an IMG. In any case, I think this one of those cases where specific performance is defined as an implementation detail internal to each rendering engine (and possibly the browsers built around them). As such, it's both out of our control as designers/developers and subject to change from browser to browser and version to version. In other words, I wouldn't spend too much time worrying about it.

The main performance difference is using background images allows you to use CSS sprites. Having one image contain a large number of images from your page means the user only has to make one request instead of one for each image.

Another difference is with responsive layouts. If you have an element that is only shown at certain screen widths (ie, not on mobile phones), it will still load the image if it is specified in the html (using display:none for instance), but most all browsers now will NOT load the image if is a background-image specified in unused media query-CSS rules. A lot of early responsive layouts got criticized because they still used the same bandwidth as the full size sites.
It is also useful with such designs because you can easily specify different images for different screen sizes. "Retina" displays on tablets and even laptops now won't look their best without 2x res graphics. So... even if you don't do such things now, it is probably a good practice to get into, because you might find yourself needing it soon!

I think by using background-image attribute in the div, the page layout gets loaded first and image present in the divs loaded later after the dom is loaded. so by using background-image the html layout is loaded faster on the web browser.

The only difference I can conceive of it this:
You can't scale images as backgrounds, although you can for img tags. This would open a scenario where background images loaded faster becuase it forces you to have the correct native size as opposed to downloading the entire image and scaling it. However, the converse could be true: given that you didn't care about image quality so much, you could deliver smaller imgs to your page and scale them up.
I'd stick with whatever rendered cleaner (and more consistently -- IE/FF/Chrome/Safari/etc).

Technical differences yes, most notably you can set the width/height of an IMG tag and it will stretch the image, which can be useful in some situations.
The main thing you've got to keep in mind though is the context of the image within the HTML document. If the image is content, say an image in a gallery, I'd use a IMG tag. If it is just part of the interface I might use a div instead.

Why is image preloading ineffective?

My CMS project has a stylish web 2.0 login screen that fades over the screen using javascript. How come that even though I have made 120% sure that images are preloaded (I used the resource monitor in development tools) they still take a second to show up when my login screen appears. It completely destroys the fanciness! Take a look:
http://www.dahwan.info/Melior (link broken)
When you click login, the screen is supposed to fade to dark using a 75% alpha 1px png image. Even though the image is preloaded, it doesn't show up until after the animation is done. However, if you click cancel and log in again, the animation flows smoothly and perfectly.
Can anyone think of a solution to this problem? I'm having it with the rest of my CMS' GUI as well. It's like there was no image preloading what so ever.
Thanks for answers
EDIT: Ah yes, I'm currently developing this CMS for Google Chrome 5.0.375.99, adding multi browser compatibility later. Sorry for leaving that out

I have come up with a workaround to my problem. I have now tested this in three browsers on two different computers with perfect results. In short, in my image preloading function in javascript, i added each of the images into the DOM in an invisible Div tag.
$('#img_preload').append($('<img />').attr('src', img.src));
The images now being added to the Dom at page load, and according to my theory resting in the memory of my low-end computers, they appears instantly when my CMS needs them.
Thanks for your comments :)

A useful information about this problem:
The Codemonkey solution works because, by putting the images in a hidden div, the browser have to keep those images in memory and ready for a possible change of div's visibility. If the user needs to change de visibility of div from hidden to block, it has to be done instantly. This is why just load all images into an array doesn't work properly.

You could also just preload them into an array. Your problem might be caused by what is known as "garbage collection". This is where the browser looks for objects that are consuming memory which no longer have an instance on the screen and are not being referenced by anything else in memory.
If you preload images into your web age, they should be loaded into the cache, though. So, they should still re-appear when referenced again. However, images can also disappear if the cache expiration is not set for a long enough length of time for these types of files.
Your problem could also be browser-specific.... I have found that it is always best to create an "anchor" for pre-loaded content by placing them into an image array and then using the array to call up the images when needed instead of the image URL(URI).
Here is a quick-and-dirty article that covers this topic.
https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-5214317.html

The UI thread can only manage one task at a time -- it will either execute javascript or update the UI. If there is a lot of javascript parsing/executing before the code that preloads the image, that might be causing the delay.
Another suggestion is to disable clickability on the login link until after the image has been detected on the page.
To do so is fairly straightforward:
function disableBtn(el){
var btn = document.getElementById(el);
var btnId = btn.id;
btn.disabled = true;
}
To re-enable, set btn.disabled = false (after detecting that your image has been added to the DOM).