Slashdot Mirror

← Back to Stories (view on slashdot.org)

Mozilla Enables WebRender By Default On Firefox Nightly

Posted by msmash on from the moving-forward dept.

RoccamOccam writes: WebRender, an experimental GPU-based renderer for web content, written in Rust, is now enabled by default for Firefox Nightly users on desktop Windows 10 with Nvidia GPUs. The announcement was made on the mailing list.

Lin Clark provides an excellent overview of WebRender and, states, "with WebRender, we want apps to run at a silky smooth 60 frames per second (FPS) or better no matter how big the display is or how much of the page is changing from frame to frame. And it works. Pages that chug along at 15 FPS in Chrome or today's Firefox run at 60 FPS with WebRender.

In describing the WebRender approach Clark, asks, "what if we removed this boundary between painting and compositing and just went back to painting every pixel on every frame? This may sound like a ridiculous idea, but it actually has some precedent. Modern day video games repaint every pixel, and they maintain 60 frames per second more reliably than browsers do. And they do it in an unexpected way instead of creating these invalidation rectangles and layers to minimize what they need to paint, they just repaint the whole screen."

101 comments

  1. but... by Anonymous Coward · · Score: 0

    ... does that mean running my browser becomes like running FPS games where they are constantly using the GPU and drawing massive power?

    1. Re:but... by darkain · · Score: 4, Informative

      Quite the opposite. If there is no invalidated states on the screen, no painting occurs. It only paints when it needs to. It actually consumes less power overall because of the amount of code that is required to handle invalidation of only parts of the screen is massively slow. This is why the browser renders so much faster. Instead of 200ms per paint of a small section of the screen, it renders the entire screen in 15ms. The rest of the time, your CPU/GPU sits idle. Also, Webrender does all rendering on the GPU instead of CPU, so it has better optimization for painting the scene (CPUs suck at this entirely)

    2. Re:but... by K.+S.+Kyosuke · · Score: 1

      No, it mostly means that drawing finishes faster and the chips go idle quicker.

      --
      Ezekiel 23:20
    3. Re:but... by Anonymous Coward · · Score: 0

      awesome, thanks.

    4. Re:but... by Anonymous Coward · · Score: 0

      15 milliseconds would be close to half the time at 60 Hz, and more than all of the time at 120 Hz. I hope this is just an example rather than a measured result, because that would be drawing massive power.

    5. Re:but... by Tough+Love · · Score: 1

      Continuously animate one single pixel on the screen and your assumptions break, the GPU will never be idle. Don't get me wrong, I like this a lot, but power efficiency is definitely not a reason. But it isn't a complete power hog either. Compared to 3D games, shaders will be trivial. No matrix multiplies for example and no perspective divides. The fan on the GPU should stay off, and even the lamest integrated GPU should be able to handle it easily.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    6. Re:but... by darkain · · Score: 1

      Theory and practice are not the same though. Check the actual docs and videos on webrender. The DOM + Compositing process currently used to re-render a single pixel is more expensive than cutting out that entire code path and rendering the entire scene. If you're only thinking of the final piece of pushing the actual pixel to the screen, that's the quickest part of the entire process. Figuring out what value that pixel should have in the first place is where all the CPU time is currently being consumed. That's the whole reason they're doing this the way they are.

    7. Re:but... by Tough+Love · · Score: 1

      Theory and practice are not the same though. Check the actual docs and videos on webrender. The DOM + Compositing process currently used to re-render a single pixel is more expensive than cutting out that entire code path and rendering the entire scene. If you're only thinking of the final piece of pushing the actual pixel to the screen, that's the quickest part of the entire process. Figuring out what value that pixel should have in the first place is where all the CPU time is currently being consumed. That's the whole reason they're doing this the way they are.

      Check the actual docs and videos on webrender. The DOM + Compositing process currently used to re-render a single pixel is more expensive than cutting out that entire code path and rendering the entire scene.

      The actual docs say the opposite. "The optimizations above have helped pages render faster in certain cases. When not much is changing on a page—for example, when there’s just a single blinking cursor—the browser will do the least amount of work possible."

      This is practice, not theory. Again, don't get me wrong, I like this a lot, but for some cases it will eat a lot more battery than incremental render. Whether that is a problem in practice remains to be seen. My guess: not a problem even on handsets, and perceptibly smoother browsing. I'll take it.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    8. Re:but... by darkain · · Score: 1

      And if you continued reading beyond that line of text, it explains why that worked in the early days of browsers, but doesn't work in modern browsers due to increased complexity of web pages.

    9. Re:but... by Tough+Love · · Score: 1

      Could you quote some text please.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    10. Re:but... by Anonymous Coward · · Score: 0

      When not much is changing on a page—for example, when there’s just a single blinking cursor—the browser will do the least amount of work possible."

      I think you must have missed the part in that article about z-culling. It's a different way of drastically reducing the amount of work necessary and the proof is in the pudding: smooth 60fps efficiently using the hardware acceleration available beats janky rendering that inefficiently leverages the available hardware.

    11. Re:but... by Tough+Love · · Score: 1

      Didn't miss it. Z-culling will improve the blinking cursor case, but not fix it completely. Again, note: I like this, but let's not attribute magical powers to the technique that aren't there.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    12. Re:but... by Anonymous Coward · · Score: 0

      Quite the opposite. If there is no invalidated states on the screen, no painting occurs. It only paints when it needs to. It actually consumes less power overall because of the amount of code that is required to handle invalidation of only parts of the screen is massively slow.

      Adding to this is a little known side effect that it takes time for hardware to ramp up and down. Even the latest "power management" features get smoked in interactivity tests because they can't respond fast enough. One common workaround is cpu affinity but it still doesn't dismiss the core issue. We're talking hundreds of ms in some cases, a deep sleeep for example to full power. On some CPUs you can set things like dma latency targets but those are lies at best, damn lies in reality (/dev/cpu_dma_latency).

      Really wish people would stop trying to reinvent hyper / macro scheduling, it will NEVER work.

    13. Re:but... by DontBeAMoran · · Score: 3, Funny

      Sure thing, buddy.

      Could you quote some text please.

      There you go.

      --
      #DeleteFacebook
    14. Re:but... by exomondo · · Score: 1

      I hope this is just an example rather than a measured result, because that would be drawing massive power.

      Why would it be drawing massive power? This is leveraging the GPU to do things it does well instead of putting them on the CPU that does them poorly.

    15. Re:but... by arth1 · · Score: 1

      This is why the browser renders so much faster. Instead of 200ms per paint of a small section of the screen, it renders the entire screen in 15ms. The rest of the time, your CPU/GPU sits idle. Also, Webrender does all rendering on the GPU instead of CPU, so it has better optimization for painting the scene (CPUs suck at this entirely)

      How does this work when the browser and GPU are on diifferent machines? I run my browser in remote X. Will that be tonnes slower when it transfers entire renderings over the network?

      (Never mind that "modern Xorg programmers" already killed LBX because they did not use it themselves so didn't see a need.)

    16. Re:but... by darkain · · Score: 1

      Check right now. How goes GPU compositing work with your current setup? I bet it doesn't, honestly. So you'd still be stuck in the classic software rendering that you currently already have.

    17. Re:but... by DontBeAMoran · · Score: 1

      If you saw me you would compare me to a polar bear, not someone from Africa.

      --
      #DeleteFacebook
    18. Re:but... by arth1 · · Score: 1

      Check right now. How goes GPU compositing work with your current setup? I bet it doesn't, honestly. So you'd still be stuck in the classic software rendering that you currently already have.

      Yes, but at least it only sends over the rectangles that change, and doesn't redraw the entire window. While X is no longer as frugal as when it had the LBX extension, it still handles partial updates. If I understand this correctly, they want to do away with that entirely and always update the entire viewport.

  2. What about the battery hit? by Anonymous Coward · · Score: 0

    I mean, sure i like performance, but what is the cpu/gpu usage and the battery hit with WebRenderer on?

    1. Re:What about the battery hit? by viperidaenz · · Score: 1

      If you're on a laptop with an nvidia gpu, usually the gpu is powered down and the integrated gpu is running everything, saving power.
      Now when Firefox is open, your nvidia gpu needs to stay powered up the whole time.

    2. Re:What about the battery hit? by Anonymous Coward · · Score: 0

      I disabled the nvidia GPU on my windoze laptop, though for saving RAM more than anything.
      If it were possible to disable the Intel GPU and enable the nvidia GPU I would have done so.

    3. Re:What about the battery hit? by foradoxium · · Score: 1

      I've never seen a laptop with a discreet board that did not allow you to change which video card applications used, usually in performance settings. If you wanted Firefox to not use the nvidia card you could just set it to static powersaving mode. 10 google seconds gave me this example: https://support.serato.com/hc/...

    4. Re:What about the battery hit? by Anonymous Coward · · Score: 0

      Just autoscrolling this Slashdot page I observed around twice the GPU load with WebRenderer on, but more than twice the CPU load with WebRenderer on.

      Maybe there's an advantage for video or apps, but I'm not impressed yet.

    5. Re:What about the battery hit? by viperidaenz · · Score: 1

      This Firefox feature only works on nvidia GPUs, as stated in the summary. How many CPUs have integrated nvidia GPUs?
      If you want Firefox to not use the discrete GPU, you can't use WebRender.

  3. how will it be JavaScript3D? by Anonymous Coward · · Score: 0

    JavaScript3D, DOM3D, HTML3D, CSS3D, when for?

  4. Another thing by Anonymous Coward · · Score: 0

    That trackers, ads and crypto miners will use. Wake me up when they restore xul support.

    1. Re:Another thing by jfdavis668 · · Score: 1

      There is no data. There is only XUL!

    2. Re:Another thing by Anonymous Coward · · Score: 0

      They will restore it when they restore Windows NT 3.51 support as well.

    3. Re:Another thing by DarkRookie · · Score: 1

      Wakeywakey.
      Firefox is not adding back XUL. Google doesn't use it. All web browser just copy that now.

      But the reason I wake you is that Waterfox will let you use XUL addons if you didnt know about it.

      --
      The millennial that doesn't like most of the stuff designed for millennials.
    4. Re:Another thing by Anonymous Coward · · Score: 0

      >All web browser just copy that now.

      Yeah, because the article you're in a comment thread about right now is totally about a browser feature that's copying's Google's browser. And XUL was removed just to copy Chrome.

      I've often wondered if staunch proponents of XUL have any notion of their situation in space-time at all. I guess now I can rest assured that they don't.

    5. Re:Another thing by DarkRookie · · Score: 1

      The removal of XUL from Firefox means I lost add ons that there are no viable replacements for.

      Classic Theme Restorer, Download Status Bar, and another one do not work with FF57+ and there are no replacements for them.

      --
      The millennial that doesn't like most of the stuff designed for millennials.
  5. min specs? by bobmagicii · · Score: 1

    âoeThis site requires an nVidia 2080Ti or better." - the new york times soon probably

    1. Re:min specs? by Anonymous Coward · · Score: 0

      Ha! Requiring Windows 10 already is bad enough.

  6. Found the LUDDITE! by Anonymous Coward · · Score: 2, Funny

    Only LUDDITES use WebRender. Modern app appers use AppApper!

    Apps!

    1. Re:Found the LUDDITE! by Calydor · · Score: 1

      What about AppRender?

      --
      -=This sig has nothing to do with my comment. Move along now=-
    2. Re:Found the LUDDITE! by Anonymous Coward · · Score: 0

      Not appy enough.

  7. Security implications? by llamalad · · Score: 1

    What are the security implications of letting web sites run arbitrary code on your GPU?

    I bet they're more significant than you're expecting.

    https://lib.dr.iastate.edu/cgi...

    https://ieeexplore.ieee.org/st...

    1. Re:Security implications? by viperidaenz · · Score: 1

      Good thing they're not running the javascript vm on the gpu then.

    2. Re:Security implications? by Anonymous Coward · · Score: 0

      Good thing they're not running the javascript vm on the gpu...

      ... yet.

      Fixed that for ya.

    3. Re:Security implications? by AHuxley · · Score: 1

      About the same as any 2018 OS or CPU :)

      --
      Domestic spying is now "Benign Information Gathering"
    4. Re:Security implications? by exomondo · · Score: 1

      What are the security implications of letting web sites run arbitrary code on your GPU?

      This article is about the web browser using the GPU for rendering, not about web sites running arbitrary code on the GPU.

    5. Re:Security implications? by DrXym · · Score: 1

      That's an issue for WebGL, not the mechanism by which a browser renders standard HTML content. For WebGL, most browsers would maintain a driver whitelist / blacklist although IMO it is still sailing dangerously close to the wind - a driver could declare itself WebGL capable (basically OpenGL ES 2/3 with the ability to reset state) and still be vulnerable in some way. Reminiscent of ActiveX controls self declaring themselves safe for scripting.

    6. Re:Security implications? by llamalad · · Score: 1

      Because it's impossible to have arbitrary code execution vulnerability in rendering software, and nor has anyone in history ever chained exploits together to achieve a desired outcome?

      Oh, wait-
      https://security.stackexchange...

      And chaining vulnerabilities is very common.

    7. Re:Security implications? by exomondo · · Score: 1

      Nice strawman but that's a very different thing to "letting web sites run arbitrary code on your GPU" which is absolutely not the goal here but if that's really the way that you're framing it then the answer is the implications are much less severe than letting web sites run arbitrary code on your CPU.

    8. Re:Security implications? by llamalad · · Score: 1

      Orly?

      https://www.digitaltrends.com/...

    9. Re:Security implications? by exomondo · · Score: 1

      Again, this is not about "letting web sites run arbitrary code on your GPU". But more to the point you obviously didn't even read that paper. In order to do that you need to first compromise the system at the root level so you can get access to the memory holding the keyboard buffer then run a CUDA program with admin privileges to map that memory to the GPU and execute the compute kernel to read that memory. i.e. to do this you need to have completely compromised the operating system already.

    10. Re:Security implications? by llamalad · · Score: 1

      You're driving a car down the road.

      Do you make decisions solely based on what's directly in front of your bumper?

      Or do you make decisions drawing from years of experience driving cars and what you see to either side and in the rearview mirror and your side mirrors and what you see further down the road and, dare I say it, common sense?

    11. Re:Security implications? by exomondo · · Score: 1

      Or do you make decisions drawing from years of experience driving cars and what you see to either side and in the rearview mirror and your side mirrors and what you see further down the road and, dare I say it, common sense?

      You seem very confused, you've posted links demonstrating that a privileged application can map kernel memory and run a CUDA program that can then access that memory, we already know that, that's not news (well actually it does seem to be news to you). Whether the browser uses the GPU to render something (which also has been done for a long time and is not a new thing) or not has no bearing whatsoever on that at all.

      There's nothing fundamentally about Firefox's Web Render that makes it any more or less vulnerable to the keylogger you linked than any other software. Your posts suggest you think there is, you are wrong.

    12. Re:Security implications? by llamalad · · Score: 1

      While walking along in desert sand, you suddenly look down and see a tortoise crawling toward you. You reach down and flip it over onto its back. The tortoise lies there, its belly baking in the hot sun, beating its legs, trying to turn itself over, but it cannot do so without your help.

      You are not helping.

      Why?

    13. Re:Security implications? by exomondo · · Score: 1

      If you can posit why a CUDA application executed via a privilege escalation bug is a risk to Web Render feature of Mozilla any more than to any other application then, or indeed what about Web Render makes it particularly prone to some unspecified GPU-based attack then I'm willing to listen but I'm afraid it's pretty clear you don't - and likely lack the capacity to - understand. I'm afraid I can't fix your stupid, sorry.

      Privilege escalation bugs that allow arbitrary execution of code on the GPU or any other processor are of concern but there is nothing that you can seem to point to that makes Web Render any more susceptible to such things that any other code.

  8. Idiots Design Web Pages that Render 15 FPS by BrendaEM · · Score: 3, Insightful

    It's not your computer.

    --
    https://www.youtube.com/c/BrendaEM
    1. Re:Idiots Design Web Pages that Render 15 FPS by DontBeAMoran · · Score: 1

      Oh good, I'm glad to know that my Pentium MMX 166MHz with 512MB RAM is not the problem.

      --
      #DeleteFacebook
  9. Imagine! by DeBaas · · Score: 1

    Imagine how wonderful /. will look!

    --
    ---
    1. Re:Imagine! by Anonymous Coward · · Score: 0

      And once the tensor cores are utilized, we, the Anonymous Cowards, shall post even more intelligently!

    2. Re:Imagine! by zlives · · Score: 2

      win 10 3d animated fonts to the rescue!!!

  10. Apps! by mujadaddy · · Score: 1

    Apping apps to the app so you can app the app!

    Okay, now that THAT'S out of the way, looks okay, but I think Randall should sue.

    --
    Populus vult decipi, ergo decipiatur...
    "Force shits upon Reason's back." - Poor Richard's Almanac
  11. Where's Donald Becker? by gerald.edward.butler · · Score: 1

    I'd like to get a Beowulf Cluster of these!

  12. 60 FPS is great; any plans for ... by UnknownSoldier · · Score: 2

    Any plans to target 120 Hz?

    1. Re:60 FPS is great; any plans for ... by fibonacci8 · · Score: 1

      I'm sure marketing has plans. 120 FPS is snake oil until either improved input methods exist, or the increased cost in bandwidth for the minimal visible benefit is solved. It can be done, but it's not worth customers paying for... for now.

      --
      Inheritance is the sincerest form of nepotism.
    2. Re:60 FPS is great; any plans for ... by Anonymous Coward · · Score: 0

      60Hz x two eyes, VRML for the win, Baby!

    3. Re:60 FPS is great; any plans for ... by Anonymous Coward · · Score: 0

      FYI Apple released a 120Hz iPad. (2nd generation iPad Pro 10.5" and 12.9")
      I spent a decade running CRT monitors at 100Hz, though people made fun at me. You can see the faster speed when moving the mouse cursor or scrolling text in a terminal, it's not anything special.. I also knew a guy who was a high level Quake 3 player and ran the game at a locked 125 fps in 2002. For human vision somewhere between 80 and 100 fps become well enough, but there isn't a fixed value it depends on content (contrast, edges, peripheral vs central vision). 125 fps just happened to be a value where you jump 1% farther in Quake 3 or something (next is 333 fps)

      In the comments in the youtube video linked to in TFS, the dev who made it says the graphics test ran at 140 fps with v-sync disabled (this on a 2012 laptop)

    4. Re:60 FPS is great; any plans for ... by Anonymous Coward · · Score: 0

      Both WebRender and the Direct3D 11 (Advanced Layers) compositors could render at 144 Hz when I tried it. WebRender seemed to have roughly twice as much GPU load as Direct3D 11 did.

    5. Re:60 FPS is great; any plans for ... by Waffle+Iron · · Score: 3, Funny

      I want a plugin to limit the browser to 24 FPS to make it look more cinematic.

    6. Re:60 FPS is great; any plans for ... by cerberusss · · Score: 1

      Amen, brother.

      *lazily sips coffee from fresh-roasted beans*

      I watch all of my browsing as shot on 35mm film, it's the only way I surf the internet nowadays.

      *pushes black-rimmed glasses further up my hipster nose*
      *adjusts suspenders*
      *checks 4th gen. Apple watch*

      --
      8 of 13 people found this answer helpful. Did you?
    7. Re:60 FPS is great; any plans for ... by Anonymous Coward · · Score: 0

      Motion blurred fonts are all the chrome these days.

  13. Relying on the GPU is a security mightmare by Anonymous Coward · · Score: 0

    We need to stop relying on the GPU for shit. It's a security nightmare. I understand why people want to do it, but there are good reasons to avoid it. GPU were never designed for this and opens up our computers to being easily compromised.

    1. Re:Relying on the GPU is a security mightmare by Anonymous Coward · · Score: 0

      Eh, the fact that Mozilla can enable a feature like this in an app that can just go ahead and utilize the GPU in this manner means that YOUR COMPUTERS ARE ALREADY EASILY COMPROMISED.

    2. Re:Relying on the GPU is a security mightmare by Anonymous Coward · · Score: 0

      Not for me, I ssh -X localhost everything I run. /s

    3. Re:Relying on the GPU is a security mightmare by Anonymous Coward · · Score: 0

      I agree with you about security, but Graphics Processing Units were designed to process graphics and that is what Mozilla is using them to do.

    4. Re:Relying on the GPU is a security mightmare by Anonymous Coward · · Score: 0

      I understand why people want to do it, but there are good reasons to avoid it.

      Such as?

      GPU were never designed for this and opens up our computers to being easily compromised.

      How exactly? There is a separation there, on the CPU side we see compromises because it manages the separation between kernel and userspace, the GPU does not have to contend with things like that.

  14. Just imagine the speed increase by the_skywise · · Score: 1

    if you took out all the damn javascript!

    1. Re:Just imagine the speed increase by Tough+Love · · Score: 2

      Even better, take out the Google spyware links. (Google is far from the only culprit, they just waste the most total time.)

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    2. Re:Just imagine the speed increase by DontBeAMoran · · Score: 1

      After that, remove all the godamn fucking 8K-resolution images, not everyone has a 30" quadruple-HiDPI display.

      --
      #DeleteFacebook
  15. commas by RoccamOccam · · Score: 2

    Lin Clark provides an excellent overview of WebRender and, states, "with WebRender...."

    I have no idea why I typed all of those commas.

    1. Re:commas by fibonacci8 · · Score: 2

      Shatner commas?

      --
      Inheritance is the sincerest form of nepotism.
  16. efficiency frontier hijack by epine · · Score: 1

    Also, Webrender does all rendering on the GPU instead of CPU, so it has better optimization for painting the scene (CPUs suck at this entirely).

    CPUs suck at this, in much the same way that decathletes suck at high jump.

    The only event that your GPU really loves is the marathon. Marathon anything—so long as it demands less cognitive agility than a biathlon.

    Efficient frontier

    So put that universal boner tingle back in your pants—everything in life is a tradeoff, if you so much as back the lens 1 mm away.

    Instead of 200 ms per paint of a small section of the screen, it renders the entire screen in 15 ms.

    Why do I suspect those numbers predate the 1950X Threadripper (which would tear your GPUs arms off in the hexakaidecathalon).

    I really don't think the word "sucks" should be applied to an elite athlete with 4% body fat who runs for a living, just because his pipes are too studly to ace the ultramarathon.

    1. Re:efficiency frontier hijack by Anonymous Coward · · Score: 0

      Why do I suspect those numbers predate the 1950X Threadripper (which would tear your GPUs arms off in the hexakaidecathalon).

      They don't, CPUs absolutely do suck at this task compared to GPUs. Inherently parallel problems like this comprised of many simple operations are obviously much more suited a processor designed to do that.

    2. Re:efficiency frontier hijack by exomondo · · Score: 1

      Why do I suspect those numbers predate the 1950X Threadripper (which would tear your GPUs arms off in the hexakaidecathalon).

      I really don't think the word "sucks" should be applied to an elite athlete with 4% body fat who runs for a living, just because his pipes are too studly to ace the ultramarathon.

      The reason you don't use your CPU to rasterize scenes in games is, quite frankly, because it sucks at it. The same thing applies here, of course you use the graphics processing unit to do this work because that is exactly what it is suited for and the CPU, while capable of doing it, is comparatively sucky at it. It doesn't matter how much praise you think a 1950XThreadripper deserves the fact is it is comparatively terrible at this task.

  17. browse in lynx, idiot by Anonymous Coward · · Score: 0

    if you took out all the damn javascript!

    why not just go back to gopher and ftp? 80-x24 text is all anyone ever needs

  18. Yay Mozilla by Tough+Love · · Score: 2

    Firefox is my main browser for a lot of reasons, not just that Google doesn't dominate it. Great to see the Mozilla team leading the way on this, and it's a big validation for Rust. Any serious systems programmer ought to take a close look methinks.

    --
    When all you have is a hammer, every problem starts to look like a thumb.
    1. Re: Yay Mozilla by Anonymous Coward · · Score: 0

      Or use other browsers that have had GPU offloading baked in for years

    2. Re: Yay Mozilla by Anonymous Coward · · Score: 0

      Firefox had GPU offloading for years, too.

    3. Re:Yay Mozilla by Anonymous Coward · · Score: 0

      Firefox is my main browser for a lot of reasons, not just that Google doesn't dominate it.

      Google does dominate it! Follow the money, just look at where Mozilla's revenue comes from.

  19. You want 60fps by DarkRookie · · Score: 2

    Don't program for a web browser.
    Or stop people from filling up their sites with bullshit JS and media.

    --
    The millennial that doesn't like most of the stuff designed for millennials.
    1. Re:You want 60fps by Anonymous Coward · · Score: 0

      Don't program for a web browser.

      Or stop people from filling up their sites with bullshit JS and media.

      just use lynx, loser

      that way you won't have to put up with any of that stuff

    2. Re:You want 60fps by Anonymous Coward · · Score: 0

      Don't program for a web browser.

      Why? Perhaps you have misunderstood the article or the headline but the crux of it is that you can indeed have web pages perform at 60fps. Web browsers have always worked in an antiquated way that we have moved beyond in the areas of modern games and desktop and mobile applications. This is about modernizing the way rendering is done in web browsers. The answer is not "don't use it because it's antiquated", the answer is "modernize it so it is no longer antiquated, just do it properly".

      If I want to write a simple application that runs on all platforms I shouldn't have to produce and distribute a binary for each one or get into the Java position of having to have users download additional VM runtimes for each platform since browser technology is available everywhere it is worth utilising and there's no reason it shouldn't be able to run at reasonable speeds for modern hardware.

    3. Re:You want 60fps by tepples · · Score: 1

      If I want to write a simple application that runs on all platforms I shouldn't have to produce and distribute a binary for each one

      Why not? Personally, I agree with you, but a lot of other Slashdot users claim to have had no problem with developing an application using Qt and "produc[ing] and distribut[ing] a binary for each one".

    4. Re:You want 60fps by Anonymous Coward · · Score: 0

      Why not? Personally, I agree with you, but a lot of other Slashdot users claim to have had no problem with developing an application using Qt and "produc[ing] and distribut[ing] a binary for each one".

      I'm not saying it isn't doable but that for a large class of applications it is wasted effort to have to build for a bunch of platforms and distribute via the various mechanisms that those platforms offer or require and then you have to go through that (or in some cases a subset of it) whenever you want to update. Then there is also a large class of applications where that approach is the better approach. It's not absolute in either case.

    5. Re:You want 60fps by thegarbz · · Score: 1

      Don't program for a web browser.

      Don't want to succeed, don't program for a popular platform.

    6. Re:You want 60fps by DarkRookie · · Score: 1

      Popular does not equal good.
      The top 40 radio stations prove that.

      --
      The millennial that doesn't like most of the stuff designed for millennials.
    7. Re:You want 60fps by thegarbz · · Score: 1

      That depends on what you want to achieve. A "good" provider for their family would like to run a successful business that makes money. In software if your popularity is zero so is your income. Your wife may not think you're very "good" for your idealistic choices of programming platform.

      Also turning your comment around, popular likewise doesn't mean bad. And as per TFA quite clearly if you want to achieve 60fps whatever that boiler plate statement may imply you could just fine program for a web browser.

  20. So? by BitztreamNotARealNam · · Score: 2

    How's life in the hypocrite lane?

  21. As a video games engineer, my reaction was... by Anonymous Coward · · Score: 0

    My reaction was OMG! They've been trying to do incremental screen updates on machines with a GPU? What were they thinking?!?

  22. Re:Still not getting it guys by Anonymous Coward · · Score: 1

    It's bitztream the autism-hating, custom EpiPen-hating, Musk-hating, Qualcomm-hating, Firefox tabs-hating, Slashdot editors-hating Slashdot troll!

  23. Tha Mozilla Hacks article was posted on October 10 by bartok · · Score: 1

    This is extremely old news. It would be interesting to know if that tech has been enabled for more than Win10 and Nvidia GPUs by now.

  24. AmigaOS had hw acceleration 20 years ago by Anonymous Coward · · Score: 0

    AmigaOS had hw acceleration 20 years ago

  25. CPU rendering is not the issue. by Anonymous Coward · · Score: 0

    CPU rendering is NOT the issue that needs to be fixed by elimination.
    What needs to be fixed is the shitty DOM system, as well as JavaScripts horrific scope model that falls to bits when you get more than 3 layers down.
    That's where ALL the slow-down is.
    You can easily write huge interactive web-pages that can hit the golden 60fps mark.
    The problem is all the shit-tier developers out there using libraries made by just as shit developers who don't understand WHY JavaScript and the DOM sucks ass, and how to prevent it.

    It's not even small-time devs either, GOOGLE do it. Hell, this fucking site does it. It's still massively better than the horrific mess that came before this, but even this still does it.
    Gmail went to shit when they started doing this. Google Maps chugs along on what was a gaming computer of the mid 2000s, Street View is sub-1fps last I checked on a netbook.
    Google Maps could run on a machine from the fucking 90s on the old code.
    This plague has infected everywhere.
    Wrapping functions in deep layers, deep inheritance, anonymous function wrappers out the fucking ass, it's all the shit that JavaScript is the WORST at doing that everyone is doing now.

    THAT is why things are so slow.
    Leave graphics intense stuff for the Canvas element. It works. It works very well.
    Still needs some tidying up and some other basic features though.
    The compositing system is so slow because the shitfest that is the DOM.
    It has a high cost for lookup and changes. A very high cost. See the usual arguments of "draw a 100 elements one after another versus embedding 100 elements to a parent container in JS, THEN drawing the container". It's embarrassingly bad.
    Delete it and start again. It's shit.
    Don't even bake backwards compatibility in to it. New system, totally incompatible. We already broke JavaScript for literally everything pre-Harmony with template strings and lambdas. (and some other stuff I think, Let maybe?)