We developed a complex reporting application using flot however something that I did not foresee is that we were going to have an issue with the output, although everything looks and works cool the Business users cannot copy the chart in their presentations because the output is a canvas element.
I've looked for several approaches I even found a way to convert the canvas to an image but this only works on HTML5 supported browsers, unfortunately our users use IE7 I know this is very old but there is nothing I can do (trust me we tried) so I have to come up with a solution to export the graph to an image format.
My last attempt was using fxcanvas and flashcanvas to emulate the toDataURL method but turns out there is a 32kb buffer where my images are at least 300kb.
Business users (upper management) is pushing for a solution and they clearly don't understand there are technical boundaries here, I'm open to any solution that does not involve the following:
Upgrade / change browse
Install plugins like chrome tab or so.
Install cab files on the server or users machine
However I'm open to any Active X solution or any export option that does not require installing 3rd party programs (except for MS libraries where they dont' have to perform any addiontal step like registering libraries).
The basic way to do it is using canvas.toDataURL("image/png"); but I also found this link for you
http://nihilogic.dk/labs/canvas2image/
I've not tested it.
If you want the users to get the same result (or at least as close as possible), why not try relying a bit on the backend?(assuming there is one) Just generate the image on the backend and output a standard jpg or png.
I can't really think of another solution, even the SVG is compatible only on IE7+, the closest solution without using backend would be using flash, as it's a third party but it's pretty known and it's built-in on the modern browsers.
Relying on the client side always involve: Asking them to upgrade the browser/ Using a third party plugin, so keep an eye on that in the future projects planning, the compatibility issues are one of the most annoying in my opinion in web development
Related
I tried to take a screenshot of a movie on the Disney+ web app when I realised that the video turns black as soon as I try to take a new screenshot with Snipping Tool. When I tried to do the same thing with OBS and Discord streams, I saw the same effect.
Interestingly, this only works for Chrome on my machine (I also tried Firefox and Edge and they just let me record my screen).
When I saw this, I became really curious on how they achieved this.
Does anyone have any idea how I can recreate this for my own web projects?
I became really curious on how they achieved this.
They use Widevine.
Widevine homepage.
https://ottverse.com/widevine-drm-how-does-it-work/
https://en.wikipedia.org/wiki/Widevine
News reports:
https://www.cordcuttersnews.com/sadly-disney-wont-work-on-chromebooks-linux-some-android-devices-because-of-drm/
https://www.tomsguide.com/news/disney-plus-will-work-on-chromebooks
https://www.androidpolice.com/2019/10/22/disney-will-only-work-on-devices-that-support-the-strictest-widevine-l3-drm/
It's also used by Netflix, Hulu and others.
Widevine is Google's DRM system that's baked-in to Chrome.
All other major browsers have adopted it as well, because no-one will use a browser that can't access Netflix.
Mozilla's and Microsoft's support is less user-hostile and as you noticed.
It's just a standard HTML5 <video> element - when the browser downloads the video stream it will see that it's encrypted with Widevine and that engages the Widevine client-side code which does all the DRM biz.
Though there are HTML and DOM features that facilitate DRM, I'm unsure of the extent that any JavaScript is required to use it - as theoretically everything the browser needs to know to load the DRM system should be embedded in the raw media stream.
On Windows, I understand (though unconfirmed) that Widevine makes use of SetWindowDisplayAffinity to block screenshots.
Nothing stops you from doing this in your own native code (e.g. if you had an Electron fork), but please don't because it's a real dick-move to your users, in addition to not working at all if the user has the DWM disabled (e.g. they're running Windows 7 with Aero disabled).
Has anyone any idea how I can recreate this for my own web projects?
You'll need to license Widevine yourself. This is a complicated process intended only for large media production companies and content rightsholders, not individuals or small businesses.
Anyway, even if you could, please don't. Why would you want to make to harder for users to share and appreciate your media? Just stick it up on YouTube instead.
I'm making a game with HTML/CSS/Javascript because it's the code I'm most comfortable with at the moment. I'm only really doing this as an exercise in game development and plan to learn C# later. But for now that's what I'm using, and I have a question about it.
Obviously when making a website, you want your website to be compatible with all web browsers equally. Right now, I'm using Chrome to test/debug my game, and I've decided to develop this game with Chrome in mind. But not everybody has Chrome, and not everyone would want to download it in order to play my game.
Is there a way to run an HTML/CSS/Javascript file in a Google Chrome "environment" without having the actual browser installed? Just it's code engine and none of the rest of the browser.
I've been reading about their V8 Javascript engine that they use in Chrome, and am wondering if that is part of the answer I'm looking for. What I'd like to do is include this "engine" in an installer with my game files and have it install like any other game.
Hopefully this makes sense. This may not be possible/exist, but if someone knows something I don't or an point me in the right direction, that'd be amazing. Thanks!
You could look into Node-webkit which essentially allows you to write desktop applications in html/css/js. When you distribute your game along with your node webkit executable, it is always run in the same environment. You can see some cool examples on their demos and examples page.
Usually a common path to convert web application to native desktop applications is to use a "thin" browser as app container and ship it.
A lot of current applications out there are using this trick (Spotify, Slack, etc...) and it works pretty well.
I've read of some people using the CocoonJS game engine framework and successfully ship it with this techniques.
To most famous wrappers, that I know are node-webkit or electron (AKA atom-shell).
Once you include your game in either one of those you can just "compile" it (it is not a real compile, but just to give you an idea) and ship it: with some tricks it is also possible to publish it in the Mac/Win app stores.
In case you want to focus on mobile instead, there are similar frameworks but I don't really know which are the most common.
Note: if you're using fancy WebGL or very advanced stuff these tools may have some issues sometimes.
So essentially you want to install the JS engine to use it with any browser? In this case, the answer is: nope. Browsers act different, they don't have a standard interface, nor have this "swapping" capability in mind.
In case you'd be asking for an embedded browser inside an app... well, isn't that worse than installing Chrome? You may embed webkit/V8, but it's a hard way and you'd know programming.
So simple answer is: you'd make it compatible for at least the evergreen browsers (Chrome / Firefox mainly). Or reduce your target to webkit based only browsers (or in your case V8, i.e. Chrome, Chromium and the forks).
If you want that your game is only for chrome, because you read V8 documentation, you can create it as an extension. There'sn't other way to install your JS, because browser interpret javascript, not compile it. And the docs you need is found at: https://developer.chrome.com/extensions/getstarted
The Problem
I'm working on a web application where users can sequence audio samples and optionally apply effects to the musical patterns they create using the Web Audio API. The patterns are stored as JSON data, and I'd like to do some analysis of the rendered audio of each pattern server-side. This leaves me with two options, as far as I can see:
Run my own rendering code server-side, trying to make it as faithful as possible to the in-browser rendering. Maybe I could even pull out the Web Audio code from the Chromium project and modify that, but this seems like potentially a lot of work.
Do the rendering client-side, hopefully faster-than-realtime, and then send the rendered audio to the server. This is ideal (and DRY), because there's only one engine being used for pattern rendering.
The Possible Solution
This question lead me to this code sample in the Chromium repository, which seems to indicate that offline processing is a possibility. The trick seems to be constructing a webkitAudioContext with some arguments (usually, a zero-argument constructor is used). The following are my guesses at what the parameters mean:
new webkitAudioContext(2, // channels
10 * 44100, // length in samples
44100); // sample rate
I adapted the sample slightly, and tested it in Chrome 23.0.1271.91 on Windows, Mac, and Linux. Here's the live example, and the results (open up the Dev Tools Javascript Console to see what's happening):
Mac - It Works!!
Windows - FAIL - SYNTAX_ERR: DOM Exception 12
Linux - FAIL - SYNTAX_ERR: DOM Exception 12
The webkitAudioContext constructor I described above causes the exception on Windows and Linux.
My Question
Offline rendering would be perfect for what I'm trying to do, but I can't find documentation anywhere, and support is less-than-ideal. Does anyone have more information about this? Should I be expecting support for this in Windows and/or Linux soon, or should I be expecting support to disappear soon on Mac?
I did some research on this a few months back, and there is a startRendering function on the audioContext, but I was told by Google people that the implementation was, at that time, due to change. I don't think this has happened yet, and it's still not a part of the official documentation, so I'd be careful building an app that depends on it.
The current implementation doesn't render any faster than realtime either (maybe slightly in very light applications), and sometimes even slower than realtime.
Your best bet is hitting the trenches and implement Web Audio server-side if you need non-realtime rendering. If you could live with realtime rendering there's a project at https://github.com/mattdiamond/Recorderjs which might be of interest.
Please note that I'm not a googler myself, and what I was told was not a promise in any way.
I'm creating a web-based online game and am trying to find the best fit in terms of a framework for the front end of the game. The back end of the game is currently using asp.net mvc 2. Given that I could take the controller actions and turn them into WCF service actions the choice in the back end should not affect my options of a front end.
One thing that is certain, it does need to play in a browser. I have done some research on an HTML 5-only front end as part of this process and am probably leaning in this direction but I have a few concerns:
Assuming this game is completed this time next year, what kinds of difficulties will I have with current HTML 5 adoption levels? Specifically I'm worried about Firefox 3.6 and IE 7/8 still having a large install base. I have looked at Chrome Frame to solve the IE problem but am not sure if there are drawbacks to that I am unaware of either (other than the installation requirement).
I'm used to doing C# with a nice IDE complete with realtime information about whether the code compiles and intellisense reminding me of symbol names. Am I going to run into a problem with Javascript where my code becomes big and difficult to manage? The accessibility problem that a Javascript only engine solves for my users is more important than convenience for me but it of course can't be unmanageable either.
Are the HTML 5 engines on the market right now mature enough to trust with my time investment? Am I at high risk of adopting a framework that will fall into disrepair in a year from now? Of the engines I have looked at, none seem to have really great community support, am I wrong? Are there others out there that do?
here are those I have found thus far:
CraftyJS (http://craftyjs.com/api/Sprite.html)
ImpactJS (http://impactjs.com/)
PropulsionJS (http://www.propulsionjs.com/)
The Render Engine (http://www.renderengine.com/demos.php)
RPG JS (http://rpgjs.com/)
EaselJS (http://easeljs.com/)
Does anyone know anything of the community with these or have any reason to trust that any of these will be well maintained or available for at least the next several years? Does anyone know of another framework that's out there? ImpatJS has the most impressive demo of them all and it's also the only one that isn't free.
Thanks for any help / advice. I'm just worried I'll choose a front-end that I regret and I don't want to have to start from scratch 4 or 5 months down the road.
This is a 2D browser-game. It's not targeting mobile now, but it will be moving to mobile immediately after first launch. One hope is that it will work on mobile fine if I do HTML 5. I may have to tweak it for display size but if I don't have to port it to mobile that would be a definite plus.
This is my two cents having just been through the same decision making process for my company.
Our goal was to create as broad a game as possible that means it needs to run on as many browsers as possible. I ruled out html5 right away because the adoption is not there and seems to be at least a couple years until it reaches more than 60% penetration.
This left me with Flash vs. Silverlight. Flash's installed base is huge and there are many game engines available for it. Flash is a safe bet unless you have specific requirements for video or 3d.
I choose Silverlight because I wanted a good installed base (60%) and I wanted to leverage my companies’ in-house .Net expertise. I also wanted to use WCF for the backend and did not want to mix environments.
Keep in mind that SL5 is going to support most of XNA which is a big deal. There are a ton of XNA engines and source code that you can use to start with.
Here's a great site for looking at html5 browser support:
http://caniuse.com/
I can't speak with expertise on the particulars of HTML5 and Canvas, but...
As far as support goes, you'll still have probably a large bunch of IE7-8 users. IE is a little different than other browsers because you have to DO something to install updates. (i.e, go to the Install Updates in Control Panel or visit ie.microsoft.com). Other browsers (like firefox) just tell you and make the update easy. So your FF 3.6 users should be gone, but IE will still probably be a problem. Keep in mind, though, that much of the old IE browser share is due to IT depts. keeping their users on older versions - something you won't need to worry about.
This could be a problem. However, developing JS in Visual Studio or a similar IDE isn't so bad - there's still IntelliSense and other helpful things, as well as realtime debugging. It's definitely going to be a bit more difficult than C#, especially as many of the new JS api's haven't been implemented into the Autocomplete's of many IDE's.
I don't think you need be afraid of this. At this point, HTML5 and Canvas have gotten far enough that they won't be revoked, only improved. There may be a few modifications of the APIS and such, but not enough to keep you from using it.
Is HTML5 going to replace Flash? No, because games and RIA that require more out of javascript cannot be done until enough of the world is using IE 15 (which is about 5 10 years). Safari, Chrome, FF (maybe), will be up to par here soon but their js engines are going to require good hardware and that's not always going to be there.
Silverlight is a good option but it's not as well supported as Flash. This is why flash will still be around. The next version will support video controllers. It' called Project Mole hill and you can check out my SO question here.
If you want to make super simple games without good graphics try out one of those services you suggested. impact.js is $100, the others look free. In the future we will be able to use node.js to handle request with servers, but in the meantime Flash is certaily the way to go!.
I would much much much rather use javascript but after you start coding and realize the limitations compared flash will make your application standout.
Then for mobile devise, iPad, iPhone, Android, etc.. If you really think your audience is there build the game in the their language. It's more epensive and and harder, but Objective C, Java, they are much faster than HTML, JS, CSS etc...
I did some trial runs with YUI3, Burst engine & Raphael for SVG animation - everything seemed to run well; YUI's dragdrop module even detects the same drag operations on Mobile without adding a single line of code.
I can only imagine that if I had the time, a YUI3 instance available on a Node.js server with Raphael SVG animation would be my choice. You could drop the SVG aspect and use more standard graphic techniques, or perhaps serve up alternate quality graphics for those User Agents with fewer testes. Maybe it could be that your alternate quality version is just another implementation of your game engine - and you might choose to develop games using non-SVG anyway.
Just thoughts mostly, that doesn't help with your real-time IDE debugging...
impact.js has a great community and documentation. It is well worth checking out. I believe iosimpact.js is part of the package (although beta???) allowing for the development of native games for the iphone/ipad.
Yes, indeed you will lose a large user base. But how relevant that user base will be to you will depend on what your target is. Every-day-RPG players are much more likely to have the latest browser than Sunday-Morning-Sudoku users.
Give Eclipse + Web Tools + Aptana a try. It worked really nice for me.
No experience there.
There are certainly people out there who think that HTML5 is going to replace flash in online games. Here is an HTML/Javascript based engine that I heard about few days ago
http://www.youtube.com/watch?v=_RRnyChxijA
I haven't actually used it but it looks really promising and It's designed for similar set of requirements that you've put. It lets you design 2D / 2.5D ( isometric projections ) games. And it does look promising.
Given the iPhone's 25k limit for caching of files, I'm wondering if there's interest in an iPhone optimized javascript library that makes caching a top level goal. Since it'd be iPhone only it could get rid of most cross-browser cruft and rely on safari specific capabilities, hopefully cutting down some of the girth and staying with 25k.
John Resig discusses this briefly, although mostly to dismiss it, it seems. He does mention:
if you're particularly excited about
breaking jQuery down into little
chunks you can grab the individual
pieces from SVN and build a custom
copy.
Anyone tried that?
Dojo implements a 6k version that seems to rely on deferred loading. I'm mostly a jQuery user so I haven't given it a try, but it looks interesting.
Overall: what do you think about a safari/iphone specific javascript library that implements, say, the top 90% most used APIs in jQuery (or your other favorite library)?
Newer update: looks like Zepto is the way to go these days.
Found XUI, looks like what I was looking for, although I haven't given it a try yet.
You should check out QuickConnectiPhone. It may do what you want. It can be found at https://sourceforge.net/projects/quickconnect/. It also lets you write your app in JavaScript, CSS, and HTML and yet install it on a device.
There is an API that will allow you to make calls down to the Objective-C layer as well for phone vibration, GPS locations, accelerometer information, and some more. You can even extend this to other native phone behaviors as well.
The development blog for the framework is found at http://tetontech.wordpress.com
I'm experimenting with XUI as well, looks promising, seems to follow JQuery-way of doing things.
The same people also created 'lawnchair' for persistant storage of data in json format, XUI+lawnchair looks like a great combination for cross-platform (as in at least iphone+android, maybe webos, symbian, blackberry and ms as well) mobile development.
I think it would be fantastic, but it would be hard to match the testing and reliability of jquery unless someone really picks it up and runs with it. If there was a lightweight, safari only version of jquery that was completely compatible with the plugins and documented methods, it would be a godsend.
Given the increasing popularity of the iphone, I think it would be a really useful thing, it might be possible to remove the cross browser stuff and get it down to size.... however, it would be even more useful if the iphone had a more realistic cache limit.
It does make me wonder if the cache limit in the iphone was determined by the capacity of the hardware or the business needs of the carriers. A 50K cache limit would reduce a lot more carrier usage...