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).
Related
We have a simple css sprite with multiple images that are used for different states of buttons and displaying some rich texts eg. "You matched IMG IMG IMG".
.cssinfo_btn_Play_down, .cssinfo_btn_Play_hover, .cssinfo_btn_Play_normal{
background-image: url('pack.png');
background-repeat: no-repeat;}
.cssinfo_btn_Play_down{width:311px;height:107px;background-position:-1569px -664px}
.cssinfo_btn_Play_hover{width:311px;height:107px;background-position:-859px -544px}
.cssinfo_btn_Play_normal{width:311px;height:107px;background-position:-1181px -560px}
Button
<div id="btn-play" ng-class="{'cssinfo_btn_Play_normal': $ctrl.closeState === 1, 'cssinfo_btn_Play_hover': $ctrl.closeState === 2, 'cssinfo_btn_Play_down': $ctrl.closeState === 3}" class="cssinfo_btn_Play_normal" style="opacity: 1;"></div>
The wierd thing is that each time style using css sprite is applied, the source image is requested again. Since the image is already loaded, chrome correctly detects that and loads it from memory so there is no network traffic. While this is fairly quick operation, we do notice a small drop in performance. We also tested on Firefox an there are no additional request after initial load.
Repeated requests
If we untick background-image in element inspector and tick it back everything works as it should and no additional request are performed.
It seems that the moment css file is edited in browser (through inspector or sources) Chrome correctly updates img lookup table.
For buttons we can create workaround with all states precreated and just changing their visibility, but for texts there are simply to many possible combinations.
Any ideas/suggestions why this is happening in Chrome and how to avoid it?
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/
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.
When I'm trying to drag an image from one contentEditable DIV and drop it to another one in Firefox, image completely disappears.
Here is an example:
http://jsfiddle.net/VvAT2/1/
In both IE and Chrome image is moved (as expected), but in FF it's just removed from the first one, and doesn't appear in the second one. To me it seems weird especially since there is no javascript at all here, so it's kind of default browser's behavior. Is there any good way to control it? (I'd prefer not to implement the whole DD-thing in javascript, it obviously shouldn't be necessary for such trivial case).
PS: When it comes to dragging images from outside of the contentEditable, everything seems to be the same for all three browsers - image is just copied, and that's fine...
This video explains the problem best: http://www.screencast-o-matic.com/watch/cQ1Oc9f1L
Basically the directory is located here: http://www.ipalaces.org/uploaderprogress/grrrrrr.html
Is the problem piece using YUI.js as the uploading script. The YUI updates the table's row with new information on every event. So I have it update it with some CSS/HTML so that it does a progress loading bar. It works fine for all browsers but IE. I am not sure if this is a known rendering bug or what, and if there is even a fix for it?
the working-demo.html basically shows that if you just resize the div using javascript, IE renders it fine. Its just updated the table's row with new div information seems to cause rendering issues.
I couldn't reproduce the bug because you applied that fix. But I did take a look at the source. The way you are animating that progress bar just begs for bugs. Try compatibility mode in IE8 and you will see that it's shrinking instead of growing (because the element is centred) and that progressbar-completed element is 2x bigger then container. Same in Chrome and probably Safari.
This is how I would do it:
(source: maikumori.com)
Make A constant for example 250px. Then you have to make a background image with same size as A containing progress bar as if it was at 100%.
Then:
background-position = B = -1 * Math.Round(A * UploadedSize / FileSize)
Pros:
Takes less markup
If you make background image 2*A and B = B + A then you can have custom image for "blank" space therefore you can make fancier progress bars easily
Should work in most modern and not so modern browsers
Doesn't make a mess if user has css/javascript disabled
Cons:
A must be constant
Haven't tested =(
P.S.
Sorry for blinding colours, couldn't change them afterwards ... mspaint
I found a solution.
If I include this in the HTML then it will work fine:
<div class='progressbar-completed' style='visibility: hidden;'></div>
It seems like IE is having trouble maintaining the "memory" of the background file when its dynamically created in javascript.
Putting the DIV in the html itself seems to make the memory of the background file persistent in IE.