5 ms·

I know Javascript/HTML/CSS makes it very easy to develop something, however it is really sad to see people are struggling to get 60fps to show 20 boxes with ima

• scott_karana 11y ago
  I'm with you. This is a regression. A unified-ish platform might be a benefit to their developers, but this has also been a net loss for Netflix's end-users. :/
  • deleted 11y ago
    [deleted]
  • andrepd 11y ago
    Absolutely. It strikes me as odd that these days it is not only acceptable, but encouraged as a virtue, for developers to focus on making their own jobs easier as opposed to delivering a good (fast and efficient, among other things) product.
    • zevyoura 11y ago
      Usually making a developer's job easier entails making them more productive, which means fewer bugs and more features. Those things also correlate with a good product just as much or more than performance in most cases.
• hayksaakian 11y ago
  the biggest trade off is maintainability Are you getting code which any john developer can pick up and develop on, or is it something which requires knowing a special purpose programming language and corresponding frameworks? From my point of view, I want to see a big company build a Canvas or WebGL UI that goes to thousands of people. We can speculate, but someone actually trying what you mention is the only way to find out if it works in the industry.
  • kibibu 11y ago
    I'm curious how one would handle accessibility with a WebGL UI. Is generating a parallel vanilla-HTML version the only option? I suppose you could progressively enhance your HTML version to override certain DOM elements with WebGL UI, but I have no idea how modern screenreaders would handle it.
  • sosborn 11y ago
    Here is one example: http://engineering.flipboard.com/2015/02/mobile-web/ http://engineering.flipboard.com/2015/02/mobile-web/
    • nacs 11y ago
      And an example of doing it wrong: http://famous.org/ http://famous.org/
      • cpeterso 11y ago
        Wrong how?
• guiomie 11y ago
  Woudlnt there be a way to use a game engine to parse HTML+CSS and gain those performance improvements?
  • wmf 11y ago
    In general, probably not. Any optimization the game engine uses could also be used by browser engines (they already use DirectX/OpenGL, for example). CSS is just plain complex.
  • jeremiep 11y ago
    Game engines don't even go nearly that high-level. I see GUIs implemented in C++ more often than in scripting languages, and when they go that route its usually LUA without any declarative markup whatsoever. Everything is a tradeoff, if you want the ease of HTML+CSS then be prepared to pay the performance hit, and if you want lighting fast GUIs, be prepared to pay the productivity hit.
    • BuckRogers 11y ago
      What about those of us who prefer to stick with tried and true text, like HackerNews? Fairly simple and effective. No need for a GUI when you can just have a line of text convey the idea much faster.
    • MichaelGG 11y ago
      What's so complicated with the Netflix UI? I've been using the web for quite a while but I'm hard pressed to find any benefit, as a user, in the new Netflix UI. It's not like the old one rocked. But come on, it's a few cover images and text.
  • Timmons 11y ago
    Weirdly, UI interfaces are also a problem in the game world. Where we want to have a designer or artist design and implement something in a game in a fast way we often resort to using Scaleform[1]. It is flash based tool for games, within the industry it is notorious for how slow and inefficient it is. A simple UI element can often be more costly than a major in-game 3D object. We are willing to pay this extra cost for these elements because they are often required to be quickly put together and then iterated on over a long period of time in a very dynamic and changing system. Some elements may be moved from Scaleform into a more native implementation but for the most part it is left to be slowly parsed and inefficiently rendered. Basically, where we need fast changing interfaces that arent necessarily implemented by high skill programmers then we are going to take a performance hit to get the same level of visuals we could get if we had the time and manpower to approach it better. [1]http://gameware.autodesk.com/scaleform http://gameware.autodesk.com/scaleform
• comex 11y ago
  These days, more like millions of (textured) polygons :)
  • jeremiep 11y ago
    Depends of your platform, shader complexity, the number of GPU context switches and the number of sync points. Mobile devices for example still have a hard time going over the quarter-million mark and thats assuming the GPU is near 100% usage, which in reality is probably closer to 60%.
• jeremiep 11y ago
  Game engines and browsers have radically different architectures and performance/productivity requirements. Computing polygons is basically applying one function to an array of values and is delegated to the GPU, so its no wonder they easily reach 60 FPS with hundred of thousands of polygons per frame. A better comparison would be against the performance of game logic, which in a game engine can easily become the bottleneck from all the conditionals, random memory accesses and sequential dependencies. And even there they don't sit on nearly as many layers of abstractions as a web page does. This comes at the cost of productivity; building a web site is a few orders of magnitude more productive than using the latest game engines. Of course, sitting on the DOM and its many quirks as well as its reflow/redraw cycles can make it harder to reach 60FPS in the browser. But at least you're saving yourself from a world of low-level pain.
  • andrepd 11y ago
    So essentially you are sacrificing your end result for an easier time for yourself, the developer.
    • jeremiep 11y ago
      You're sacrificing performance, not the end result. However, a lot of the performance tricks do carry over (such as object pooling for example.) But for 99% of the web this doesn't matter at all. I'll take declarative over imperative any day if it means I can spend the saved time polishing the product instead of debugging or optimizing. You have no idea the amount of debugging and optimizing which goes into developing a video game. Having worked on both I can say time spent debugging/optimizing is at least an order of magnitude more than for web applications. Its much worse when you're using an in-house engine as well.
    • deleted 11y ago
      [deleted]
    • egeozcan 11y ago
      You are sacrificing your end result every time you don't spend a lifetime designing a custom processor for your application with an instruction set specific to your use case and instead have an easier time living like a normal human being.
• thejosh 11y ago
  Sure, if you're on "powerful" hardware, if you're talking about FPS in current games, current consoles don't really go past 30 for most games.
  • yoklov 11y ago
    This is largely a tradeoff between framerate and visual effects. Current generation consoles can make 60fps, but not with the level of visual effects that are expected from them. Whether or not this tradeoff is worthwhile is at least partially personal opinion (my opinion on the subject is... mixed, although I think the option should be available both ways). Either way, it is undeniably harder to sell new consoles, or games for those consoles, when screenshots of them looks the same as it did in the previous generation, even if those screenshots were taken at 60fps.
• kozukumi 11y ago
  In all honesty this is what Java was designed to tackle.
• h1fra 11y ago
  Ironically, some game devellopers are using webkit on top of their game to do the UI. Like simcity (https://news.ycombinator.com/item?id=5359143 https://news.ycombinator.com/item?id=5359143)