Announcement

Collapse
No announcement yet.

Mozilla's Servo Has Been Picking Up A Number Of WebGL Improvements

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Mozilla's Servo Has Been Picking Up A Number Of WebGL Improvements

    Phoronix: Mozilla's Servo Has Been Picking Up A Number Of WebGL Improvements

    After being on hiatus since the end of April, Mozilla's Servo Blog has finally put out a status update concerning their web engine improvements made over the past three months...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Originally posted by tildearrow

    Maybe not a crash in the Rust engine? Otherwise I am surprised.
    No programming language will magically prevent all classes of bugs.

    For example, I just ran into two "bad assumption by programmer" bugs in the Serde serialization/deserialization library for Rust and reported them.
    • The default serializer for the data type used for file timestamps panics if it encounters a timestamp prior to the UNIX epoch... and the ext2/ext3/ext4 family of filesystems does allow negative "seconds since the epoch" values. I discovered it in testing against real files.
    • The default serializer for filesystem paths naively maps them to UTF-8 strings when outputting JSON, which causes it to error out if you run into a filename that isn't a sequence of valid codepoints. (In my case, mojibake combined with POSIX filesystems allowing any sequence of bytes except NUL or / to be a filename, but the same should be possible on Windows, since it allows un-paired surrogates in UTF-16 filenames for legacy compatibility.)
    Last edited by ssokolow; 24 July 2018, 07:18 AM.

    Comment


    • #3
      Originally posted by tildearrow

      Maybe not a crash in the Rust engine? Otherwise I am surprised.
      I'm pretty sure that the point of Rust was to 1) avoid null pointers, 2) avoid buffer under/overflow 3) make concurrency correctness the default and provable. These things in and of themselves don't make code automatically correct. Bugs will still happen (including bugs that crash the application), however a substantial set of bugs that are security related are completely avoided.

      Comment


      • #4
        Originally posted by atomsymbol
        I don't see how the programming language Rust alone is supposed to guarantee bugfree software.
        Rust never guaranteed that. It is a language that makes it easier to write multi-threaded code, that's all.

        Comment


        • #5
          Originally posted by atomsymbol
          The rendering is broken on all sites I tried to browse with Servo. It crashes when browsing http://anandtech.com. I don't see how the programming language Rust alone is supposed to guarantee bugfree software.
          I don't think anyone is claiming Rust will make something bugfree. What it's supposed to do is prevent memory leaks, buffer overruns, and user-after-free errors without adding any runtime performance or memory overhead.

          That's still a huge benefit. But browser rendering engines are monstrously complicated.

          Comment


          • #6
            Originally posted by Creak View Post
            Rust never guaranteed that. It is a language that makes it easier to write multi-threaded code, that's all.
            To be fair to Rust, the type system is pretty damn powerful. For example, aside from the "require that it end on a valid terminal state" part, you can use Rust's type system to compile-time verify correct use of any API that can be modelled as a state machine.

            (Hyper uses that capability to catch things like trying to set headers after the body of an HTTP request has already started streaming.)

            Comment


            • #7
              Originally posted by ssokolow View Post

              No programming language will magically prevent all classes of bugs.

              For example, I just ran into two "bad assumption by programmer" bugs in the Serde serialization/deserialization library for Rust and reported them.
              • The default serializer for the data type used for file timestamps panics if it encounters a timestamp prior to the UNIX epoch... and the ext2/ext3/ext4 family of filesystems does allow negative "seconds since the epoch" values. I discovered it in testing against real files.
              • The default serializer for filesystem paths naively maps them to UTF-8 strings when outputting JSON, which causes it to error out if you run into a filename that isn't a sequence of valid codepoints. (In my case, mojibake combined with POSIX filesystems allowing any sequence of bytes except NUL or / to be a filename.)
              The problem in both cases is, the 'function' that deals with the data doesn't handle totality. These safer languages provide more tools to achieve that. Apparently you're not familiar with theorem proving languages. There you must react to negative values too.

              Comment


              • #8
                You can create an infinite loop in any langauge. Same with some other bugs. What rust does it eliminate <i>some</i> bug types.

                Comment


                • #9
                  Originally posted by atomsymbol
                  The rendering is broken on all sites I tried to browse with Servo. It crashes when browsing http://anandtech.com.
                  Did you report those issues? Open the crash report in `about:crashes`, go to the Bugzilla tab and see if it's already reported/tracked.

                  Originally posted by atomsymbol
                  I don't see how the programming language Rust alone is supposed to guarantee bugfree software.
                  It isn't. Certain crashes are even expected, since that's better than having security issues silently creep around. And since e10s it should only crash a content process anyways.

                  Comment


                  • #10
                    They should finally address the problems with WebGL rendering performance on Linux (and according to this bug macOS too). Google Maps 3D is a pain to use and it affects scrolling performance etc. too with compositing enabled (not especially bad but you definitely notice the slower rendering than Chromium). Mozilla knows it for at least four years and is still undecided what (if any) to do about it!

                    Comment

                    Working...
                    X