Development/LHM LiMux

= OpenGL / VCL Rendering Backend =

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

+ 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
 * OpenGL SalGraphics magic

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

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

Un-structured notes

 * Simple OpenGL / VCL backend ...

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

+ 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 ?
 * Implement the salgdi virtual interface ...

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

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

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


 * OpenGL/ES -> render target.

+ 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
 * Markus:

+ 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.

+ very simple indeed ...
 * Basebmp ->

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

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

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

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

+ 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 ...
 * how does basegfx deal with Xor mode ...

- 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 ...
 * wrapping the GL API -> helps to wrap stuff

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


 * Target is Windows initially ...

+ 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.
 * problems:

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

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

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

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

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

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

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

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