Development/LHM LiMux

    From The Document Foundation Wiki

    TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate

    OpenGL / VCL Rendering Backend

    * Bitmap / VirtualDevice use textures as their OS/representation
    + no problem with lots of small bitmaps
    + happy with lots of 32x32 bitmaps.
    + code already in chart handling

* OpenGL SalGraphics magic
    + infrastructure work
    + basic guts:
        + line / fill props
        + clipping
    + bitmap compositing
    + basic line / pixel methods
    + polypolygon / polygon
    + Font/Text rendering
        + caching etc.
        + ignore text measure / embed etc.
    + basebmp for nasties
        + touches every method, fallback elsewhere.
    + copyArea / copyBits

* Optional OpenGL foo:
    + image scaling API/foo
    + drawPolyLine (caps etc.)
    + bezier bits

* OpenGL/ES support ...
    + use a limited OpenGL API / subset.

    Un-structured notes

    * Simple OpenGL / VCL backend ...

* What level to do this at ?
    + basebmp ... / basegfx.

* Implement the salgdi virtual interface ...
    + a number of weird raster-ops ...
        + mostly don't need them.
            + some WMF / EMF / old-school files.
        + significantly easier ... S/W renderer
          for the WMF stuff.
        + and slim down the OS API ...
        + render SVM (excised all of them from the code)
            + Armin says -> very few ...
            + remove from public API.
        + how best to isolate the meta-file renders ?

* AI:   + check few horrible raster-ops ...
        + use fallback - basebmp ...

* Write another plugin ...
    + font backend / salgdi rendering / etc. ...
    + basebmp just a tool ...
    + inside the VCL plugin, fallback to S/W rendering ...
      raster-ops
        + contain the poison there.

* sub-classing basebmp:
    + seems like a good idea (?)

* OpenGL/ES -> render target.

* Markus:
    + lots of different drawing-layer features ...
    + use a quite old OpenGL version : OpenGL 2.0 ...
        + means, quite a lot of work ...
        + uncommonly used / how many are there ?
        + lots of corner-cases ...
            + lots of non-obvious stuff, chart2 ...
            + remove stuff, after done everything ?
            + still have text positioning issues

    + 2 stage approach:
        + collect objects & then render them ...
        + set properties quite late; long after creating
          the objects, and re-render them.

Thorsten:
    + biggest problem is writer ... no scene graph.

Drawinglayer - renders using VCL ...
    + renderer using VCL - a few thousand lines of code ...
        + not the most complex piece to get a native
          renderer for.

Writer still uses VCL directly ...
    + need something.

* Basebmp ->
    + very simple indeed ...

* OpenGL basebmp impl ... ?
    + problem with that ? VCL as well ... proceedural.
    + chuck drawing call out there; show on screen.

* problems with 2D (Markus)
    + increase the z border, drawing new layers ...

* push GL bits through into the drawing layer ? ...
    + higher up ?

* VCL output device methods ->
    + SalGraphics ...
        + fun.

* how does basegfx deal with Xor mode ...
    + try - find, an hour going through code ... XOR
        + isolated to meta-files
    + just vclprocessor -> fallback to S/W rendering.
        + few days: fallback to S/W rendering ...
    + terror: 'getPixel' -> also not used ...

* wrapping the GL API -> helps to wrap stuff
    - not scatter bugs and workarounds all around the place
    + outputdevice cut down to sensible functionality ...
        + whatever GPU programming language.
    + documented, standardized, floating point etc.
        + minimal API wrapping openGL ...

* Start with SalGraphics API ...
    + all in 'pixels'

* Target is Windows initially ...

* problems:
    + copyArea, copyBits -> problem
    + getPixel etc.
    + bool returning problems: (with fallbacks)
        + drawEPS
        + drawNativeControl
            + [ which we want to support ]
            + to pixels & to screen ...
    + 'invert' -> a problem.
    + 'Bitmaps' -> OpenGL bitmaps ...
        + as textures.

* non-problems:
    + Clipping
    + text -> to bitmap anyway ...
        + caching that, needed anyway ...

    * render to texture ? ... [ more expensive ? ]

AI: how do others do OpenGL rendering with native windows controls.

* Framebufferobject:
    + texture - only good for 2D rendering
    + z buffer
    + no 3D methods natively in VCL.

* Markus: do it all with shaders ...
    + newer openGL don't have to accelerate the fixed pipeline
        + driver manufacturerers ...
    + implement our own line drawing etc.
        + give it 2x points ...

* Self-intersection / polygon winding an issue ...
    + stick to CPU unwinding for now ...

* Mirroring
    + not used for the virtual SalGraphics methods ...

    Involved: …

    Priority Main Loop

    Involved: jennifer.liebel@muenchen.de, tobias.madl@muenchen.de, florian.haftmann@informatik.tu-muenchen.de, …

    Main Loop

    XFastParser Promotion

    Code Pointers

    - include/sax/fastparser.hxx - oox/source/core/fastparser.cxx

    - wrapper for ::oox::core::FastParser
    - used in oox/source/docprop/ooxmldocpropimport.cxx

    - oox/source/crypto/DocumentDecryption.cxx

    - simple use-case, since AgileTokenHandler does not compute anything
    - except for startUnknownElement

    - writerfilter/source/ooxml/factoryimpl.py

    - generates workdir/CustomTarget/writerfilter/source/OOXMLFactory_generated.cxx
    - has OOXMLStreamImpl::getFastParser

    - interfaces are in offapi/com/sun/star/xml/sax

    - FastParser

    TODO

    - SvXMLImport: remove inheritance to XDocumentHandler
    - SvXMLImportContext: remove inheritance to XContextHandler
    - derived classes of SvXMLImportContext and SvXMLImport have to implement the new interfaces
    - replace all Parsers with FastParsers
    - finish performance unit-test (matus)

    DONE

    - SvXMLImport implements XFastDocumentHandler
    - SvXMLImportContext implements XFastContextHandler

    UnitTests

    There is one in sax/qa/cppunit/parser.cxx - but needs more love. I've added simple css::xml::sax::XFastTokenHandler implementation in 6503be5311716cf520cf534ca1bb0fd595b93d72

    What I think should be done there:

    1. We need a better, more complicated input
    2. Extend DummyTokenHandler to recognize some of the element/attribute strings used in the input.
    3. Implement simple XFastDocumentHandler and use setFastDocumentHandler() examples for this:
    - oox/source/crypto/DocumentDecryption.cxx
    - but we want to use tokens, not compare strings
    - unoxml/qa/unit/domtest.cxx
    - we don't build this, maybe we should, no idea how obsolete it is

    http://api.libreoffice.org/docs/idl/ref/interfacecom_1_1sun_1_1star_1_1xml_1_1sax_1_1XFastParser.html contains some description and there is also a link to a wiki with rather useful information.

    Involved: Daniel Sikeler

    Retrieved from "https://wiki.documentfoundation.org/index.php?title=Development/LHM_LiMux&oldid=109574"