I am developing a website which can be found here.
In a nutshell this is a fluid dynamics solver executing in webgl fragment shaders. The result is mapped to a textured quad and rendered on the canvas.
While doing some development work this weekend, I noticed that the Low and Medium resolution versions of the page are no longer working on Chrome (see the links in top right corner). However, if you open the page in Firefox everything works as expected. Be warned, this page is not expected to work on mac unless you've enabled webgl, it doesnt work in IE, and I havent tested it with opera.
A few other odd symptoms:
The mapping of mouse position to canvas position is now wrong in chrome unless the window is fullscreen.
The low and medium quality version appear to show only a tiny section of the low right corner of the texture.
To observe this in low/medium click the Analyze tab, and quickly change the velocity slider between low and high. Try this out in high mode to see the difference.
Last weekend the framerate in chrome was 60fps on my machine, its now 30fps even in high quality. Firefox gets a stead 60fps
The only real difference between the low, medium and high implementations is the texture resolution, which is 256x32, 512x64, 1024x128 respectively.
Can anyone shed some light on what is going on?
I'm not sure if this is the problem, but based on the simulation (and the corruption artifacts I'm seeing) it seems like you may be using floating point textures to store/render the simulation state. There was a semi-recent change in Chrome that fixed a bug in how filtered floating point textures were exposed and required some code changes. You can read about it here:
IMPORTANT: Your WebGL floating point texture usage needs to be fixed!!!!
Related
I am building a website for me and I care about performance, speed, user experience and a lot more. When I started I didn't know much and I made an initial design using adobe xd. Then using webexport plugin I got a html file that has 2k+ lines of codes for scale to fit any screen and proportional resize of everything. I think I made a 1080p standard artboard but somehow it was way too big like 3554px by 2216px. So the webpage is now that big and scaling is running on it. I don't think it's too big for a browser to handle. Things were good before chrome 97 or 96 update. After that chrome and any browser running on chromium just can't scale my webpage fast enough to fit the screen. I see big divs getting smaller and it takes kinda like 500 ms to settle with decent setup. A lot of variables can affect the performance like if the machine(pc) and network is slow the scaling takes couple of seconds which is too much.
Is there any way to hint the browser to do the scaling first then make the page visible? The older version of chrome was doing it right. I can make the page visible after 600 ms using setTimeout function but doesn't seem what I want.
CSS
will-change: transform;
Tried this but it has bad effect like blurry text on my content. I don't know why it's pushing the browser to it's limit sometimes, maybe I can better optimize my page but these browsers should be more powerful (safari is the worst - can even render the webpage)
This is the home page
https://elomymelo.com/
You should see big page fitting inside the screen and it'll probable take 200 ms pretty fast
proportional resize on window also works
This is a heavy article page
https://elomymelo.com/oneplus%20nord%20review.html
I tried to hide the scaling effect in this page but not satisfied because browsers mess up sometimes. I need the javascript scaling done much faster like visitors will not see that weird transition.
First, sorry for my english. I'm from Russia, I've tried to get answer on russian version of Stack Overflow, but no success.
Right now I'm doing a website on my work. It contains a lot of heavy images and visual effects (according to designer's layout). While I was testing the main page, I ran into strange bug. It is very difficult to catch it, but our designer saw it on his iPhone XS max and iMac with Retina display 5K. Me on my Xiaomi Redmi 4A, iMac Retina 4K and Macbook Air 17 couldn't catch it.
Please, take a look at the screenshot. How this block works: we have three pictures, when user swipes left or right, they are moving, and centered image is scaling to 110%. I'm doing it via CSS3 and jQuery.
It looks like a trace from immediately stopped vehicle. Does anybody now why this happening? Maybe I'm doing something wrong?
Images are in PNG. On screenshot you can see two normal states and one with bug. Bug was captured on iPhone XS max, normal states are captured in Chrome Developer mode (simulating iPhone 6/7/8 plus).
Thank you
Link to picture:
Bug
I'm currently working on a small canvas game written in pure javascript from scratch.
The game involves a 2d lighting algorithm similar to this one, but with one light source and 25 polygons which makes for about 30,000 calculations per frame.
My frame rate is great in Safari, meh in Chrome, and unplayable in Firefox. However, if I have the Chrome developer console up while playing the game, the frame rate is the same as Safari.
What could be the reason for this?
After the comments suggested the window size might be affecting the frame rate, I found out that the smaller the window, the smoother the game runs but only in chrome. The amount that is drawn on screen or any calculations used by the game don't depend at all on the screen size.
I measure the frame rate difference purely by eye, and you can see the effect in these gifs:
Bad, big window:
Good, small window:
The game runs much smoother in the browser than is apparent in these gifs, but the effect is still noticeable.
I can get the same effect to happen with the first example in the link that I posted. Is it just me or does anyone else get the same effect?
Even stranger... I gotten the same effect on several other websites, like Facebook when I scroll the home feed. The bigger the window, the choppier the scrolling gets. Is this a Chrome specific thing, is anyone getting similar results?
I've seen this as well in my pages/applications. The issue seems to apply to anything, but is more pronounced with canvas and accelerated CSS. As far as I can tell, this issue is a performance bug relating to Chrome's composited layer rendering. Basically, Chrome breaks the page up into layers and uses the GPU to render those layers. You can see these by enabling the "Show composited layer borders" option in the "Rendering" tab on the dev console. Chrome's FPS performance decreases as the number of composite layers increases, regardless of the layers changing or not.
Here's an independent example. Steps to reproduce:
Load this page in Chrome, it's a relatively simple animated CSS demo that is a fixed size like your game: http://www.subcide.com/experiments/fail-whale/
Bring up the Chrome developer window (pop it out so it's an independent window) and enable the "Show FPS meter" option.
Size the window small so that it just contains the fail whale demo. Note your FPS.
Now size the window large or full screen it. Note your FPS.
With a small window, I get 55 FPS. Full screen, I get 34 FPS. I would expect the FPS to be nearly the same, regardless of the page size as the animated area doesn't change. The FPS seems to be proportional to the number of composite layers on the visible screen. Also, resizing the window results in the animation being chunky and skipping frames. If I perform the same window resizing in Safari, the animation stays smooth. Safari knows there's nothing new to render, while Chrome is seemingly doing a bunch of work for no reason.
So the reason why you see better performance when your dev console is open is because you have your dev console inline/embedded with the page, which makes the page itself smaller when it's open. This results in a page with fewer composite layers for Chrome to handle, which results in better FPS. If you pop your developer console out so it's an independent window and doesn't affect the page size, your FPS won't be affected by the dev console being up or not.
This appears to be the "why" this is happening. Now, if anyone figures out what can be done about this, I'd certainly be interested to know.
vI know to some extent this is a known issue that has been asked here but never answered, but I'm hoping for some additional insight.
I have a simple SVG image in a div on a web page. I want to be able to zoom the image using pinch gestures and have the SVG render sharply. It doesn't need to be sharp during the zoom, but should be sharp after the gesture is complete.
I'm doing my testing on a Windows 8.1 computer with a touch monitor, on an iPad, and on an old Android Galaxy Tab. On the main computer, I'm using IE11 and Chrome. For handling touch gestures, I'm using Hammer.js. I'm doing the zooming by modifying the transform CSS using the jQuery css() function (I'm setting scale3d and translate3d).
IE11 on my computer works exactly like I would like it to. It keeps the SVG image sharp throughout the pinch zoom and the image is always sharp regardless of when I set the CSS.
Chrome on my computer always renders the SVG blocky when I am zoomed in using pinch zoom. It is blocky during the zoom and does not get sharp afterwards. If I add a call to zoom the image after the page (x13) is loaded, the image is sharp. If I use a setTimeout() call to reset the zoom and then rezoom the image after the pinch zoom ends, the image is sharp.
On the iPad and Android tablet, the SVG never renders sharply, regardless of when I zoom it in code.
Does anyone have any ideas of how to reliably end up with a sharp rendering of SVG after a pinch-zoom is completed? Does anyone have a better solution? Using the SVG viewBox to zoom and pan during the gesture does not provide good enough performance for our more complex SVG images. I'm thinking of attempting to use the hardware accelerated scale3d/translate3d during the gesture and then attempt to convert this to new SVG viewBox settings afterwards, but this is a challenge and I'm not sure panning will work correctly after this is done. Any pointers or ideas are greatly appreciated.
Having just tried to answer your other SVG Question I will have a try at this one.
Michael Mullany is spot on that GPU translations will never give you a sharp image. This is because the GPU just maps one array of pixels to a new one. Because it has no concept of lines or rectangles the resolution is set by the time the GPU gets the image. The CPU will always struggle to re-render in time for a smooth drag.
What happens to allow some browsers to produce a sharp image is they do clever manipulations like rendering more pixels than they need so some zooming can happen without loss of resolution. These however are completely inconsistent and just not possible to rely on.
The as I see it 'correct' solution is to translate and zoom with hardware accelerated transformations during a pinch or zoom and then to refresh the viewbox with no css transformation when the translation has finished.
Challenges to overcome are
The css transformation will use screen coordinates but the viewBox manipulation will use the SVG coordinate system.
There are browser inconsistencies in both screenCTM and device pixel ratio
limits so that people don't drag or zoom too far need to be calculated in both systems
Pinch centerpoints also need to be calculated in both
To improve performance further the css transforms will be wrapped into updating on the requestAnimationFrame loop.
My working solution is hammerhead2. I am concentrating on desktops and android mobiles first and it seams to be working for them. To simplify the problem zoom is always centered to the screen center. I do however thing this is currently one of the only solutions. Here is an example of it working.
I have a problem similar to one described in the following questions.
KineticJS : scaling issue while using custom clipFunc on 2x pixel aspect display
In my application: (please try on retina ipad vs normal ipad or desktop browser, even iOS simulator would also do)
There is are two canvas layers, one of them contains a blanket group that I scale with pinch-zoom gesture in the range of 0.5x to 1.5x
On the retina screen my canvas gets zoomed out to 1/4 the screen when at 0.5x
Now, with the change suggested in the comments, I managed to make it scale it properly however touch events are no longer scaled accordingly. Any ideas whats going on here?
Note that it is working perfectly on non-retina screens.
Am using KineticJS 4.4.3 - as its was an academic project that began early this year for proof-of-concept and now I'm continuing it to make a complete application.
Thanks!
My problem got solved after I upgraded to KineticJS 4.7.4
It however broke the clipping code I had as clipFunc was deprecated but that's a different issue which was resolved by resetting clip parameters on dragmove event.
Not an efficient solution but it works for now!