We are developing an image viewer with zoom and cet...We are developing with angular js and using matrix3d transformations on the images so we can manipulate them.
When opening our project with Firefox with 30 1MB pics it renders them quite easily, while in google chrome it makes problems with even 4 1MB images. I feel Like we are missing a few css lines which will solve it all.
What might be the causes for this kind of thing?
Related
This is less of a code-based question and more of a best practices-based question I suppose.
I built a scrollytelling data visualization with svg elements using d3.js. While it works just fine on my desktop, it lags quite a bit on mobile (I'm thinking perhaps because mobile has less cpu/ram capability). While making it responsive using chrome dev tools for mobile, I suppose I figured because it looked fine for that particular device (which it does design-wise), it would render the elements just the same performance-wise (which it does not when deployed to an actual hard device).
I suppose my question(s) is - Is there a best practice for preventing something like this from happening? I'm assuming I should have staged this on an actual device earlier so I would pick up on something like this occurring. Moreover, (and perhaps a dump question), are there well-working svg-to-canvas converters that would allow me to override this problem (are these even a thing?), so when device width & height is detected, it would run the canvas-copy as opposed to the original svg code which is better suited for more powerful/capable devices?
Many thanks.
I am working on a web application that stores and displays satellite images from a given location.
My problem is that these images are quite large (up to 20MB jpg-files) and this causes rendering problems on certain mobile devices.
On some android phones the image resolution is downgraded, while on some iOS devices the image won't even load. The iOS problem is maybe described here, but with no solution.
Does someone have any experience with this kind of problem?
I do apologize if my problem is to broad, but i am really just looking for some pointers or ideas.
I am developing in html/css with jquery/javascript and the server is hosted by cPanel with a Linux CentOS machine.
Regards Peder.
You basically have two options:
Split those large images into smaller images and tile them (still downloads large amounts of data, but at least the client can do it in pieces)
Downgrade image resolution. That is, dynamically serve the quality of image that the client can actually handle.
Many map websites will use a combination of both. Being, they download a few high-quality segments for the area you look at closely and low-quality for all the areas you aren't looking at as closely.
Recently a large number of users of my company's website have reported seeing black boxes on some images on our login page.
For example:
I've searched for solutions, and everyone suggests turning off Hardware acceleration in Chrome by going to Settings | Advanced | Use hardware acceleration when available and disabling this option, which of course I don't want to have to tell users of our website to do!
It seems like this has been an on again/off again issue in Chrome since 2015.
Is there a way to avoid this issue using CSS, different image formats, or directives of some sort?
EDIT: Some Additional information
It's definitely reproducible on different machines running the same version of Chrome, with no extensions installed, with a new profile user, and in Incognito mode. But not on all machines - only some.
The images in question are being loaded from a CSS Image sprite.
Here's a dump of my GPU info, which has this issue.
I've found 2 different solutions for our situation:
Remove the border-radius css attribute from styling these images
Stop using a CSS Image Sprite, and use an image or font instead to load these images from.
I need suggestions on how to solve this problem.
We are developing an image editing application using fabricjs. We also have developed the functionality to apply filters on images like the ones mentioned here(along with the code).
They work perfectly fine on images with size of 1100px X 700px but if the image size exceeds this the filters take time before they get applied on the image. What can I do to make the filter's application faster for large images?
You should start to look at version 2.0
Generally filters are faster and where possible webgl is used.
http://fabricjs.com/image-filter-webgl
We’re using Chrome for an interactive installation and appear to have hit some sort of image loading ceiling.
The app is built for a multitouch device and runs at 1920x1080. It's built on backbone and involves the rendering and removing of a large number of views which contain sprite animations (facilitated by the stepping of transparent png background images).
We’re preloading all of the images and listening for completion using David Desandro’s imagesloaded plugin. This worked perfectly at first (with less assets) and appears to work now, until you navigate further into the application. Despite the absence of 404s in the console and the confirmed presence of the files some of the images aren’t loaded and simply don’t appear. The problem persists even if we don’t preload the images.
The typical size of an animation sequence is 92250px x 450px and they come in any where between 1mb and 10mb each (that's after they've been optimised using the compressors behind grunt-contrib-imagemin). The image assets total is around 300mb.
What we’ve tried:
Applying any cache related flags in the chrome command line arguments when launching chrome (http://peter.sh/experiments/chromium-command-line-switches/) such as --disk-cache-size.
Caching all of the media assets using the HTML5 cache manifest.
Testing on different machines, both mac and PC. This produces the same results.
What we’re currently trying:
Reducing the size of all of the images by removing every other frame in the animations. This isn't ideal.
Changing the animation method to switch out (preloaded) individual images rather than sprites.
Preloading images in batches just before they're about to be added (not ideal).
Ideally we'd like to remove the ceiling on whatever this limit we've hit is. Any help/insights would be appreciated!
Whilst we haven't really got to the bottom of what is causing this issue, we have implemented a work around. Switching out the large sprite sheet animations for individual PNG frames does the job. I'd still be interested to learn exactly what the issue/limitation was for future reference...