191–200 of 212 posts
Just tried it with the Nightly by setting gfx.webrender.enabled to true in about:config. Wow, that thing flies. It's seriously amazing. And so far no bugs or visual inconsistencies I could detect. Firefox is really making great progress on this front!
Earlier quoted context omitted.
Actually, virtually every device the average grade consumer uses, has a GPU. For instance, even Atom processors have GPUs. Granted, they don't have as much cores as a full-fledged nVidia GPU, nor as much dedicated memory, but they are still GPU with several tens of cores and specialized APIs that were designed specifically for the tasks at hand. Plus, they offload (ish) the CPU.
Something without a GPU: VirtualBox. Last time I tried a Servo nightly in VirtualBox (to be fair, a few months ago), it immediately crashed/aborted with a GPU-related error. I think there's a good argument for preventing security-critical apps from raw GPU access, because graphics cards and drivers are a huge amount of attack surface. I still think WebRender is the way forward, but I hope they get it working with som…
If anything it'll push the GPU makers to have better drivers support.
EDIT: As for the no-GPU case, it is an edge-case, in which we could for example switch to the classical renderer. If you're running FF from a VM as your daily driver, there's something not right somewhere I think. (I'm thinking of C&C servers for satellites still running on WinXP and stuff)
Earlier quoted context omitted.
I'll admit I'm certainly not an expert on browser rendering pipelines, but that's not the impression the article gave. Rather, it suggested that current browser engines may, in fact, be more efficient in terms of the absolute number of computations done. When discussing existing browsers: > But often the things on these layers didn’t change from frame to frame. For example, think of a traditional animation. The backg…
There's some interesting discussion about this very topic happening on /r/rust right now: https://www.reddit.com/r/rust/comments/75hzk5/the_whole_web_... A particularly relevant bit: > For the case where the CPU would have painted a single pixel, WR will certainly use a bit more power than CPU rendering with a compositor. For the case where a large portion of the screen changes, CPU renderers might miss their frame b…
Earlier quoted context omitted.
Speaking of batching, I look at this demo [1] on my mobile phone, and I can get ~3500 sprites without dropping below 60FPS. A web page may not be able to reuse as much image data, I know. But smart game engines frequently look for ways to better batch sprites. And technically speaking, if you're using a Z-buffer, you don't need to sort opaque layers at all . You can draw the layers in back and then draw more layers i…
As far as I understand this, that demo will have no benefit whatsoever from the changes described in the article. Since it uses with WebGL, it has always done all its rendering on the GPU in a videogame style way – in any version of any browser.
This is great! I'm really impressed by the technical achievement, and hope everyone takes lessons from it to put performance and FPS at the forefront of their concerns when developing applications. Sadly, seeing the state of the industry, people will just use this as an excuse to continue write more and more sloppy code that would perform terrible even on the newest and faster WebRender version. In other words, this…
Just tried it with the Nightly by setting gfx.webrender.enabled to true in about:config. Wow, that thing flies. It's seriously amazing. And so far no bugs or visual inconsistencies I could detect. Firefox is really making great progress on this front!
Just tried it with the Nightly by setting gfx.webrender.enabled to true in about:config. Wow, that thing flies. It's seriously amazing. And so far no bugs or visual inconsistencies I could detect. Firefox is really making great progress on this front!
I really want to use Firefox full time, but I miss Safari's multi-touch gesture integration.
For example, I use a four finger swipe down to hit CMD-W, which closes the window in focus for most apps.
Earlier quoted context omitted.
Let's clarify, WebRender doesn't do anything at all if nothing changed. If the content of the window is static then webrender won't wake your gpu up until it really needs to. There seem to be a confusion about video games needing to render at constant frame rate, but that is only the case in games where there is always something changing on screen. It isn't that uncommon for other types of games with more static grap…
What about if a tiny thing changes? Perhaps animated avatars totaling 1% of the page. Is that a scenario where the new method might use more power, because it redraws too much?
Humourously enough, when I worked on a team that was writing a graphical web browser for mobile in the late 90's [1], they used a display list for rendering. The reasoning was somewhat different, web pages were essentially static (we didn't do "DHTML"), if the page rendering process could generate an efficient display list, then the page source could be discarded, and only the display list needed to be held in memory…
The FORTH code then downloaded PostScript code into the NeWS server, where it would be executed in the server to draw the page.
It even had an Emacs interface written in Mocklisp!
http://www.donhopkins.com/home/archive/HyperTIES/ties.doc.tx...
http://www.donhopkins.com/home/images/HyperTIESDiagram.jpg http://www.donhopkins.com/home/images/HyperTIESAuthoring.jpg
http://www.donhopkins.com/drupal/node/101 http://www.donhopkins.com/drupal/node/102
http://www.donhopkins.com/home/ties/ http://www.donhopkins.com/home/ties/fmt.f http://www.donhopkins.com/home/ties/fmt.c http://www.donhopkins.com/home/ties/fmt.cps http://www.donhopkins.com/home/ties/fmt.ps http://www.donhopkins.com/home/ties/ties-2.ml
Earlier quoted context omitted.
What about if a tiny thing changes? Perhaps animated avatars totaling 1% of the page. Is that a scenario where the new method might use more power, because it redraws too much?
A compositor is already repainting the whole window on the GPU. WR doesn't change anything here.
