Development/LHM LiMux

From The Document Foundation Wiki
Jump to: navigation, search

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