This is quite simple, I want to increase the performance of my page by using canvas to generate diagonal lines pattern instead background-image.
Should I do that? why?
If you're displaying static content, is slower and much more obtuse. and do completely different things, the former being for dynamic graphics using JavaScript and the latter being for static images retrieved from a URI.
Browsers tend to be optimised for loading IMG sources while the HTML is streaming: so you'll see an image before the page has loaded completely. Canvas, on the other hand, will be dependent on the DOM being loaded, so (typically) won't load until the DOMContentLoaded event has fired. Add to that the latency in creating a Canvas context and the memory requirements and it almost certainly isn't what you want if the images are truly static.
If you want to do something fancy with the image why not load the image in an IMG tag and then convert it to a canvas once loaded to do the transformations?
Related
If any dev reading this knows the solution, please reply.
Less prominent with app.disableHardwareAcceleration();
Appears to depend on hardware capability.
Does not stutter once you have scrolled to the end. So, its related to how chromium render images?
Images are preloaded by setting src on const img = document.createElement("img"); inside useLayoutEffect(()=>{ },[])
If you have an answer then post in this Github Repository Link.
Expecting no stutter when scrolling down images.
I try to get my head around the relatively new img attribute "loading".
I understand that if an img has the attribute loading="lazy" then it will tell the browsers that support the attribute, that it can be loaded when getting near the viewport.
So why not always set loading="lazy"? Those images that appear instantly on the screen would get rendered anyways, as they already are inside the viewport. So basically loading="lazy" is ignored in that case anyways.
I also see in this demo https://mathiasbynens.be/demo/img-loading-lazy that the pictures in the top of the dom are having the loading="lazy" attribute set.
I got the link above from: https://web.dev/native-lazy-loading/
Thanks in advance :)
You should avoid setting loading=lazy for any images that are in the first visible viewport.
Source: https://web.dev/browser-level-image-lazy-loading/#avoid-lazy-loading-images-that-are-in-the-first-visible-viewport
In short, if the image is not loaded lazily, the browser can start fetching the resource immediately. Lazy images need to wait until the Layout phase of the browser rendering pipeline, to determine if an image is in the viewport or not.
Adding loading=lazy unnecessarily will likely add a small amount of delay until your webpage is fully rendered.
One of the reasons I can think of to not always use lazy loading is when the network can be disrupted. In that case, you want to download as much as possible while the connection is active, so that the most of the page is usable when the connection is down.
It’s a hint to the browser that the image might not be immediately useful/visible and that it should prioritize other resources. The third image in an image carousel or images appearing far down on the page are some good examples of when this attribute is useful.
Overly lazy implementations, such as Firefox, don’t images until they’re scrolled into view. This causes the browser to display a white area while the image is being loaded. This isn’t an ideal user-experience. Chrome, on the other hand, loads images 3000–8000px before they appear on screen which is too eager again.
Chrome won’t load lazy-loaded images even when they’re within the viewport for background-opened tabs. This is caused by a limitation of Chromium’s IntersectionObserver and may be fixed in a future version.
I'm building a web app which has 360 degree images loaded into an a-sky primitive. I'm using aframe-react. There are total of 20+ 360 degree images and only one img asset inside a-assets. once user switches scene react will change src of asset img and scene will re render. Everything works fine but it's using lot of memory because of caching. One time it used 4GB+ memory. In mobile the web page crashes after switching through ~8+ images. How do I handle this situation?
I tried looking into THREE.Cache but images are not cached there.
Is this memory usage has anything to do with using React?
There's an issue for A-Frame to automatically manage it, but right now have to hack around to clear textures.
AFRAME.scenes[0].systems.material.textureCache[url].then(function (texture) {
texture.dispose();
});
I have a QML GridView, with a huge number of simple icons in it. The number can be in the millions, but only around a thousand will be visible at the same time, and there are only a few dozen types of images, so I guess they should be cached well.
If I use PNG images, everything is fine. The startup time is relatively long, but after everything is rendered, the application runs fine even on low-spec machines, and scrolling / resizing / zooming in the GridView is also fast and smooth.
However, if I use SVG instead, it slows my system down significantly. Even after everything is rendered, the responsiveness of the application is horrible, even GUI elements unrelated to the GridView are showing significant lag, the mouse cursor can barely be moved, etc. I thought after they are rendered, SVGs are presented just as any other image. Why must the CPU be busy if I don't even interact with them? And, most importantly, is there anything I can do about it? The same thing happens if I have SVG images containing nothing but a single rectangle, and use the same image in every cell. So it must mean the objects themselves are doing something.
"The number can be in the millions" and *"The startup time is relatively long"- those statement warrant a discussion about the design of your data model and bitmap caching strategy. But you didn't provide any code. So the following is a guess.
I'm not sure if you are loading the SVG images in C++ code or through QML, but I suspect you aren't setting the sourceSize (width and height) properties when you import your SVG. Hence, it's getting mapped into memory at a much larger size than it's getting rendered at. That is, it's eating up a lot more memory than it was with pre-sized PNG files. Or perhaps it's getting mapped in at a smaller size and Qt is is spending a lot of time having to resize these images at runtime as it scrolls in/out of view.
Open up one of your SVG files with notepad and look at at the attribute to see what the import size is.
In any case, try making sure your sourceSize.width and sourceSize.height match your render width/height.
Image {
id: icon
anchors.centerIn: parent
source: "cloud.svg"
sourceSize.width: 50
sourceSize.height: 50
width: 50
height: 50
}
Loading SVG's is an expensive operation...
Gridview manage dynamic objects.. creating visible items and destroying invisible items each time ....so, must render SVG each time you move the grid
One very bad idea is use that:
GridVIew{
cacheBuffer : 6000
//create 6000 items ...long startup time and memory expensive
...
}
This is a much better option:
Image {
id: icon
asynchronous : true //load image in asyncronus thread
sourceSize.width: width //scale as item size
sourceSize.height: height //scale as item size
...
}
If the load is too slow, you can add something like "LOADING..." text in the item background...
I have a dojo animation object of about 15 images. I'm also using dojo.fx.chain to link them all together.
Right before I create all my dojo.fadeIn's and dojo.fadeOut's I added in some basic javascript to preload each image.
My question is: Am I doing this the hard way or is there some function/attr I can set in the animation object to do this?
I do not think there is a predefined method in dojo to preload these images for your animation.
I guess you are listening image.onload and image.onerror events to preload images, it is a common method. If you feel it is too difficult and hard to control, you can try a simple clean css way that is to put an invisible div into your page and set background images with these animation images. When the page load, the images are automatically loaded.
dojo Animations are not specifically geared around images, they work on an abstract level and may operate on DOM nodes. So, there's no built-in support for IMG nodes specifically.
There is dojox.image.preload (http://api.dojotoolkit.org/jsdoc/HEAD/dojox.image.preload) which will do the work virsir suggested of loading images into an offscreen div, but it does not (currently) arrange an onLoad event hook for you to detect when they're loaded and thus play your animation.
I imagine you could use preload()'s return value and use it to hook into onLoad, but that's an exercise for the reader. Have a look at the source code, dojox/image/_base.js.