We are working on a video player plugin with FireBreath. It has a windowless mode, and in Chrome on Windows it produces a very strange effect.
Whenever we try to paint in the hdc the pixels appear either in the right colour or inverted, depending of the value of the most significant bit in any of the 3 channels.
This means that in full colour depth on average half of the pixels appear inverted, while the other half is fine. It is the same both when displaying a video frame using StretchDIBits(), and when just filling with solid colours with FillRect(). The SetStretchBltMode() is set to COLORONCOLOR.
We could not find a solution so far, our temporary hack is to convert the colours to half the depth and set all the most significant bits to 1, but it's obviously a bad solution for the waste of CPU effort and losing half the colour depth.
Yeah, Chrome has a weird bug that way. The easiest fix is to set your background color to black behind the window; there is a whole thread on this on the firebreath-dev group.
EDIT: bug might actually not be the right term, on reflection; it has an interesting implementation that way =]
Related
I've followed the answer in this post Cesium label blurred but have had no luck.
I've made sure that viewer.scene.fxaa = false and nothing seems to change. Please see my screenshot attached.
Does anyone have a fix for this?
Thanks so much!
Be wary of hard-coding something like viewer.resolutionScale = 2. There's a baked-in assumption on this line of code that the user probably has a high-DPI screen, and their browser is scaling up the webpage accordingly. Running this line of code on a system that is already using a 1:1 pixel ratio may cause it to render twice as wide and twice as tall as what the device can actually display.
Here's an alternate suggestion:
viewer.resolutionScale = window.devicePixelRatio
It's not perfect, but better than a hard-coded 2. It will attempt to get the Cesium viewer to exactly match the device's native pixels, which may not be the same size as "CSS pixels", particularly on high-DPI screens.
A value of "1" here (the default) means that Cesium's viewer canvas pixels are the same size as the webpage's idea of CSS pixels, which may be larger and chunkier than the screen's own native pixels. Higher numbers act as a multiplier on the WebGL canvas resolution, taking more graphics memory and performance. You may find that the machine you're testing this on already has a window.devicePixelRatio of 1.5 or 2.0, so the line above may not act any differently from a hard-coded 2 on your particular machine. But checking the local devicePixelRatio is better than making assumptions.
This can be fixed by adding:
viewer.resolutionScale = 2
May impact performance, but it seems fine so far.
So I am making this horizontal scroll site which has a ton of images. I planned on using svgs for the entire site, but with only 20-30 svg images of medium to high complexity used in the page, and chrome already seems to be showing som jank and high paint times for scroll (and firefox is even worse, though safari seems to do a lot better).
Scroll timeline
View the site (scroll works on mac only, windows users can use arrow keys)
My question is, if I were to use pngs instead of svgs, would it reduce the paint times and hence the jank? Why is the browser struggling with only around 20 odd svg images?
As was my doubt, the problem turned out to be something completely different. Browsers are more than capable of handling multiple vector images. But what they aren't good at (and understandably so) is at redrawing those images very often.
Problem
My long horizontal scroll site was quite wide (30,000px). I had a background-color property applied to one of lower z-index'ed div's to represent the sky throughout the scroll site. I didn't want the sky to stretch the entire 30,000px since it essentially didn't change much, and hence gave it viewport width and height, with:
position:fixed;
Not a very smart move. Turns out that this property was causing my document layer to be repainted on every frame. Initially I though it was normal for browsers to do so on scroll, since Robby Leonardi's site, which I used as reference also repainted every frame.
Solution
Thanks to this article by one of the chrome dev tools developers, I set aside conventional wisdom, and make the sky layer
position:absolute;
and stretched it the entire site width, and boom! The paint rectangles were gone. And the scroll performance was smoother than butter.
Other solutions I tried
Hiding elements not near the viewport to make painting lighter, as suggested by #philipp, but didn't yeild any appreciable difference. Also, it felt super-hacky, and it wasn't targeting the root cause of the problem.
I tried modularizing my site into scenes and using translateZ(0) hack on each scene so that only the smaller scenes get repainted instead of the document. This actually helped quite a bit, and scroll was decent. Then,
I gave all the svg images their own layer by using translateZ(0). I started getting FPS of around 60 now, but again, this wasn't the right way of doing things.
I once had a similar thing. The SVG was 10 or more times as wide as the one shown above, it contained ~20k elements and was about 3MB in size. The only Thing what brought back performance (since it was a jump and run game) was an algorithm which was able to find all elements whose bounding box overlapped the viewport. With this I could use display: none; to hide everything what is invisible.
That reduced the amout of visible elements to ~150 per frame and the game ran again fluently.
I used a balanced binary tree (avl tree) and a one dimensional range query, since the height of the viewport was always the same as the image.
Good luck!
[EDIT]
Forgot to leave something like an anwer. From my Experience are large/huge SVG Graphics a bottleneck in rendering, especially if there is a lot of scripting happening. If you do not need any Interactivity with the elements from the Graphic, so nothing than a large Background Image, I would recommend to use a Tile map, based on PNG images, that is the standard way in Jump'n'Run games with huges »worlds«, so you can gain perfomance in two Points:
Rendering is faster,
You can »lazy ajax load« tiles, depending on visibility, to prevent users to download the »whole world« at startup.
Additinally you could use something like PIXI.js to render with WebGL, what will push the performance drastically and with it comes support for Tilemaps and Spritesheets.
If you insist on the advantages of Vector Grafics (Scaling, Interactivity) than you need to find a way to hide as much elements as possible to keep the frame rate high.
Ok I am developing a game using Libgdx and everything was fine until I noticed that when my character moves, its texture becomes slightly blurred at the edges, as if it is blending in with the background in the android version. There seems to be a slight graininess to the image as well which becomes more noticeable when it moves. I THINK these problems might be related to texture filtering, but wanted to come on and ask here to see if anyone had experienced this before. Any insight appreciated.
EDIT: Here is an the image, you can see it's quite grainy on the whole. When it moves the graininess seems move, it is hard to describe, but it looks as if the pixels on the eater are moving relative to each other slightly.
The way I draw it is pretty straight forward the following is called in my render method:
idleTexture = new Texture(Gdx.files.internal("images/GreenGuy.png"));
spriteBatch.draw(idleTexture, x, y*ppuY,width*ppuX,height*ppuY);
All other work I look at does what I am doing, but I am not totally happy with the results. I have tried changing between linear and nearest filtering but this did not change anything. I have also tried just using a smaller image instead of shrinking a large one, but I still get the same problem of the pixels not remaining relatively static while the character is moving.
i ran across something i have never seen before. the page has a top div and a footer div. both with an image as background. mirrored the image as well via photoshop.
now the weird thing is, it shows a different color. see http://www.hp-consultants.nl
when i tilt my screen towards me the colors become the same. even in photoshop i notice the difference. does anyone know what is wrong?
ive tried using regular CSS colors instead of a background image, to no effect. even the same image shows a difference
thanks!
There's nothing wrong with your page. Using Photohop's colour picker confirms that the colours are both indeed exactly the same.
The effect probably happens because you're sitting in front of a TFT monitor, whose display is sensitive to the angle you look at it from.
Some useful background information:
LCD Test: Viewing angle
Wikipedia on TFT LCDs:
TN displays suffer from limited viewing angles, especially in the vertical direction. Colors will shift when viewed off-perpendicular. In the vertical direction, colors will shift so much that they will invert past a certain angle.
The colours are exactly the same a quick check with any image editor will tell you that. TFT Monitors can do strange things to colours depending on the viewing angle.
Also our eyes and brains are really not as good at determining colour as we think. Have you ever seen this optical illusion.
The Squares Labeled A & B are the same colour
may be is the orientation of the led, that brights differently. have you tried to get the browser windows to the bottom of the screen so you see the header where the footer is.
Try this:
open 2 browser instances
resize the window of each to view only the header or the footer (one for each)
place the footer window at the top and the header window at the top
switch window places
in my case I see the bottom one always more clear.
Hope this helps you
I was wondering if anyone has done any tests with background images. We normally create a background that repeats at least in one direction (x or y or both).
Example
Let's say we have a gradient background that repeats in X direction. Gradient height is 400px. We have several possibilities. We can create as small image as possible (1 pixel width and 400 pixels high) or we can create a larger image with 400 pixels height.
Observation
Since gradient is 400 pixels high we probably won't choose GIF format, because it can only store 256 adaptive colours. Maybe that's enaough if our gradient is subtle, since it doesn't have that many, but otherwise we'll probably rather store image as a 24-bit PNG image to preserve complete gradient detail.
Dilemma
Should we create an image of 1×400 px size that will be repeated n times horizontally or should we create an image of 100×400 px size to speed up rendering in the browser and have a larger image file size.
So. Image size vs. rendering speed? Which one wins? Anyone cares to test this? With regards to browser rendering speed and possible small image redraw flickering...
The rendering speed is the bottleneck here, since bigger tiles can be put into the browser's cache.
I've actually tried this for the major browsers, and at least some of them rendered noticeably slow on very small tiles.
So if increasing the bitmap size does not result in ridiculously big file sizes, I would definately go with that. Test it yourself and see. (Remember to include IE6, as still many people are stuck with it).
You might be able to strike a good balance between bitmap size and file size, but in general I'd try 50x400, 100x400, 200x400 and even 400x400 pixels.
I found out that there may be a huge difference in the rendering performance of the browser, if you have a background-image with width of 1px and repeating it. It's better to have a background-image with slightly larger dimensions. So a image with a width of 100px performs much better in the browser. This especially comes into play when you use a repeated background-image in a draggable layer on your website. The drag-performance is pretty bad with an often-repeated background-image.
I'd like to point out that for the cost of sending down an extra few rows (1-2 only example here) .8k - 1.6kb (if you can get away with 8-bit) more like 2.4kb - 4.0kb for 24bit
2 pixel columns more means the required iterations required to blit the background in is cut down to 1/3 for up to 1.6kb (8-bit) or 4kb (24bit)
even 1 extra column halves the blitting required down to half the element width.
If the background's done in less than a second for a 56.6k modem I reckon it's lean enough.
If small dimensions of an image have a negative impact on rendering, I'm sure any decent browser would blit the image internally a few times before tiling.
That said, I tend not to use 1 pixel image dimensions, so I can see the image clearly without resizing it. PNG compression is good enough to handle this at very little cost to file size, in most situations.
I'd put money on the bottleneck being the image download rather than the rendering engine doing the tiling, so go for the 1 pixel wide option.
Also the 24-bit PNG is redundant since you're still only getting 8 bits per channel (red, green and blue).
I generally prefer to go in between, 1pixel wide will probably make your gradient seem a bit unclear but you can do something like 5pixel width which gives enough room to the gradient to maintain consistency and clarity across the page.. but I would suggest you can add more patterns and images to a single image and then use background positioning(css sprites) to position them because download a single image of say 50kb would take less time comapared to 5 40kb images since the browser makes fewer requests to the server...
I have not benchmarked this but I'd bet that on most modern computers the rendering won't be an issue whereas you always want to save on on the image download time. I often go for the 1px type of graphics.