I have a custom receiver and using it to cast an HTML dashboard. Everything works great except for the resolution. It looks like the chrome browser (on the chromecast) is displaying at a very low resolution.
It looks like the TV is still getting the feed at 1080p but the browser is zooming in or something like that.
If I just draw a box 1900px wide on the screen about half of it is chopped off. Is there anyway to control the display height/width of the chrome browser running on the chrome cast?
It is 1280x720 but it is best to query for the window size within your JavaScript so if in future things change, your code is still accommodating for that. You also might want to take into account the possibility of overscan on TVs.
Related
I'm developing a React project in Windows 10 and the issue I've come across is that my website design looks too big(when on 100% resolution of Chrome) on my laptop screen and works fine on 75%, I guess it's rendering the design of large screens on my laptop. Please guide me how to get rid of this problem and view the website in normal mode.
I've set my Window's Scale and Layout as 150%(Recommended), and Resolution of 1920 * 1800(Recommended), but when I view my website in the Chrome inspect tool at the dimension of 1920, it seems fine but when I view it in normal mode, then it content becomes so bigger.
Note: You might say that it's due to 150% but I've also checked by decreasing this, it decreases all the other content on screen but website looks same.
Please note that Chrome's resolution and Window's layout are two different things mentioned above,
first one is set to 100% and the second is 150%.
This is really weird behavior. Having difficulty even quantifying. Have had to revise a few times.
Best I can do is the following:
The tech stack for my app is Backbone Marionette, handlebars.js, require.js.
The app contains images mostly of icon size - say 32x32 and under. Some jpg, some png, some svg.
Some of the images, the same ones each time, don't display. That's a common issue on which many have posted. No big news there.
But if I hit the sleep button, leave the iPad sit for a minute or two until the unit really goes into hibernate mode, and then revive it, the images slowly and magically fade in. They don't abruptly display when the screen lights. They fade in afterward.
Doesn't work to just hit the sleep button and instantly revive. Have to wait a minute until it truly hibernates.
After true hibernation, no matter how many times I refresh the page, the images are there. But, if I go and clear the cache on Safari and load the page, the images are not there again - until I do that hibernate thing.
All of these images do display without fail in a browser on a PC (all flavors). It's just on the iPad that they don't.
I thought, at first, it was just images I was loading in collection views. It is not. I have a third party HTML5 video player in the app. It has a play button and other controls in svg format. This also exhibits the behavior above.
Once the iPad has hibernated and been revived, the images fade in. Only clearing cache makes them disappear again.
There are no 404 errors when the images don't display (checked in dev console on a MAC). In fact, if I just tap the screen where the video play button is supposed to display, the player begins. So the button seems to actually be there, just not painted on the screen - until you do that hibernate thing.
Some images in the app always load no matter what. I'm looking at those images to see if I can note anything special about them or the code which renders them.
I tend to think it's not the images themselves because the very same images in a plain web page always display on the iPad. Also, that third party video player in a plain web page displays the svg play button and controls without fail on the iPad.
It's just in my app that the behavior occurs. So it's logical to think my app is where the problem lies. I just can't seem to find a common thread for the images that always work vs ones that don't.
Not sure what code I can even post here. I'll look and see what might make sense to post.
Definitely a problem loading images dynamically via the framework. They are there but do not paint. No idea what the problem actually is. Literally only happens on Safari mobile browser. Can't make it happen anywhere else, even old IE. Know one solution that definitely works though. Preload all the images by explicitly including them in a div in your markup. When you load your marionette app, remove the div - $("#preload-images").remove(). Thereafter the images never fail to paint when added dynamically via marionette.
I would like to make screenshots of the receiver application running of the Chromecast device.
I need to have it running on the device to show the video and the application together.
Is there a way to do this ?
Ali Naddaf's answer is technically true, however with a little work I was able to make a faithful reconstruction of the screen, to the point that it is indistinguishable from an actual screenshot.
We will use code from the html2canvas project, see http://html2canvas.hertzen.com/documentation.html . It will render our screen to a canvas. In particular, copy&paste the compiled code from http://html2canvas.hertzen.com/build/html2canvas.js to the Chromecast console. (adding a tag to dom seems not to work) You can access the Chromecast console & developer tools by accessing the ip.ad.dr.ss:9222 port via Chrome.
Issue the following command:
html2canvas(document.body, {onrendered: function(canvas){document.write('');}});
This will destructively replace the screen with the screenshot (I find this convenient but you can easily think of a more polite way if you wish)
In the elements browser, you will have an img, with a base64 url specified as a src. Click on the url, chrome will open the image in a new tab. Hopefully it's the screenshot that you wanted.
You might find that some pictures are missing because of e.g. same origin policy. The javascript have other privileges than accessing images from html. If this happens, work it out somehow (use https for images for example), then goto 1.
You have your screenshot!
No, that is not possible due to many reasons such as media rights and security.
I'm extending zsolt-szatmari's answer into a copy-pastable script that you can use in the Chromecast Developer Tools console:
As he said, copy and paste http://html2canvas.hertzen.com/build/html2canvas.js code into the console
Call the html2canvas method: it will create a new canvas element into the DOM: html2canvas(document.body, { onrendered: function(canvas) { document.body.appendChild(canvas); } });.
Get a base64 string representation of the image currently displayed in the canvas: document.getElementsByTagName('canvas')[0].toDataURL('image/png');
You'll then get a very long base64 string: if you click on it, Chrome will show the image in a new tab. Please note that this image could be far from what is really shown on your Chromecast due to html2canvas limits:
The screenshot is based on the DOM and as such may not be 100%
accurate to the real representation as it does not make an actual
screenshot, but builds the screenshot based on the information
available on the page.
(source)
I was thinking that you could maybe use this to capture the canvas to an image file, which normally works in javascript with canvas:
var canvas = document.getElementById("mycanvas");
var img = canvas.toDataURL("image/png");
Of course then you would need to transfer this image file to somewhere - not exactly sure how to the last bit from the chromecast. Maybe that is not possible.
As a chromecast developer myself I needed screenshots of the app running to show customers. I ended up doing a kind of "simulation" of the chromecast - calling some mockup methods in javascript to display the data and then accessing my receiver app via the cast url on my desktop in the browser. Then I used a screen capture program to capture the browser output. This gave me the same screenshot as from running the receiver app on chromecast on TV, which is essentially just a browser showing your html+css+javascript receiver.
When i try to load a website it shows like this on my desktop:
http://img846.imageshack.us/img846/9646/1354627721863.jpg
Now normally it should flow well like it shows on my laptop:
http://unforgivenwow.com/theknight/unforgivenwow/
anybody a clue?
Nvm, got it fixed. Appearantly windows used my monitor his colors so i changed those to rgba.
Different monitors display images differently. If it's just a matter of the image color quality, your monitor might not be able to handle all of the colors. If it's a matter of speed, then it's probably an issue with your computer or internet connection.
We have a website that currently serves drawings to users via the SVG Viewer plugin. We have one client that sees it through IE8. With IE8, when they do a Change Zoom Level on the browser to anything other then 100%, the viewer tries to occupy the new space and zooms correctly. However, when the user tries to manipulate the frames inside that bound the viewer (it's a frameset website with the viewer being in the center) the entire site hangs. IE8 also shows that it takes up CPU cycles on the client computer, so it's trying to do something but hitting a loop.
I don't think this is actually our code and might just be something with SVG and how IE8 handles plugins and it's zoom. Does anyone know if this is a real problem and if there's a good solution?
If you are referring to the Adobe SVG Viewer plug-in, then I recommend that you (ideally) get your clients to start using a web browser that supports SVG natively — i.e. Chrome, Safari, Firefox, Opera; even IE9 (to some extent) — or use a different shim like SVGWeb to provide SVG support for those users of older browsers who also have Flash installed.
I found out what the problem was. I thought it was the SVG viewer trying to do something with the frames, when it turned out that I was just setting the frameset's initial size to the clientHeight and clientWidth, and then subtracting something from the height. That subtraction was a toolbar based in the frameset and, when you change the zoom level in the browser, there's a lock up that can occur with you trying to pull a components size and the client's size. At least, this is what I was seeing.