Announcement

Collapse
No announcement yet.

Making Compiler, Disk Testing More Reproducible

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

  • Making Compiler, Disk Testing More Reproducible

    Phoronix: Making Compiler, Disk Testing More Reproducible

    There's some enhancements to share that make compiler and disk testing more reproducible under Linux, plus many other features...

    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
    The text in the PNGs is clipped:

    Comment


    • #3
      Originally posted by curaga View Post
      The text in the PNGs is clipped:

      I haven't yet implemented any artificial word-wrapping support in the PNG back-end renderer... Opera is the only major browser where SVG is black-listed, even Microsoft IE does better. Opera still can't handle text dominant-baseline...
      Michael Larabel
      https://www.michaellarabel.com/

      Comment


      • #4
        Just curious, why do you have to do manual png support? Couldn't you just pipe the svg to rsvg, or any other svg renderer and let them handle the conversion to png?

        Comment


        • #5
          Originally posted by phoronix View Post
          If you're browser doesn't yet fully support SVG,
          I'm not a browser!

          (Sorry, I couldn't resist)

          Comment


          • #6
            Originally posted by curaga View Post
            Just curious, why do you have to do manual png support? Couldn't you just pipe the svg to rsvg, or any other svg renderer and let them handle the conversion to png?
            Previous to the forthcoming 3.8-Bygland release, pts_Graph used bilde_renderer, which was a cross-format image renderer I came up with. The single API exposed that was used by pts_Graph could then seamlessly target SVG, PNG, JPEG, SVGZ, Adobe SWF/Flash, etc with different back-end renderers. With 3.8 the focus has changed to using an SVG DOM directly. The only time PNG (or anything else) is being used is when either targeting a problematic browser or when inserting graphs into an Adobe PDF file. In terms of not using any external SVG-to-PNG converter now, I prefer eliminating the need of external dependencies, etc. SVG is the main focus. The PNG renderer I wrote for Bygland that accepts the SVG DOM as input can produce a near static parity in about 400 lines of code, which is efficient for fall-back purposes when doing the rendering on OpenBenchmarking.org.
            Michael Larabel
            https://www.michaellarabel.com/

            Comment


            • #7
              Originally posted by curaga View Post
              Just curious, why do you have to do manual png support? Couldn't you just pipe the svg to rsvg, or any other svg renderer and let them handle the conversion to png?
              CURAGA:

              Within PTS Git I changed around how SVG text alignment is done so it avoids most use of the dominant-baseline attribute where Opera falls on its face... On OB, you can try appending '&force_format=SVG' to any of the URLs to get SVG graphs.... do those pretty much show up nicely for you? Opera may be white-listed soon with this new renderer that avoids dominant-baseline attribute.

              e.g. http://openbenchmarking.org/result/1...rce_format=SVG
              Michael Larabel
              https://www.michaellarabel.com/

              Comment


              • #8
                Thanks for taking care of the browser minority Michael.

                The alignment is now fine, but some text is even more unreadable than in the PNGs. The summary table looks fully OK.



                --------------

                In the bars, the top-left description is clipped. There's some unreadable text here too:

                Comment

                Working...
                X