I want the visitor to see the loading GIF as soon as he enters the website, until the the website has completely loaded and ready to go.
HTML:
<img id = "firstLoadedImage" border="0" alt="title" src="Pictures/loading.gif" />
There is no CSS associated with this.
And I loaded every other image through my javascript document.ready call. This is the only occurance of declaring an image in HTML or CSS, beacuse I know that all the images are loaded together if I do that, but I only want this gif to load first.
But the problem still exists where in CHROME only, that there is a very noticeable delay before my gif image actually loads and starts to animate. I've extensively researched this and found the best matching solution, yet I tried their ways to find that it's somewhat a slightly different case from mine. - Loading GIF (Preloader) gets stuck only on Chrome -
The difference being that I'm using the GIF before the entire web page finished loading. I've tried dataURI with base64 already. It didn't work for me, as the same reasons from #amiregelz OP stated in his comments. So the only other solution is deleting the delcaration:
background-attachment: fixed;
But the only problem is that I never even used that code anywhere. So I guess the problem is now, what should I try next.
Any help from Guru's would be highly appreciated. Thanks in advance.
This issue should be fixed now in the newer versions of chrome.
Related
I work for a media company in Norway, and on rare occasion we see that an image will fail to render in its entirety. When this happens, we can refresh the page and the image will still only partially render. We have only ever seen this happen on Safari, and I have been able to reproduce it both on desktop (Safari 13.1.2) and mobile (iOS 14.4.1).
In the network tab, the image seems to have been fully delivered. The amount of bytes transferred is the expected amount. In fact, if we increment the height of the container by 1px, the image will suddenly appear in full, with no network activity occurring. In other words, the browser did receive the full image, it just is not showing.
Everything in the styling looks totally normal, but we still assumed this was somehow related to the CSS. However, we created a local override, and we were still able to reproduce with the following code:
<figure class="desktopi-45000 mobilei-45000 tableti-45000">
<picture>
<img itemprop="image" data-defer="view" sizes="(max-width: 640px) 640px,(max-width: 1024px) 1024px,1240px" title="- Du hører ikke hjemme her!" alt="- Du hører ikke hjemme her!" class="" srcset="https://www.dagbladet.no/images/73594916.jpg?imageId=73594916&x=15.742793791574&y=14.099216710183&cropw=72.431633407243&croph=57.57180156658&width=760&height=342&compression=70 640w,https://www.dagbladet.no/images/73594916.jpg?imageId=73594916&x=15.742793791574&y=14.099216710183&cropw=72.431633407243&croph=57.57180156658&width=900&height=405&compression=80 1024w,https://www.dagbladet.no/images/73594916.jpg?imageId=73594916&x=15.742793791574&y=14.099216710183&cropw=72.431633407243&croph=57.57180156658&width=980&height=441&compression=80 1240w" src="https://www.dagbladet.no/images/73594916.jpg?imageId=73594916&x=15.742793791574&y=14.099216710183&cropw=72.431633407243&croph=57.57180156658&width=380&height=171">
</picture>
</figure>
Here is an image comparison of what we see when the issue occurs. Note that it can take many, many tries before the bug occurs.
While trying to figure this out, we came across a similar question. However, the answers provided fail to elaborate on the root cause of the problem. One of the answers says to use decoding="sync", and that does seem to resolve the problem (at the very least, we cannot reproduce with that added). However, that is not a viable solution due to the performance impact it has. Given the other sites are not experiencing this problem and do not use decoding="sync", there is something else going on. The question, therefore, is why is this happening? What is causing this, and what can be done to resolve it?
When testing locally, this could seem to be fixed by adding either
decoding="async"
or
decoding="sync"
to the image-tag. For some reason, Safari and browsers running on Apple-products seem to struggle with automatically choosing the best suitable way of decoding images to render.
The most upvoted answer on the question you've come across does actually clarify it a bit. But for a bit more explanation, there the actual Mozilla WebDeveloper explanation here, and according to the second answer, iOS has a bit of a soft-limit when it comes to loading things in, and lower priority things (like something loaded asynchronously) are given less memory. By using decoding="sync" on an <img> tag you are specifying that it should be loaded synchronously, things loaded synchronously tend to be of a higher priority and therefore have a bit more memory to work with. You could opt to lower the resolution of the image in order to not have to rely on synchronous loading to allow a higher memory usage when loading the images in. As far as I can tell, this is, in fact, a known iOS/MacOS issue, but I cannot find any mention of work being made towards it. So synchronous loading or differing image sources (with different resolutions) or possibly even some modern implementation of iframe-style tech (like what's used on JSPs, or any kind of nesting like what can be found in Angular) can serve as ways to alieviate this issue, but it seems like something that Apple will have to solve in order for it to undoubtedly cause problems.
I may be wrong about this, since I am not an Apple Technician, but innate browser issues cannot be solved through Web Programming alone. I apologize for putting all this in an answer, but comments have a bit of a character limit and links count towards it.
in the developer tools, I noticed that if you change something in css, the picture is displayed completely...
it became a solution for me: after the picture was uploaded, using js I added css which will not affect the image on the page like (z-index) or what ever, but thanks to this, the picture began to be fully displayed
I'm using haxe and openfl to create an html5 application. I tested the app in multiple browsers and devices, all work fine except in Chrome on iOS 7 only. The images used are not appearing seemingly randomly. Every time I re load different images appear and others disappear with exception to a couple that are always there. Here is what I tried:
I tried setting the z-index on the canvas that is used for one of the missing images, as well as a bigger width and height.
I know that the images are being loaded, I used Charles to take a look. There are no errors in the console log and changing the time and place where the images are being added to the display list in haxe changes nothing.
I swapped out one of the images that are always there for an image that is never there and it still didn't load.
The file names had a couple dashes and spaces in them so I changed that as well with no effect.
It's a very strange problem that I can't seem to diagnose. nor can I really find anyone with a similar problem.
The main issue is the fact that I can't see what haxe is building that might be causing this issue.
This is hard to answer without code samples. My advise is to look at what's different about the pictures that stay versus the ones that don't, both in how you're coding and the pictures themselves. I've had problems with images displaying correctly on ios only to find the problem was embedded somewhere in the metadata of an image. Hope this helps.
I am working on creating a website with a background that transitions with a fade. I have an issue with display when viewing with Firefox. The site loads fine and cycles through the images, when the point comes for it to return to the first image it resizes to a tiny pic in the top left corner. This does not happen on any other browsers, and it does not happen with all of the images in the cycle. If I refresh the page the problem is fixed and the sizing issue goes. I have tried from other computers and the problem is consistent. A version of the site can be seen http://www.rhys-williams.webspace.virginmedia.com/ Any help with this issue would be a big help thanks.
SOLVED
I have resolved this problem. The issue is caused by the cycle changing quicker than the image loads. I added a second to the display time and it now displays fine :)
Remove div from this line -> so your code will look like:
<div id="slideshowContainer" class="slideshow">
I guess that firefox was confused because of it.
Edit: Also, there are few unclosed tags (html errors), but i think this was the main reason of problems. Also, document has no valid declaration... fix these things, and then try... i have tested locally, with base href, and all works fine?
Hm -> please try to remove this, too: next: '.slideshow'
next option should have selector for next button, if i remember well...
By linked images, I mean having an image in a directory and giving the path to the image in order to set an objects display or background. I've noticed that since using this method, my page is taking a considerable amount of time to load. So if this is the issue, what would be the alternative?
Thanks
I suggest using the Firebug addon for Firefox.
It breaks the loading time down and explains how long each thing takes to load.
But from your question i would say no, it shouldn't add any extra loading time on.
(I assume you mean loading an image from /index/pictures compared to /index/)
EDIT: Looking at your comments you say "more detailed image"... does this mean a larger file size and if so how large?
You can answer your question yourself by using firebug, We can't without asking a lot more questions since you have left so much needed information out. :/
Regardless of the location of the file, your browser still has to obtain the file. The key word there, is browser.
The data (regardless of type) is downloaded to the client (browser).
Regarding image size, try reducing image size, there are plenty of programs out there (I've found VSO image resizer rather useful in the past)
Remember, slow loading webpages effect SEO!
I'm experiencing a strange PNG issue in my as3 flash project. I am loading a bunch of PNG's into flash which have gradient transparencies.
In early slides, these are displaying correctly, later on in the project, the gradient transparency is showing as a solid black background.
Is this a memory issue? I've been pretty hot about memory clean up. All the images are loaded in using exactly the same scripts, and I can swap the images around with the identical results. It just seems like after a while flash stops showing the transparency right.
Images of my problem can been seen below.
Working:
http://s331209305.websitehome.co.uk/board/working.jpg
and then after the first level has played:
broken:
broken.jpg (same url as above with broken.jpg at the end (apparently as I am a new user here I can't have more than one url in a post))
I've been search Google for literally hours but can't find anyone experiencing a similar issue.
Any advice very much appreciated.
T
Ok, I know this is an old post but I too searched for a long time on google and only found this reference to the problem I was having as well.
Anyways, long story short, I fixed my issue.
The problem was I had set the alpha way to high. I set it to 5 and it did something similar to yours. I had to make sure the alpha was always clamped between 0 and 1.
Hope that was your issue as well.
I'm curious if you are loading them on top of each other, and you start seeing buildup.
it's hard to tell what exactly is going on without seeing any code, but here are some ideas
make sure that the BitmapData has
alpha enabled (this is usually done
through the constructor)
if this is a
memory issue (though this doesn't
seem like it is) try using object
pools. the HYPE framework has one,
but there are others too.
Check how they are loaded. I use the casa lib for loading, which makes the handling of the images easier, I load pngs through it and haven't had any issues like this.
post a simplified version of the problem. I've solved a problem countless times where I tried to post the problem, but would simplify it to the bare essentials and end up seeing the cause.