Announcement

Collapse
No announcement yet.

LibreOffice's 3D Renderer Now Supports Multi-Threading

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

  • LibreOffice's 3D Renderer Now Supports Multi-Threading

    Phoronix: LibreOffice's 3D Renderer Now Supports Multi-Threading

    The 3D/OpenGL support in LibreOffice just got a bit better with now supporting multi-threaded rendering...

    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
    When is this used?

    Is this used in LibreOffice Impress for things like PowerPoint presentations?

    Comment


    • #3
      Originally posted by uid313 View Post
      When is this used?

      Is this used in LibreOffice Impress for things like PowerPoint presentations?
      i wasn't following it that well, but if not mistaking, it will basically render everything using 3D. For any 3d graphics, CPU is usually bottleneck if 3d part of app is single threaded.

      Comment


      • #4
        why does libreoffice contain its own gigantic software rendering library in the first place? there's like countless out there, including ones that will try hardware first and fall back to software only if necessary. libreoffice is already is an enormously complicated project, why would you purposefully add to its complexity with an extraneous subsystem like this? from the outside looking in it really seems like a case of nih syndrome

        if this is someones pet project then fine, good for them. if you want to reinvent the wheel on your own time i see nothing wrong that. but if i were a big donor and found out that this part of the code was being further developed and maintained with money from the foundation, i'd be pretty pissed off about it (unless there's a good reason to justify its existence).

        Comment


        • #5
          Because fixing broken stuff is so boring. Instead they include ten new experimental features and show them on screenshots how important these are. A small paragraph at the end describes bug fixes which was introduced in previous versions. Longterm bugs will also be maintained but who cares.

          Comment


          • #6
            Because fixing broken stuff is so boring. Instead they include ten new experimental features and show them on screenshots how important these are. A small paragraph at the end describes bug fixes which was introduced in previous versions. Longterm bugs will also be maintained but who cares.
            I think every user who really tries to work in LibreOffice is frustrated. No one interested in bug fixing, too many longterm bugs. It seems that this project is for developers of new features, not for users.

            Comment


            • #7
              From my point of view, the biggest bug in LO/OO is Java dependency, bottom line.

              Comment


              • #8
                Didn't read carefully. They are using OpenGL. Anyway. I agree with the previous posters that they might have bigger problems than a 3D engine.
                The text below is for you amusement

                I wonder what they are trying to accomplish. I don't know the details of LibreOffice's rendering engine, but if they needed serious 3D rendering, they should probably make use of APIs that were built for that. OpenGL for example ;-) But then they'd probably not go multi threading on the rendering part. You don't wanna share a rendering context between threads with that API. But still - if they're die hard multi threaders, they could give Vulkan a shot ;-)
                If they're really inventing several wheels in their huge code base, as a few previous posters said, they need to wake up. This isn't the 80ties - no need for CPU based 3D rendering :-P And I guess even back then there were more sophisticated methods.
                Maybe they get support from a competitor (the makers of a popular office software that shall remain anonymous ;-) ) to make crappy software.
                'nuff trolling for today (I hope *g*)
                Last edited by markd; 09 May 2016, 06:31 AM.

                Comment


                • #9
                  Originally posted by markd View Post
                  Didn't read carefully. They are using OpenGL.
                  i see no use of opengl anywhere, at least not in the commit the article linked to. just look at the top function named BPixelRasterToBitmapEx, it's performing software rasterization.

                  my best guess would be that the giant internal software rendering library is legacy code from (star|open)office, but instead of extending and maintaining this code they'd be much better off ripping it out and hooking it up to some third party external or internal library like cairo, skia, nanovg, etc for 2d graphics and opengl for 3d. if they really must have software fallback at the application level, iirc you can setup and use mesa's llvmpipe for that.
                  Last edited by e_tank; 09 May 2016, 04:36 PM.

                  Comment


                  • #10
                    Originally posted by e_tank View Post
                    i see no use of opengl anywhere, at least not in the commit the article linked to. just look at the top function named BPixelRasterToBitmapEx, it's performing software rasterization.
                    Yeah.. this commit has nothing to do with OpenGL. In LibreOffice you can insert 3D objects like cube, sphere, torus which IMHO I don't know who really uses them but still.. they were added in the SO/OO era. This commit makes rendering them in software faster.

                    Originally posted by e_tank View Post
                    my best guess would be that the giant internal software rendering library is legacy code from (star|open)office, but instead of extending and maintaining this code they'd be much better off ripping it out and hooking it up to some third party external or internal library like cairo, skia, nanovg, etc for 2d graphics and opengl for 3d. if they really must have software fallback at the application level, iirc you can setup and use mesa's llvmpipe for that.
                    Ripping drawinglayer out is not that easy - it is in the end also used for the model of 2D/3D objects and they are used ~all over the code. Also rendering is not coupled to the drawinglayer - it is just one or two classes where the rendering of a object is delegated or a decomposition to more simple primitives is performed. The actual rendering is delegated to the native renderer (cairo in gtk3, X11 and Xrender in gtk2, GDI+ in Windows, our OpenGL 2D renderer,...) and if this is not available we do it in software.

                    We have generally chosen to build our own OpenGL 2D renderer because none of other libraries really were suitable for what we needed and we thought it wasn't that hard to do it. Skia is its own little environment not just a mere 2D library, it is also a moving target - no really stable releases (or at least it was so at that time we started). We use cairo for software 2D when using gtk3 / headless rendering, however OpenGL accelerated cairo hasn't really been worked on or widely available. I discovered nanovg just recently and seems great, however when the OpenGL (overall) 2D renderer work started we didn't know about it (I wasn't directly involved then too).

                    Comment

                    Working...
                    X