Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Chrome Google

Google Chrome 34 Is Out: Responsive Images, Supervised Users 115

Posted by Soulskill from the onward-and-upward dept.
An anonymous reader writes "Google today released Chrome version 34 for Windows, Mac, and Linux. The new version includes support for responsive images, an unprefixed version of the Web Audio API, and importing supervised users. You can update to the latest release now using the browser's built-in silent updater, or download it directly from google.com/chrome."
This discussion has been archived. No new comments can be posted.

Google Chrome 34 Is Out: Responsive Images, Supervised Users More

Google Chrome 34 Is Out: Responsive Images, Supervised Users

Comments Filter:

  • Responsive Images (Score:5, Informative)

    by ADRA ( 37398 ) on Tuesday April 08, 2014 @03:40PM (#46698487)

    In case anyone wanted to know what responsive images are, I googles this imformative article on the subject:
    http://dev.opera.com/articles/... [opera.com]

    • Nah...TL:DR (Score:5, Informative)

      by xxxJonBoyxxx ( 565205 ) on Tuesday April 08, 2014 @03:50PM (#46698583)

      A "responsive image" will load either a small or large version (or multiple versions) depending on the browsers's screen resolution. To do this, it makes an extra request to the server before requesting the appropriate image size.

      (The referenced Opera article prattles on and on - Google's faster.)

      • Re: (Score:2, Interesting)

        by Anonymous Coward

        Soo... they reinvented mipmapping [wikipedia.org]?

        • Re: (Score:1)

          by Desler ( 1608317 )

          But it's "on the web"!!!!! That's totally new!!

        • Sort of, except its purpose is to reduce load time over the internet rather than increasing render efficiency for the client (nobody's computer struggles to display static images on a web page)

      • Wouldn't this be better with JPEG2000 or other wavelet based image format?

        You just fetch whatever level of detail you want, you just stop.

        • Re: (Score:1)

          by Anonymous Coward

          Battery life... computing wavelets consumes more energy than receiving bits, especially if you have no GPU or DSP hardware acceleration, either because it doesn't exist on the client or not powering one up saves the power cost.

          • Re: (Score:2)

            by tepples ( 727027 )

            computing wavelets consumes more energy than receiving bits

            How does the wavelet transform performed with lifting [wikipedia.org] use any more energy than the 8-band cosine transform of JPEG?

        • You don't need wavelets for that. Instead, all you really need is so-called "progressive JPEG": send the first 15 or 21 DCT coefficients for a half-resolution decode, then send more coefficients for the full-resolution decode. But in practice, that doesn't speed things up because in order to terminate the image download after the first few coefficients, the web browser has to close the HTTP connection instead of keeping it alive, which means yet another round of TCP slow start.

          • Re: (Score:2)

            by pjt33 ( 739471 )

            Should be possible to do it with range requests, surely? But it's a chicken-and-egg problem, because there's no point adding the overhead of testing whether the server supports ranges until PJPEG is more widespread, and the current status quo doesn't seem to motivate many people to use PJPEG.

            • Re: (Score:2)

              by tepples ( 727027 )

              Should be possible to do it with range requests, surely?

              Even if the browser knows that a server supports range requests, how will a browser know in advance what byte range corresponds to each PJPEG pass?

              • Re: (Score:2)

                by segin ( 883667 )
                Use range requests to only grab the JPEG headers, and then use further range requests to grab the rest of the data. Use HTTP Keep-Alive [wikipedia.org] and you can avoid some of the inefficiencies of multiple requests... of course, web browsers have been doing HTTP Keep-Alive for years now.

              • Re: (Score:2)

                by pjt33 ( 739471 )

                I don't think it needs to know in advance: the decode is probably faster than the network transfer, so it can request it in batches of size X, decode each batch while the next one is being transferred, and at worse fetch just under 2 batches more than it needs.

                • the decode is probably faster than the network transfer

                  That's not the bottleneck as much as the multi-decisecond latency of requesting each range over a wireless (satellite or cellular) connection.

                  so it can request it in batches of size X

                  How would the browser know what size X is, so that it doesn't get a tiny range, request another, wait two seconds, request another, wait two seconds, etc.?

                  • Re: (Score:2)

                    by pjt33 ( 739471 )

                    The browser picks size X. A simple implementation would hard-code a single X; a more advanced implementation would combine experimental evidence about the statistical properties of PJPEGs, the measured latency, the decode progress...

        • Re: (Score:3)

          by Bengie ( 1121981 )
          Reminds me of viewing porn as a child and watching the images slowly "come into focus".

          • Re: (Score:2)

            by vux984 ( 928602 )

            Reminds me of viewing porn as a child and watching the images slowly "come into focus".

            Or the images on google image search. Today.

        • Re: (Score:2)

          by Misagon ( 1135 )

          The only option would be "some other wavelet-based image format".

          JPEG-2000 is completely different to ordinary JPEG. It is crippled in that the encoding is quite complex, has a tonne of different ways it can be encoded and is therefore difficult to do at speed. The software decoders that are not dead-slow are proprietary.
          You wouldn't really win anything with using JPEG-2000.

      • A "responsive image" will load either a small or large version (or multiple versions) depending on the browsers's screen resolution. To do this, it makes an extra request to the server before requesting the appropriate image size.

        I use Googles Define: option a lot, would seriously miss it. Google says almost the same thing

        Yet a picture speaks a thousand word if you listen. The same picture on different platforms, requested responsive image will supply the correct picture
        to the appropriate device http://brightlemon.com/files/r... [brightlemon.com]

      • Re: (Score:1)

        by Aewyn ( 836766 )

        Don't know where you get the idea of an extra request from. What they have implemented is the srcset attribute (from the WHATWG HTML spec), which means that authors can write e.g.

        <img alt="Slashdot" src="slashdot_logo.png" srcset="slashdot_logo_big.png 2x">

        and the browser will then choose based on the viewport size and resolution which URL to load (whereas browsers that don't support this attribute will just load what's in src). In this case, it would load the big image if the resolution was at leas

      • Re: (Score:2)

        by jgoemat ( 565882 )

        To do this, it makes an extra request to the server before requesting the appropriate image size.

        This seems completely wrong, how did it get rated 5-Informative? One of the primary purposes is to use less bandwidth. Responsive images just tells the browser to load a different image based on screen size or pixel density, there's no extra request to the server.

    • Re: (Score:2)

      by jez9999 ( 618189 )

      Weird... I don't understand the problem they're describing in that blog post. Surely JS code can detect when viewport size is modified, and change images accordingly.

    • Re: (Score:2)

      by Ark42 ( 522144 )

      That article seems to present a lot of various ways Responsive Images could be implemented, without actually telling me which way was chosen, and which syntax Chrome actually supports now.

      • It was implemented retardedly. Instead of having repeated tags per item, you give a parse string srcset="jumbo.jpg 1x, jumbo2.jpg 2x, jumbo4.jpg 4x". They may as well have implemented it with JSON.

  • What about proper HiDPI support?

  • Why is this still a 32-bit browser? Java won't install in 32-bit browsers.

  • If it still eats up 1 GB memory for 3 open tabs (or 500 MB with no tabs), then sorry, it's still shit.

    • Running on linux mint I currently have 2 windows and a combined 29 tabs. Current memory footprint for all processes is 2256mb. Each tab seems to consume a minimum of 30mb uo to a max of 112mb.

      For specifics this page is using 31.1mb

      I personally don't have a problem with that given ever tab is a separate process.

      • Re:Memory usage? (Score:5, Informative)

        by Ingenium13 ( 162116 ) <ingenium&gmail,com> on Tuesday April 08, 2014 @06:17PM (#46700001) Homepage

        Wow, that's surprising. Chrome eats memory on Ubuntu 12.04. Using version 34, with 19 tabs open, I'm using 2.9GB of private memory and 1GB proportional. This page is using 150MB for me. Maybe it's a 64-bit thing? After a day or so memory usage will approach 6-8GB.

        I've found gmail to be particularly bad. My gmail tab is at 400MB right now, but within 24 hours it will balloon to 1GB and then keep growing. I think it usually ends up around 2-2.5GB after a few days, but I've seen it higher. I think there must be some kind of JS memory leak or something.

        That said, it's not usually that big of a deal for me. I have 16GB of RAM, most of which is just cache unless I load a VM. Chrome's memory leaks do force me to close the browser and restart it though when I need to free up a few GB for running multiple simultaneous VMs.

        • Should probably have specified - I'm on a 32bit system and the machine only has 4gb of ram. (custom software at work which is not currently 64bit friendly at all)

          Also have adblcok, ghostery, gmail notifier and a few other random things installed.

        • Re: (Score:2)

          by AmiMoJo ( 196126 ) *

          Maybe it's an issue with the Linux version. On Win7 x64 I see about 25MB for a Slashdot story tab. I'm using about 1.6GB total but have over 40 tabs open in three windows.

        • Yeah I have the same issue. I've tried various Linux distros (ubuntu based) and they all have the same issue. Chrome is a memory monster. Firefox works like we would expect. Very reasonable memory usage, Chrome though is just as you stated. In fact, I run Linux Mint 16 at the moment. I had 2GB in this notebook. I upgraded to 6GB, just so I could run Chrome...lol. Yes, I upgraded memory - to run a browser...lol. I sort of rely on my Google accounts integration with Chrome, so it's worth it to me. Really, I

      • Re: (Score:2)

        by geekoid ( 135745 )

        I have 3 tabs and 11 process for chrome running. Total memory usage is about 500MB
        I have ad blocker, and a few developer extensions running.
        I'm on a win7 64 bit box.

      • 32-bit Windows -- chrome taking 256MB...at first. Has shrunk down to 165MB a few minutes later. Not my idea of acceptable memory usage.

        Opera, with 17 tabs, and it has been running for a few days, is only using 323MB

  • Rather have vector (Score:3, Interesting)

    by Chelloveck ( 14643 ) on Tuesday April 08, 2014 @04:38PM (#46699131)
    I have a dream... Where, instead of learning to support some new "responsive image" paradigm, the web designers of the world focus their efforts on learning to make use of the responsive vector images that browsers already support.

    • Re: (Score:2)

      by Desler ( 1608317 )

      Ignoring the fact that most images on the web are not vector-based to begin with?

      • Most images on the web are used to render fancy box borders user elements, another set is used to simulate their shadows. If those elements would not be kludged together as so-called css-sprites, the majority of images on the web WOULD be vector based.

    • Vectorize this (Score:4, Insightful)

      by tepples ( 727027 ) <tepplesNO@SPAMgmail.com> on Tuesday April 08, 2014 @04:49PM (#46699237) Homepage Journal
      True, with IE for XP officially dead, it's finally safe to use SVG on the vast majority of browsers. But good luck efficiently vectorizing a photograph received through a camera lens.

    • Yeah, vector photographs, those work great!

      • Re: (Score:2)

        by segin ( 883667 )

        The vast majority of images on the web aren't photographs and could easily be vectorized. Need some examples? The Slashdot logo, the stats "medal" icon, the user settings icon in the user info box, the Slashdot TV icon, the Chrome logo in the summary, every single comment's "flag this comment" icon, the friends bubbles...

        There's about 700 images on this very page alone that could be vectorized. None of them are actual photographs.

    • Re:Rather have vector (Score:5, Insightful)

      by locopuyo ( 1433631 ) on Tuesday April 08, 2014 @05:45PM (#46699691) Homepage
      I'll just snap a vector image here with my camera....

      • Re: (Score:2)

        by narcc ( 412956 )

        I think the idea is to use vector images for the zillions of things that aren't photographs. It's a very good idea.

      • Ever heard of an autotracer? Some of the new ones work amazingly well.
  • All of the good mouse gesture add-ons broke when chrome update 32 removed some legacy features in the name of security. The only mouse gestures that work now have ad-ware built in. Why can't someone make an open source mouse gesture add on?

  • Re: Google Chrome 34 is Out (Score:5, Funny)

    by Zanadou ( 1043400 ) on Tuesday April 08, 2014 @07:26PM (#46700545)

    You can update to the latest release now using the browser's built-in silent updater

    Whoa, whoa, slow down... could you walk me though that?

  • Let me know (Score:4, Insightful)

    by Lord Kano ( 13027 ) on Tuesday April 08, 2014 @10:57PM (#46701713) Homepage Journal

    when they add a menu bar. Until then, I have ZERO interest in Chrome.
    I'm not trolling. I'm completely serious. Removing a standard UI component "just because" is an absolute deal breaker for me.

    LK

    • Re: (Score:1)

      by Anonymous Coward

      How about "Just because it gives more vertical space for the webpage". Yes, that 7mm is appreciated on a 16:9 screen.

      • Re: (Score:3)

        by jez9999 ( 618189 )

        Then stop buying computer monitors that are designed for viewing Hollywood movies and start buying ones that are designed for general-purpose computing.

      • Hit F11 - be astounded by the extra browser content screenspace. Now if only that didn't also fill the horizontal, eh.

      • How about "Just because it gives more vertical space for the webpage". Yes, that 7mm is appreciated on a 16:9 screen.

        Whoa there, you're flat-out contradicting the $millions in user interface research that went into the Ribbon.

    • I don't need a menu bar, just a normal window title bar will do me, like every other app on my computer.

      Grr.

      • That's cool that it works out for you, but I won't touch a browser without a menu bar.

        I hate the ribbon interface in Office too.

        LK

Slashdot Top Deals

The sooner all the animals are extinct, the sooner we'll find their money. - Ed Bluestone

Close