Firefox fixes save gigabytes of memory on image-heavy pages • Hacker News Board

Re: Firefox fixes save gigabytes of memory on image-heavy pages

#201

Post by hosay123 » Fri, Oct 04, 2013, 3:55 AM UTC

kmike84 wrote: post #112

Peaker wrote: post #68

Earlier quoted context omitted.

Last I tried Firefox, pretty recently, it still needed to address some serious issues, when compared to Chrome: * Unresponsiveness due to one tab thrashing * Bad use of screen-space (bookmarks always visible, cannot disappear titlebar like in Chrome [there's only a Windows extension for that], menu-bar takes up another bar of space by default) * Launching firefox has stop-the-world behavior to check/update extensions…

I switched to Firefox from Chrome a couple of months ago, and liked it so far. The UI is fine, and the speed is also fine. But the MacOS+Firefox+Gmail bug ( https://bugzilla.mozilla.org/show_bug.cgi?id=341886 ) drives me nuts. Can't jump to the start or the end of line while editing the message (OK, it is possible with emacs shortcuts instead of standard Mac shortcuts). Can't select text from the current position to…

Woah. Been using that combo since 2006 and never once noticed this issue. You know alt/left+right moves between words? This is why I never noticed

Re: Firefox fixes save gigabytes of memory on image-heavy pages

#202

Post by mattlutze » Fri, Oct 04, 2013, 4:57 PM UTC

mistercow wrote: post #90

mattlutze wrote: post #18

Earlier quoted context omitted.

Technically it's three trials of 2D data, with the axes being Time and Memory Usage. The width of the lines given by the version axis is for visibility, not to encode data. A 2D line graph with 3 colors for the different versions would be an appropriate visualization. This one suffers spatial distortion and is only useful in confirming that yes, they use less memory in step 2 now.

>The width of the lines given by the version axis is for visibility, not to encode data. Bar graphs do exactly the same thing in a 2D graph. Would you suggest that all bar graphs be replaced by a one pixel wide stacked bar graph? Of course not, because even though the samples in a bar graph are discrete, they convey order. It's the same here. The width of the lines is only for visibility, but the Z position of the li…

I do agree that a style with discrete steps would also be appropriate.

To the other points, no, not all bar graphs do the same thing. Bar graph bars are often the width they are due to data binning, where the width has significance.

The graph was trivial, but made less clear by the 3D isometric projection. the spatial distortion is reduced but not canceled out by the space.

3D pie charts share the same failure. Yes, as long as the tilt is slight, they are still mostly readable. But it will make "closer" wedges appear larger and "farther" wedges appear smaller. It's visual dishonesty and unnecessary.

Just because one can finagle understanding out of a visualization does not make it a good visualization.

Re: Firefox fixes save gigabytes of memory on image-heavy pages

#203

Post by swift » Mon, Oct 07, 2013, 10:07 PM UTC

NathanKP wrote: post #120

swift wrote: post #108

Earlier quoted context omitted.

I don't know that I'd characterize this as a workaround. Infinity.js is definitely a good approach, but you should expect good baseline performance from the browser even without more complicated techniques.

I expect good baseline performance from a combination of both the HTML and JavaScript code of the page, and the browser. Sure it's nice if the browser does some tricks to make a badly written page that has 2 GB of image data on it play somewhat more nicely on the system, but if that page loads badly its not the browsers fault, its the fault of the web developer who didn't paginate, or use Infinity.js or something lik…

Honestly, this is pretty similar in effect to a UITableView-style wrapper, except that it's handled automatically by the platform. Sophisticated JS-only webapps are perhaps a different case, but a site that consists primarily of HTML and CSS should work just fine across a variety of different devices with different performance characteristics and memory capacities, automatically. This is one of the advantages of a declarative model like HTML/CSS: it gives the implementation a lot of freedom to apply optimizations and adapt to the limitations of the platform it's running on.

I guess what I'm trying to say is that this isn't a workaround - it's one of the primary reasons HTML and CSS are architected in the way that they are. This has nothing to do with helping inexperienced web developers and everything to do with preserving the declarative nature of basic web content.