Development/LHM LiMux
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, …
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
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:
- We need a better, more complicated input
- Extend DummyTokenHandler to recognize some of the element/attribute strings used in the input.
- 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
- - oox/source/crypto/DocumentDecryption.cxx
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