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.
* 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 ...
Priority Main Loop
Involved: email@example.com, firstname.lastname@example.org, email@example.com, …
- include/sax/fastparser.hxx - oox/source/core/fastparser.cxx
- - wrapper for ::oox::core::FastParser
- - used in oox/source/docprop/ooxmldocpropimport.cxx
- - simple use-case, since AgileTokenHandler does not compute anything
- - except for startUnknownElement
- - generates workdir/CustomTarget/writerfilter/source/OOXMLFactory_generated.cxx
- - has OOXMLStreamImpl::getFastParser
- interfaces are in offapi/com/sun/star/xml/sax
- 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)
- SvXMLImport implements XFastDocumentHandler
- SvXMLImportContext implements XFastContextHandler
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