Difference between revisions of "DrawingPrimitives"

From Apache OpenOffice Wiki
Jump to: navigation, search
(Todo List)
 
(20 intermediate revisions by 3 users not shown)
Line 3: Line 3:
 
All three items will be addressed in [http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Id=3064&Path=SRC680%2Faw033 CWS aw033], and the means for that are DrawingPrimitives. The mental model for these primitives are metafiles or display lists, i.e. resolution-independent representation of renderable geometry. DrawingPrimitives define a hierarchy of increasingly simpler geometric primitives, starting with fairly high-level ones like customShapePrimitive or captionPrimitive, down to simple ones like polyPolygonColorPrimitive. The high-level primitives have built-in support for breaking them up into simpler ones, which makes implementing a renderer for DrawingPrimitives quite easy (in a first step, one has to provide only support for a small set of very basic primitives, like bitmap and polygon).
 
All three items will be addressed in [http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Id=3064&Path=SRC680%2Faw033 CWS aw033], and the means for that are DrawingPrimitives. The mental model for these primitives are metafiles or display lists, i.e. resolution-independent representation of renderable geometry. DrawingPrimitives define a hierarchy of increasingly simpler geometric primitives, starting with fairly high-level ones like customShapePrimitive or captionPrimitive, down to simple ones like polyPolygonColorPrimitive. The high-level primitives have built-in support for breaking them up into simpler ones, which makes implementing a renderer for DrawingPrimitives quite easy (in a first step, one has to provide only support for a small set of very basic primitives, like bitmap and polygon).
  
==Giving it a try==
+
==It's done!==
  
You can have a (preliminary) glance at how this works by building [http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Id=3064&Path=SRC680%2Faw033 CWS aw033] (follow the link for informations on which milestone this is currently based, and which modules are branched). You'll further need to checkout the new module drawinglayer from CVS.
+
All needed CWSes (aw024, awo33, aw059) are integrated in OOo 3.1 and AntiAliasing will be activated for all Systems and all OOo Applications for OOO 3.1. For a fast overview, You may read this blog entry ([http://blogs.sun.com/GullFOSS/entry/finally_anti_aliasing_is_done]) about it.
 +
I was busy with last adaptions and fixes for OOO 3.1 in the last time. There is still work to be done in follow-up projects, e.g. change SlideShow to primitive usage; change HitTest to use Primitives; change graphic object conversion to use primitives. Also all the exporters may use them now.
 +
All this may be done after 3.1; the version itself is fully functional with primitives and has already profited in many ways (AntiAliasing being only one aspect of them).
  
After the build is done, open up a Draw or Impress, insert some shapes, and toggle between old and new drawing layer via <Ctrl><Shift>-T (this already repaints the view, just like <Ctrl><Shift>-R).
 
  
Some code pointers:
+
I have to give a warning here: The rest of the text is pretty technical; it's more or less the protocol of changes done on the long migration task. AFAIK it's pretty up-to-date, but will not be updated anymore as often as during migration to OOo 3.1. It is still a good reading when You want to get an overview of primitives, their concept and their usage.
* drawinglayer/source/primitive for the basic primitives
+
* svx/source/sdr/primitive for the high-level (shape-equivalent) primitives
+
* svx/source/sdr/contact/objectcontactofpageview.cxx: DoProcessDisplay() for the main paint entry (and some funny flags)
+
  
==Using XCanvas as the backend renderer==
 
  
Having said all this, it's now fairly easy to have XCanvas used instead of OutputDevice. I've implemented a preliminary canvas renderer in drawinglayer/source/processor/canvasprocessor.cxx, which, when used, can finally display the Draw/Impress edit view anti-aliased:
+
When this will be continued, i will move the points in progress to tasks and also to new Wiki pages on OOo Wiki.
  
[http://blogs.sun.com/roller/resources/thorsten/shot0.png Screenshot]
+
==Giving it a try==
 +
 
 +
It's all in there :-), so when You want to try, get the latest OOo 3.1 developer release here [http://download.openoffice.org/680/index.html]
 +
 
 +
Some code pointers:
 +
* drawinglayer/source/primitive(2d|3d) for the basic 2D/3D primitives
 +
* drawinglayer/source/renderer(2d|3d)for the basic primitives
 +
* svx/source/sdr/primitive(2d/3d) for the high-level (shape-equivalent) primitives
 +
* svx/source/sdr/contact/objectcontactofpageview.cxx: DoProcessDisplay() for the main paint entry
 +
 
 +
==Using XCanvas as the backend renderer==
  
 +
There is a basic canvas-based primitive rendere included in the drawinglayer project and it can be used changing the static bool 'bTryTestCanvas' in createBaseProcessor2DFromOutputDevice() in svx/source/sdr/contact/objectcontacttools.cxx
  
 
== Primitives Implementation (aw033) in Detail ==
 
== Primitives Implementation (aw033) in Detail ==
Line 27: Line 35:
 
This excerpts describe explicitely some internas of the currently ongoing Primitives implementation in aw033. I will try to keep this up-to-date, maybe even get rid of my now used Writer-Document.
 
This excerpts describe explicitely some internas of the currently ongoing Primitives implementation in aw033. I will try to keep this up-to-date, maybe even get rid of my now used Writer-Document.
  
== Changes already done ==
+
== Changes already done (before starting this page) ==
  
 
Basic implementation is making good progress, so first an overview what is already achieved (without special order). This should give a good impression for the changes to expect and the work already done.
 
Basic implementation is making good progress, so first an overview what is already achieved (without special order). This should give a good impression for the changes to expect and the work already done.
Line 106: Line 114:
  
 
(38) Adaptions and fine tuning for SD, SC, SW and chart2 display.
 
(38) Adaptions and fine tuning for SD, SC, SW and chart2 display.
 
There is more stuff done, i will add as needed and relevant.
 
  
 
== CWS handling descriptions ==
 
== CWS handling descriptions ==
Line 141: Line 147:
  
 
Testing took a look at DEV300m12 version and did not found too many issues, time to resync to m21. As usual, some problems occurred, but i got the resync done in 3 days this time (why o why do i always find modules which cannot be butlt when buiding incompatible from basegfx/tools/drawinglayer?).
 
Testing took a look at DEV300m12 version and did not found too many issues, time to resync to m21. As usual, some problems occurred, but i got the resync done in 3 days this time (why o why do i always find modules which cannot be butlt when buiding incompatible from basegfx/tools/drawinglayer?).
 +
 +
Solved some problems QA told me about. To prepare giving aw033 to testing again, i will start a fresh resync to DEV300 m24. Started now...
  
 
== Transitions to primitives and stripping old code ==
 
== Transitions to primitives and stripping old code ==
Line 151: Line 159:
 
   Clearness: 1
 
   Clearness: 1
  
Todo: Started to check for DoPaintObject calls. Found some in SW which i need to replace first (see 'SW uses DoPaintObject calls ...'). I did two stripping runs in the meantime which revealed a list of strippable symbols (methods, parameters, values, etc) and lead to the problematic areas where work needs to be done.
+
Done: Started to check for DoPaintObject calls. Found some in SW which i need to replace first (see 'SW uses DoPaintObject calls ...'). I did two stripping runs in the meantime which revealed a list of strippable symbols (methods, parameters, values, etc) and lead to the problematic areas where work needs to be done.
  
 
-------
 
-------
Line 547: Line 555:
  
  
- Sometimes in AA mode, only when creating new objects, parts of the SnapLines stay on screen.
+
-- empty --
  
  
'''Done Hint List''': Things cleared
+
'''P2''': Open points from stripping
 +
  Candidate: AW, FS
 +
  Clearness: 1
  
 +
- Todo: MasterPageCaching with primitives
  
- Done: When starting a Slideshow with (F5), the first page is not shown. Looks like it gets fetched, but somehow not painted. This was because when simplifying the clippings from basegfx, i did a wrond adaption in slideshow. Thanks to THB for giving me the needed hints.
+
- Todo : AsynchGraphicLoadingEvent live
  
  
- Done: Pixel-resolution Bitmaps sometimes get scaled a little bit (only rare, but seems to happen. Need to control that, evtl. add a primitive for that purpose which decomposes centrally on bitmap pixel size and the given ViewTransformation to fet 1:1 pixel mappings. May also be the renderer, though. Re-checked but could not reproduce in current version. This is gone after reworking/optimizing the 2d scene decomposition (3D rendering) to consequent discrete resolution usage.
+
'''P2''': Evtl. THB will adapt slideshow early to primitives, this would make VCL MetaRenderer more simple (see above)
 +
  Candidate: AW/THB
 +
  TimeEffort: ?
 +
  Clearness: 1
  
 +
Changed candidate to AW since THB is not really available for this task.
  
- Done: Just for security: Check all the page number and master page visualisations of Impress again. Checked that and reworked the schema which is used for knowing the visualizing DrawPage (whichis not the current one when you think about MasetrPage content and/or page visualisation objects). Works well now.
+
Talked to THB recently (added again); he may try to get the time to do this. In the meantime we again and again stumbled over tasks/problems with SlideShow not using Primitives, so the arguments to do this get more and more.
  
  
- Done: Need to check if getRange() from 3d scene primitive might be implemented without using decomposition. Not only checked but reworked the getRange() get2DDecomposition() and createLocalDecomposition() to work more effective with discrete target coordinates. Also changed clipping against discrete ViewPort accordingly (on Metafile recording, there is no ViewPort set which means to always show everything)
+
'''P2''': Create a slideshow renderer for primitives. This would include to create a primitive renderer for canvas which will be a candidate to be used in the applications for DrawingLayer paints, too.
 +
  Candidate: AW
 +
  TimeEffort: ?
 +
  Clearness: 1
  
 +
Changed candidate to AW since THB is not really available for this task.
  
- Done: When combining polygons or objects which will be converted to polygons for being combined, straight line segments get converted to curve segments unnecessarily. Changing that.
+
This may be seen more general and not only for SlideShow; there is a possibility to improve rendering speeds by writing pure system-dependent renderers, e.g. a pure GDI+ renderer for windows residing in an own dll in drawinglayer project.
  
  
- Done: Sometimes when curve editing, a line (probably part of the overlay) to the null point is drawn. Found and resolved. The processing of the overlay striped polygon tried to produce polygons even with only one point. Changed that and secured the used tooling methods in basegfx.
+
'''P2''': Use the Canvas-PrimitiveRenderer to change DrawingLayer paints to use canvas directly instead of VCL. Also possible as example: A direct Windows (DirectX?) renderer support.
 +
  Candidate: AW
 +
  TimeEffort: ?
 +
  Clearness: 1
  
 +
Changed candidate to AW since THB and CL are not really available for this task.
  
- Done: Sometimes when scrolling the DrawingLayer view the repaint is one pixel to small in X or Y resulting in srolled but not repainted 'rests' in the right and bottom pixel lines. Need to check for integer/double conversions when calculating the repaint regions. May have been a problem with incompatible working environment, not seen anymore. Still checking. Could not reproduce in current version, still keeping an eye on it. Took a look again, could no longer reproduce.
+
Currently stalled; the primitive renderers all use the default VCL-Renderer. Implementation is done with some easy VCL extensions to support the needed AntiAliasing command on each system. This works pretty well since with a primitive renderer the subset of graphic commands used by the renderer is much better controllable as rendering using VCL (or beware: XOutputDevice :-)). This is sufficient for OOo 3.1, but there is room for enhancement, especially in 3D, too.
  
  
- Done: THB told me about a funny effect when text ends with '!'. Seems that there are exception handlings in EditEngine/Outliner to nove that sign to the front of the sentence ?!? Need to check this, does not happen in old mode. Checked again, could not reproduce. Need to ask THB. Asked THB, he said it was simple to reproduce. If i cannot reproduce, it probably is fixed with one of the other changes.
+
'''P3''': Rework OverlayObjects paint part to use primitives. Not urgently necessary, may work without primitives as it is now.
 +
  Candidate: AW
 +
  TimeEffort: ?
 +
  Clearness: 1
  
 +
Maybe not needed at all. Discussed once with THB who stated that there is no need to do so and it may even have advantages to stay on VCL and pixel base with overlays. Another possibility is to define a standardized embedding of view-independent primitives to view-dependent ones and thus to simply stay view-oriented with the overlay objects by using those. One advantage would be that the overlay objects would no longer need to implement a getRange() and the risk of doing thos wrong would be elliminated by using the sequence of primitives getRange() call.
  
- Done: Had to change back IsRTL() in one of the in-between stages of text decomposition (it was wrong). Need to check RTL-modes again. Checked, looks good.
+
Currently stalled and not needed for OOo 3.1. The current state is that i implemented a OverlayObject which uses a sequence of primitives as visualisation data. This object is used as a briding object between primitive visualisation and overlay. This is currently mainly used in the Full Drag feature for OOo 3.1. The result is that most of the interactive overlay (e.g. the drag lines, too) is rendered using primitives and a primitive renderer. This was needed to have the overlay AntiAliased in OOo 3.1, too.
  
 +
Still, there is plenty of room for enhancements here.
  
- Done: PDF export loses fillings (simple color ones). Debugged, but does happen in PDFWriter itself. Another sign that it's not the VCL MetaFileRenderer is that printing works flawlessly. Contacted PL. Found out that in filter/source/pdf/pdfexport.cxx when a META_COMMENT_ACTION uses the SvtGraphicFill, only the polygon is extracted but not the color. All other actions between XPATHFILL_SEQ_BEGIN and XPATHFILL_SEQ_END are skipped with one exception: the fill color. But the fill color is used AFTER the polygon was painted. I changed VclMetafileProcessor2D to first set Fill and LineCOlors, then to add the MetaFile comment action. Works. Will setup a task for SJ to change that in pdfexport.cxx.
 
 
 
'''P1''': Use VCL's DrawTransparent for polygons with unfied transparence instead of current Buffer-VDev usage. This may potentially speed up unified transparence paints.
 
  
 +
'''P3''': Tiling support for MetaFile renderer bitmap preparation for any-transparence filled primitive. Not urgently needed ATM since with currently created primitives this will never happen.
 
   Candidate: AW
 
   Candidate: AW
   TimeEffort: 4-7 Days
+
   TimeEffort: ?
 
   Clearness: 1
 
   Clearness: 1
  
Done: Added code to the VCL PixelProcessor to directly use OutputDevice::DrawTransparent when the UnifiedAlphaPrimitive2D contains exactly one primitive of type PolyPolygonColorPrimitive2D. This works well, but i cannot activate it since OutputDevice::DrawTransparent still uses the old tools::polygon definitions and thus will look ugly and maybe AA will not work.
 
  
Todo: Informed HDU that OutputDevice::DrawTransparent needs to be adapted to B2DPolyPolygon processing. He will evaluate if this is expensive or not. If he can adapt it, i need to change the default in VCL PixelRenderer to use OutputDevice::DrawTransparent directly (see static bAllowUsingDrawTransparent flag). HDU checked the possibilities and reports that it will take 2-3 working days to add the necessary stuff, probably after christmas. Until then i keep the option disabled. Worked today with HDU on this feature for some time, we tried to add it to VCL smoothly. Most of the stuff is in place, but even with setting the correct XRenderColor (with alpha) the result is smoothed but not transparent. HDU needs to do more investigation, but will be on holiday until next Year.
+
This List may not be complete, so Points will need to be added. If You have suggestions, feel free to contact me.
  
Todo: HDU still had no time to do this, preparations are committed in VCL pixel renderer.
+
== Done List ==
  
 +
Tasks which are done. These tasks are moved here from the Todo List from the section above.
  
'''P1''': Do some speed tests to identify bottlenecks
 
  Candidate: AW
 
  TimeEffort: 1 Week
 
  Clearness: 1
 
  
Done: Use a unxlngi6.pro version to do some scheduling for repaint times on a linux machine. Use valgrind,callgrind and kcachegrind. Made first speed tests. kcachegrind does not show any extremely bottlenecks what is good. Anyways it gives some suggestions, see todo's.
+
'''Done Hint List''': Things cleared (tasks moved from Hint List in the Todo chapter)
  
Done: Used the resynched and freshly build SRC680 m232 version for first tests. Committed all changes and rebuilding current version. Used that version for first valgrind tests.
 
  
Done: HDU made some good suggestions, ne is a specialized getRange() for B2DPolygon with curves. This would include to only decompose curve parts which are outside the bounds without control points. Good suggestion. Implemented and tested this, works well. Also reworked the extrema calculating method for bezier segments to make it more widely usable. Also change getRange() from basegfx polygon tooling to get the real bezier range by default and added a getRangeWithControlPoints() for the other case. Discussed and checked with THB, no cases known where getRangeWithControlPoints() is explicitely needed for now, thus this change is safe. Identifying all adaptiveSubdivideByAngle() calls which were just done due to getting the correct range from a bezier polygon and removing them. Due to the fact that i now use a real extrema calculation when a bezier overlaps the current range, we now get a range for beziers which is more precise than ever before.
+
- Done: Sometimes in AA mode, only when creating new objects, parts of the SnapLines stay on screen.
  
Done: HDUs hint: DrawPolyPolygon is too often called with tools::PolyPolygon which is not necessary anymore if a B2DPolygon is available. Needs to be checked. Ckecked this. No transitions to tools:Polygon are done in the VCL pixel renderer; need to debug this one. Checked this one, i found no more usages when primitive renderer is in place.
 
  
Done: Valgrind lead to buffering of dfault decomposition and range at the polygon which solved all performance stuff here. The most time consuming job now is the VCL PolyPolygon painting on X which needs to dismantle the polygons to trapezoids. Before this is done, all self-intersections need to be solved, too. This is the expensive part. Together with HDU we added a clipping against the visible parts so that a much smaller part of the polygons needs to be processed. I am really surprised that X can only render triangles/TriangleStripes and trapezoids when painting filled polygons..:-(
+
- Done: When starting a Slideshow with (F5), the first page is not shown. Looks like it gets fetched, but somehow not painted. This was because when simplifying the clippings from basegfx, i did a wrond adaption in slideshow. Thanks to THB for giving me the needed hints.
  
Done: HDUs hint: BitmapEx::Scale() and indirectly ImplScaleFast() is called too often and with nearly no scaling at all. Might be a slight numerical problem which leads to unnecessary scaling. Needs to be checked. Checked and does not happen anymore. Again adapted 3D scene decomposition to create an aligned bitmap which will not be scaled at render time but perfectly fits the target pixel region.
 
  
Done: Do more valgrind tests, interpret the results. A first possibility to enchance performance is to provide a default AdaptiveSubdivide for B2DPolygon which would be buffered at the polygon incarnation itself to avoid evtl. multiple decompositions. Added getDefaultAdaptiveSubdivision() directly to B2DPolygon, see description there.
+
- Done: Pixel-resolution Bitmaps sometimes get scaled a little bit (only rare, but seems to happen. Need to control that, evtl. add a primitive for that purpose which decomposes centrally on bitmap pixel size and the given ViewTransformation to fet 1:1 pixel mappings. May also be the renderer, though. Re-checked but could not reproduce in current version. This is gone after reworking/optimizing the 2d scene decomposition (3D rendering) to consequent discrete resolution usage.
  
Todo: Did some fresh callgrind checks on newest unxlngi6.pro build with and without AA activated. Pretty much the same when looking at basegfx and drawinglayer, no obvious differences. Main costs are now on isInside used by solving OR-operations on polygons (from VCL painting). Check/optimize isInside() eventually (solve isPointOnPolygon internally there?).
 
  
Todo: Ongoing tests with callgrind using the most current unxlngi6.pro version. No extremely visible bottlenecks encountered. Maybe getB2DRangeFromPrimitive2DSequence() calls should be buffered better; this means to locally buffer the calculated BoundRects more at the instances which use that call.
+
- Done: Just for security: Check all the page number and master page visualisations of Impress again. Checked that and reworked the schema which is used for knowing the visualizing DrawPage (whichis not the current one when you think about MasetrPage content and/or page visualisation objects). Works well now.
  
Todo: Page pane content is shown slower than on original version. I did some valgrind tests on unxlngi6.pro version, but couldn't identify something concrete. Need to look again on this.
 
  
 +
- Done: Need to check if getRange() from 3d scene primitive might be implemented without using decomposition. Not only checked but reworked the getRange() get2DDecomposition() and createLocalDecomposition() to work more effective with discrete target coordinates. Also changed clipping against discrete ViewPort accordingly (on Metafile recording, there is no ViewPort set which means to always show everything)
  
'''P2''': Test SW scrolling with many controls (was: CR 6673211)
+
 
  Candidate: AW, FS
+
- Done: When combining polygons or objects which will be converted to polygons for being combined, straight line segments get converted to curve segments unnecessarily. Changing that.
  Clearness: 1
+
 
 +
 
 +
- Done: Sometimes when curve editing, a line (probably part of the overlay) to the null point is drawn. Found and resolved. The processing of the overlay striped polygon tried to produce polygons even with only one point. Changed that and secured the used tooling methods in basegfx.
 +
 
 +
 
 +
- Done: Sometimes when scrolling the DrawingLayer view the repaint is one pixel to small in X or Y resulting in srolled but not repainted 'rests' in the right and bottom pixel lines. Need to check for integer/double conversions when calculating the repaint regions. May have been a problem with incompatible working environment, not seen anymore. Still checking. Could not reproduce in current version, still keeping an eye on it. Took a look again, could no longer reproduce.
 +
 
 +
 
 +
- Done: THB told me about a funny effect when text ends with '!'. Seems that there are exception handlings in EditEngine/Outliner to nove that sign to the front of the sentence ?!? Need to check this, does not happen in old mode. Checked again, could not reproduce. Need to ask THB. Asked THB, he said it was simple to reproduce. If i cannot reproduce, it probably is fixed with one of the other changes.
 +
 
 +
 
 +
- Done: Had to change back IsRTL() in one of the in-between stages of text decomposition (it was wrong). Need to check RTL-modes again. Checked, looks good.
 +
 
 +
 
 +
- Done: PDF export loses fillings (simple color ones). Debugged, but does happen in PDFWriter itself. Another sign that it's not the VCL MetaFileRenderer is that printing works flawlessly. Contacted PL. Found out that in filter/source/pdf/pdfexport.cxx when a META_COMMENT_ACTION uses the SvtGraphicFill, only the polygon is extracted but not the color. All other actions between XPATHFILL_SEQ_BEGIN and XPATHFILL_SEQ_END are skipped with one exception: the fill color. But the fill color is used AFTER the polygon was painted. I changed VclMetafileProcessor2D to first set Fill and LineCOlors, then to add the MetaFile comment action. Works. Will setup a task for SJ to change that in pdfexport.cxx.
  
  
Line 656: Line 687:
  
 
No longer needed with central RecalcBoundRect method. Stripped together with other no longer needed stuff.
 
No longer needed with central RecalcBoundRect method. Stripped together with other no longer needed stuff.
 
 
-Done/Todo: ImplGet3DLineGeometry->ImpGetShadowPolygon
 
 
 
-Done/Todo: Base3D removal (dialogs, etc)
 
 
 
-Done/Todo: Base3D removal : replace in dialogs (SvxPreviewCtl3D), also in VCL and goodies
 
 
 
-Done/Todo: SdrObject::ImpConvertToContourObj without CreateLinePoly to get rid of CreateLinePoly, SdrLineGeometry
 
 
Created a 2D renderer which extracts the line geometry; the thick expanded line one and the hairline one. Tested in ImpConvertToContourObj and it works well. Needed to extend the geometric DoConvertToPolyObj for SdrMeasureObj to also inherit the Stale settings to newly created objects. Thinking about getting rid of that geometry changing stuff and eventually do a conversion completely using primitive decompositions, so i keep this one on Todo.
 
  
  
Line 682: Line 699:
  
  
'''P2''': Open points from stripping
+
'''P2''': Unify RecalcBoundRect
  Candidate: AW, FS
+
  Clearness: 1
+
 
+
- Todo: MasterPageCaching with primitives
+
 
+
- Todo : AsynchGraphicLoadingEvent live
+
 
+
 
+
'''P2''': Evtl. THB will adapt slideshow early to primitives, this would make VCL MetaRenderer more simple (see above)
+
  Candidate: THB
+
  TimeEffort: ?
+
  Clearness: 1
+
 
+
 
+
'''P2''': Create a slideshow renderer for primitives. This would include to create a primitive renderer for canvas which will be a candidate to be used in the applications for DrawingLayer paints, too.
+
 
   Candidate: AW
 
   Candidate: AW
  TimeEffort: ?
 
 
   Clearness: 1
 
   Clearness: 1
  
Changed candidate to AW since THB is not really available for this task.
+
Done: BoundRect calculations are currently spread over the SdrObject model objects. With primitives, it is possible to centrally replace those calcualtions (and code used from them) by unifiedly implementing RecalcBoundRect. Had to change another two primitive creators which did not use direct model data for primitive creation but BoundRect data which of course leads to a loop in this case. Works like a charm now. Removed all crude RecalcBoundRect calculations and all associated stuff like extra sizes for text, etra sizes for beveled lines, extra stuff for 3D, etc. Also could remove the old line geometry creators completely now. Only one central implementation at SdrObject::RecalcBoundRect stays and does the job. Anyways, it stays virtual since objects derived from SdrVirtObj (e.g. SW objects) need to add some offset to the calcualted BoundRect.
  
  
'''P2''': Use the Canvas-PrimitiveRenderer to change DrawingLayer paints to use canvas directly instead of VCL. Also possible as example: A direct Windows (DirectX?) renderer support.
+
'''P2''': Remove 3D Point objects (Labels)
  Candidate: THB, AW
+
  TimeEffort: ?
+
  Clearness: 1
+
 
+
 
+
'''P3''': Rework OverlayObjects paint part to use primitives. Not urgently necessary, may work without primitives as it is now.
+
 
   Candidate: AW
 
   Candidate: AW
  TimeEffort: ?
 
 
   Clearness: 1
 
   Clearness: 1
  
Maybe not needed at all. Discussed once with THB who stated that there is no need to do so and it may even have advantages to stay on VCL and pixel base with overlays.
+
Done: The cahrt2 module no longer used SdrLabelObjects, so the last usage of 3D Point objects is gone. This allows removal of all those and also the extractor for the 2d primitive scene. Completely removed SdrPointObj and SdrLabelObj, their VCs and VOCs, the primitives for them and extra handlings in the 2D Scene3D primitives to create text primitives for existing label objects. Also removed the renderer which was used for filtering the labels.
  
  
'''P3''': Tiling support for MetaFile renderer bitmap preparation for any-transparence filled primitive. Not urgently needed ATM since with currently created primitives this will never happen.
+
'''P2''': Move 3D shadow creation to 3D object wrapper 2D objects
 
   Candidate: AW
 
   Candidate: AW
  TimeEffort: ?
 
 
   Clearness: 1
 
   Clearness: 1
  
 
+
Done: With the introduced 3D geometry information it gets possible to locally create that 2D shadow geometry for 3D objects at the 3D to 2D object wrappers. This is the more correct place and will allow removal of the currently used 3Dm shadow extractor. A extractor will still be needed, but just to collect the 2D shadow geometry (if it exists). It will also allow more central BoundRect calculations for 3D objects with shadow.
This List may not be complete, so Points will need to be added. If You have suggestions, feel free to contact me.
+
I could not completely move 2D shadow creation to the 3D primitives, but enhanced the 2Dto3DprimitiveWrapper to include the shadow, even when projected. The 3D shadow can be on/off and have different distances and can even be projected (see 3d properties). All this is taken care of using the same filtering 3D renderer the 2D Scene3D decompose uses. All together this embedding wrapper primitive for 3D allows to get a BoundRect in 2D for each SdrObj3D directly without the need to access the scene (and deal with 3D projections) in any way.
 
+
== Done List ==
+
 
+
Tasks which are done. These tasks are moved here from the Todo List from the section above.
+
  
  
Line 1,159: Line 1,148:
  
  
To be continued...
+
'''P1''': Use VCL's DrawTransparent for polygons with unfied transparence instead of current Buffer-VDev usage. This may potentially speed up unified transparence paints.
 +
 
 +
  Candidate: AW
 +
  TimeEffort: 4-7 Days
 +
  Clearness: 1
 +
 
 +
Done: Added code to the VCL PixelProcessor to directly use OutputDevice::DrawTransparent when the UnifiedAlphaPrimitive2D contains exactly one primitive of type PolyPolygonColorPrimitive2D. This works well, but i cannot activate it since OutputDevice::DrawTransparent still uses the old tools::polygon definitions and thus will look ugly and maybe AA will not work.
 +
 
 +
Done: Informed HDU that OutputDevice::DrawTransparent needs to be adapted to B2DPolyPolygon processing. He will evaluate if this is expensive or not. If he can adapt it, i need to change the default in VCL PixelRenderer to use OutputDevice::DrawTransparent directly (see static bAllowUsingDrawTransparent flag). HDU checked the possibilities and reports that it will take 2-3 working days to add the necessary stuff, probably after christmas. Until then i keep the option disabled. Worked today with HDU on this feature for some time, we tried to add it to VCL smoothly. Most of the stuff is in place, but even with setting the correct XRenderColor (with alpha) the result is smoothed but not transparent. HDU needs to do more investigation, but will be on holiday until next Year.
 +
Done now with aw063.
 +
 
 +
Done: HDU still had no time to do this, preparations are committed in VCL pixel renderer. Still HDU had no time (and also no X ATM). Done now in aw063; VCL supports basic transparence rendering for all systems now, and it is used by the renderers.
 +
 
 +
 
 +
'''P1''': Do some speed tests to identify bottlenecks
 +
  Candidate: AW
 +
  TimeEffort: 1 Week
 +
  Clearness: 1
 +
 
 +
Done: Use a unxlngi6.pro version to do some scheduling for repaint times on a linux machine. Use valgrind,callgrind and kcachegrind. Made first speed tests. kcachegrind does not show any extremely bottlenecks what is good. Anyways it gives some suggestions, see todo's.
 +
 
 +
Done: Used the resynched and freshly build SRC680 m232 version for first tests. Committed all changes and rebuilding current version. Used that version for first valgrind tests.
 +
 
 +
Done: HDU made some good suggestions, ne is a specialized getRange() for B2DPolygon with curves. This would include to only decompose curve parts which are outside the bounds without control points. Good suggestion. Implemented and tested this, works well. Also reworked the extrema calculating method for bezier segments to make it more widely usable. Also change getRange() from basegfx polygon tooling to get the real bezier range by default and added a getRangeWithControlPoints() for the other case. Discussed and checked with THB, no cases known where getRangeWithControlPoints() is explicitely needed for now, thus this change is safe. Identifying all adaptiveSubdivideByAngle() calls which were just done due to getting the correct range from a bezier polygon and removing them. Due to the fact that i now use a real extrema calculation when a bezier overlaps the current range, we now get a range for beziers which is more precise than ever before.
 +
 
 +
Done: HDUs hint: DrawPolyPolygon is too often called with tools::PolyPolygon which is not necessary anymore if a B2DPolygon is available. Needs to be checked. Ckecked this. No transitions to tools:Polygon are done in the VCL pixel renderer; need to debug this one. Checked this one, i found no more usages when primitive renderer is in place.
 +
 
 +
Done: Valgrind lead to buffering of dfault decomposition and range at the polygon which solved all performance stuff here. The most time consuming job now is the VCL PolyPolygon painting on X which needs to dismantle the polygons to trapezoids. Before this is done, all self-intersections need to be solved, too. This is the expensive part. Together with HDU we added a clipping against the visible parts so that a much smaller part of the polygons needs to be processed. I am really surprised that X can only render triangles/TriangleStripes and trapezoids when painting filled polygons..:-(
 +
 
 +
Done: HDUs hint: BitmapEx::Scale() and indirectly ImplScaleFast() is called too often and with nearly no scaling at all. Might be a slight numerical problem which leads to unnecessary scaling. Needs to be checked. Checked and does not happen anymore. Again adapted 3D scene decomposition to create an aligned bitmap which will not be scaled at render time but perfectly fits the target pixel region.
 +
 
 +
Done: Do more valgrind tests, interpret the results. A first possibility to enchance performance is to provide a default AdaptiveSubdivide for B2DPolygon which would be buffered at the polygon incarnation itself to avoid evtl. multiple decompositions. Added getDefaultAdaptiveSubdivision() directly to B2DPolygon, see description there.
 +
 
 +
Done: Page pane content is shown slower than on original version. I did some valgrind tests on unxlngi6.pro version, but couldn't identify something concrete. Need to look again on this. Found reason, it is a conflict between primitive sequence usage and current frefresh using ModelChange events and completely rebuilding PagePane view. Currently solved this with staying at the ModelChange method. Added a deelp description to SLSPageObjectViewObjectContact.cxx in Sd and discussed with AF that we will need to solve this more general after aw033 integration.
 +
 
 +
Done: Did some fresh callgrind checks on newest unxlngi6.pro build with and without AA activated. Pretty much the same when looking at basegfx and drawinglayer, no obvious differences. Main costs are now on isInside used by solving OR-operations on polygons (from VCL painting). Check/optimize isInside() eventually (solve isPointOnPolygon internally there?). Again tested on the new m12 and looks good.
 +
 
 +
Done: Ongoing tests with callgrind using the most current unxlngi6.pro version. No extremely visible bottlenecks encountered. Maybe getB2DRangeFromPrimitive2DSequence() calls should be buffered better; this means to locally buffer the calculated BoundRects more at the instances which use that call. Changed to buffering B2DRange creation as fix in aw063.
 +
 
 +
 
 +
'''P2''': Remove XOutputDevice
 +
  Candidate: AW
 +
  TimeEffort: 1 Week
 +
  Clearness: 1
 +
 
 +
Done: Time to completely remove the XOutputDevice from svx (which did all the old rendering stuff/hacks in a similar manner to VCL). Needed to remove last usages of XOutputDevice from Dialogs (used as previews for fill, hatch and similar stuff). Needed to remove usage from StyleLists (LineStyle, FillStyle, Gradient list, etc). Needed to remove in SD from PageNumber dialog preview. All removals checked and tested for their correct optical representation. XOutputDvice completely removed! Yippieh!
 +
 
 +
 
 +
'''P2''': Remove OC's, VOC's and VC's PrepareDelete()
 +
  Candidate: AW
 +
  TimeEffort: 1 Week
 +
  Clearness: 1
 +
 
 +
Done: Cleanup and siplification of the ViewObjectContact mechanism. After first simplifications there was no reason left for the used PrepareDelete() method at VOCs (ViewObjectContacts), VCs (ViewContacts) and OCs (ObjectContacts). It was primarily used as pre-destructors as virtual functions to not run into the officcial destructrors' weakness to not be able to call local virtual functions. Removed and migrated all PrepareDelete()s to the destructors. At some places PrepareDelete was used to flush the current incarnations of all VOCs for a VC, replaced this with the possibility to flush (delete, these objects are created-on-demand anyways) the current incranation of a VC at the corresponding model objects (Page, MasterPage and SdrObject). PrepareDelete() comletely removed.
 +
 
 +
 
 +
'''P2''': Test SW scrolling with many controls (was: CR 6673211)
 +
  Candidate: AW, FS
 +
  Clearness: 1
 +
 
 +
 
 +
Done: This is a after-integration task. Checked, works well.
 +
'''P2''': Stuff from stripping moved to Done/Todo later
 +
  Candidate: AW, FS
 +
  Clearness: 1
 +
 
 +
-Done: ImplGet3DLineGeometry->ImpGetShadowPolygon -> CWS aw059
 +
 
 +
-Done: Base3D removal (dialogs, etc) -> CWS aw059
 +
 
 +
-Done: Base3D removal : replace in dialogs (SvxPreviewCtl3D), also in VCL and goodies
 +
 
 +
-Done: SdrObject::ImpConvertToContourObj without CreateLinePoly to get rid of CreateLinePoly, SdrLineGeometry
 +
 
 +
Created a 2D renderer which extracts the line geometry; the thick expanded line one and the hairline one. Tested in ImpConvertToContourObj and it works well. Needed to extend the geometric DoConvertToPolyObj for SdrMeasureObj to also inherit the Stale settings to newly created objects. Thinking about getting rid of that geometry changing stuff and eventually do a conversion completely using primitive decompositions, so i keep this one on Todo.
 +
Done now in CWS aw059. Still not completely on primitives, but preparations are done.
 +
 
 +
[[Category:Draw]]

Latest revision as of 09:48, 24 February 2010

The DrawingLayer, i.e. the engine providing the Draw/Impress content, which is reused in both Calc and Writer, currently undergoes substantial refactoring. This rework takes place in CWS aw033 (and partially in CWS aw024). Although the DrawingLayer was already usable as an engine, it had several shortcomings, among them no clear distinction between model and view (all model objects handled the viewing of their content themselves), lacking separation of concerns (lots of generally useful functionality was buried in the DrawingLayer code, instead of separated out into tooling libraries), and a hard-to-remove dependency on VCL's OutputDevice for rendering.

All three items will be addressed in CWS aw033, and the means for that are DrawingPrimitives. The mental model for these primitives are metafiles or display lists, i.e. resolution-independent representation of renderable geometry. DrawingPrimitives define a hierarchy of increasingly simpler geometric primitives, starting with fairly high-level ones like customShapePrimitive or captionPrimitive, down to simple ones like polyPolygonColorPrimitive. The high-level primitives have built-in support for breaking them up into simpler ones, which makes implementing a renderer for DrawingPrimitives quite easy (in a first step, one has to provide only support for a small set of very basic primitives, like bitmap and polygon).

It's done!

All needed CWSes (aw024, awo33, aw059) are integrated in OOo 3.1 and AntiAliasing will be activated for all Systems and all OOo Applications for OOO 3.1. For a fast overview, You may read this blog entry ([1]) about it. I was busy with last adaptions and fixes for OOO 3.1 in the last time. There is still work to be done in follow-up projects, e.g. change SlideShow to primitive usage; change HitTest to use Primitives; change graphic object conversion to use primitives. Also all the exporters may use them now. All this may be done after 3.1; the version itself is fully functional with primitives and has already profited in many ways (AntiAliasing being only one aspect of them).


I have to give a warning here: The rest of the text is pretty technical; it's more or less the protocol of changes done on the long migration task. AFAIK it's pretty up-to-date, but will not be updated anymore as often as during migration to OOo 3.1. It is still a good reading when You want to get an overview of primitives, their concept and their usage.


When this will be continued, i will move the points in progress to tasks and also to new Wiki pages on OOo Wiki.

Giving it a try

It's all in there :-), so when You want to try, get the latest OOo 3.1 developer release here [2]

Some code pointers:

  • drawinglayer/source/primitive(2d|3d) for the basic 2D/3D primitives
  • drawinglayer/source/renderer(2d|3d)for the basic primitives
  • svx/source/sdr/primitive(2d/3d) for the high-level (shape-equivalent) primitives
  • svx/source/sdr/contact/objectcontactofpageview.cxx: DoProcessDisplay() for the main paint entry

Using XCanvas as the backend renderer

There is a basic canvas-based primitive rendere included in the drawinglayer project and it can be used changing the static bool 'bTryTestCanvas' in createBaseProcessor2DFromOutputDevice() in svx/source/sdr/contact/objectcontacttools.cxx

Primitives Implementation (aw033) in Detail

To keep You up-to-date and allow a deeper understanding of the mentioned Primitives and their intended functionality, i will add excerpts from a paper i wrote to document changes and ToDo's. This is separated in the changes done before staring that paper, some CWS handling descriptions, a ToDo-List and the points moved to the done list. All the text should give an internal View of what Primitives are, how they work and what can be achieved using them. After You have read this parts, You will have an overview what Primitives are about. This excerpts describe explicitely some internas of the currently ongoing Primitives implementation in aw033. I will try to keep this up-to-date, maybe even get rid of my now used Writer-Document.

Changes already done (before starting this page)

Basic implementation is making good progress, so first an overview what is already achieved (without special order). This should give a good impression for the changes to expect and the work already done.

(1) Drawinglayer project created, integrated in installation, containing basic implementations for 2D and 3D primitives, 2D and 3D renderers and 2D/ 3D toolings

(2) API for 2D and 3D primitives created, discussed with diverse people (THB, CL, AF, SB) and adapted whole implementations changed to use it.

(3) API for PrimitiveFactory created which allows to get a PrimitiveSequence from a xShape or xDrawPage, implemented. Also discussed (see above).

(4) API for Primitive2DParameters and Primitive3DParameters created, used to define a whole ViewSituation. This combines ViewTransformation, ViewRange and PointInTime (for animations).

(5) 3D primitives and 3D renderer completely implemented, primitives for all used 3D objects in Drawinglayer and chart2 are working. Some special objects like 3D text labels from chart2 (position in 3D, text in 2D) needed to be added. This was easy and shows how nice such things can be done with primitives in the future.

(6) Important: Chart2 3D looks good with new 3D default renderer, it's faster, too. Needed some small adaptions, works well.

(7) 3D primitives uses 19 primitive implementations in drawinglayer, from which 10 have a decomposition (renderer needs to support the rest ATM, for details ask or look at the code). Example: Thick lines in 3D now decompose to the appropriate surface geometry; also line joints are now supported in 3D (this would have been very complicated in the old methodology).

(8) 3D renderer supports all features the current 3D engine does, but is faster and expandable. Also a 3D renderer for OpenGL or other 3D libs – on systems which support that – is possible for the future. Default is that the default 2d renderer uses the default 3D software renderer.

(9) 2D primitives have 37 implementations in drawinglayer for the most common things, svx adds 13 higher-level primitives which all can be decomposed. All primitive implementations support resolution-independent highest implementations. This allows to create those highest primitives just once for one xShape and decompose it view-dependent if necessary. If the decomposition is not view-dependent, it will be completely reused for all views where it is rendered. This will include e.g. printing but also geometric oriented exports like SVG (when these will be changed to use primitives) and internal renderers for creating Metafiles or Bitmaps.

(10) Since the primitives themselves are resolution-independent, we are able to create a whole view-independent render description using a primitive sequence. This includes 3D. Thus, in the future, e.g. own OLEs no longer have to use Metafiles but can use a sequence of primitives. Since this is view-independent, an deactivated chart2 will be rendered with the same quality, activated or not.

(11) Special 2D primitives exist for Caption, Customshape, Graph, OLE, FormControl and Media objects, thus renderers may support them directly. All can be decomposed correctly (so they may be supported, but do not have to).

(12) View-dependent and view-independent data is completely separated by the primitives and their decompositions. The current primitive implementaion itself contains and buffers it's decomposition. The curent implementation can be seen as one possible implementation for the primitive API, thus other implementation may handle this differently.

(13) The decomposition may be dependent from the ViewInformation feeded to the decomposer. If it is dependent (e.g. 3D scene creates pixels in needed resolution), it just can remember the ViewInformation (or needed parts) to decide for reuse at the next decompose call.

(14) All implementations are based on and use now com::sun::star::uno::Sequence< com::sun::star::uno::Reference< com::sun::star::graphic::XPrimitive2D >> resp. same for 3D API definitions.

(15) Tooling classes in te drawinglayer project exist which make working with primitives easier, especially decomposition. There is also tooling in svx for helping with primitive creation for ItemSet parmater extraction directly.

(16) 2D and 3D are completely separated, in API and Implementation.

(17) There exist a clean coordinate system embedding from 3D primitives into 2D primitives including the isolated 3D transformation pipeline from the scene to get the 2D outline from 3D objects if needed (to get their correct 2D ranges (outlines) for invalidates).

(18) A basic renderer implementation for 2D and 3D exists, still every user may produce it's own. Currently existing renderers are all based on that basic renderer class definition. The default renderers and it's class definition may get the API-base if we need renderers in API notation one day.

(19) The simplest 2D and 3D renderers are collecting renderers which just add all feeded primitives to an internal PrimitiveSequence. That way, all mechanisms using renderers (e.g. passing a created renderer through the DrawHierarchy of VOCs) can also be used to not only render, but collect primitive data (PrimitiveCollector).

(20) There is a color modify primitive which is used e.g. to make object shadow unified color or to visualize entered groups (all other stuff gets blended to white 50%). This is the base for – if it gets necessary – implement the crudest OutputDevice modes if needed. This also guarantees the same geometry and visualisation for the shadow of an object which is not the case today. Also to be mentioned: Since the shadow primitive itself contains the shadow transformation (read: offset) and references the contained geometry as sequelce of primitives, this is another case where the primitives and their evtl. decompositions are completele shared using the UNO API refcounted objects.

(21) The VCL 2D pixel rendererer (using VCL) can render everything which is needed today for screen visualisation, including selection special stuff, animations and others.

(22) The API for 2D/3D primitives is minimal by purpose (just two commands). When after a first installation it cristallizes which basic primitives are needed (have no decompose), those may get APIs of their own including value transport (e.g. Polygon data, colors, etc.). For the first incarnation this is by purpose not done (to keep flexible). Instead, the renderers use RTTI ATM.

(23) The 3D renderer uses the old color ranges directly as mathematical textures (don't ask, was hard since these are non-linear and were defined in the old days based on pixel stuff), so he is resolution-independent in it's texture granularity.

(24) Text primitive is splitted in SimpleTextPrimitive and DecoratedTextPrimitive (thenks HDU for some help there). DecoratedTextPrimitive is directly supported by VCL renderers, but also can be decomposed to SimpleTextPrimitive and extra stuff like underline, strikethrough, text shadow, etc.

(25) 2D display with primities is already smoothed in the current implementation in the linux version and more correct then before; we have shadows of object text for the first time and shadow not "adding" itself when transparent at overlapping thick line and object fill. I will provide more such examples if needed.

(26) Changed MarkerPrimitives to MarkerArrayPrimitives for performance reasons, single markers were too expensive (think how much markers make up a grid decomposition)

(27) Added PointArrayPrimitive and decompositions for MarkerArrayPrimitives, thus a renderer may or may not support markers (like the crosses at grids, the gluepoints and the handles later). It is also possible to support just some markers directly.

(28) Grid painting directly supported with grid primitive; decomposes to MarkerArrayPrimitives.

(29) Complete animation support for primitives using animated primitives which encapsulate the to-be-animated object as a sequence and the animation in unified, defined AnimationEntry also defined in DrawingLayer.

(30) Animations from xShapes (the old DrawingLayer ones) are now unified; support for text animations and GIFs implemented (all old stuff replacable), also free animations like linear interpolation between two transformations implemented. This is now e.g. used for scrolling text back and forth. This is the base for also animate all kinds of Draw objects if needed in the future.

(31) When scrolling text back and forth, we now - for the first time ever - correctly clip the text at the shape outline.

(32) Animation is now securely the same everywhere and simple to support (remember the effort to implement the current state in the diashow module?). Since now everyone (the creator and the animator, maybe later the diashow) use the same description and the description just influences the decomposition of the content providing the point in time, a renderer does not even need to know about animations, it will just do the right thing for a point in time. Just use the decomposition what means: Do nothing.

(33) The ViewObjectContact (VOC)/ ObjectContact (OC)/ ViewContact(VC) fully implements and supports primitive creation. This will allow removal of all DoPaintObject methods and their old tooling like the XOutputDevice in svx.

(34) At VC level, the view-independent PrimitiveSequence (and thus it's decomposition) is buffered and thus shared with each user (thanks to UNO API). Since the basic primitive is always intended to be simple and can be created fast and cheap (no decompositions, just extraction of paint-relevant parameters from xShape) checking for change can be done directly by incarnating a primitive, comparing with the current one and – if not equal - use the new one and invalidate using the old one.

(35) At VOC level, the view-dependent PrimitiveSequence (and thus it's decomposition) is buffered the same way as at the VC level. Both implementations may be overloaded at VOC/VC as needed (and are for some cases).

(36) Animations are detected at VC-Level. This avoids common errors when animating another xShape. The detection is only done when a new PrimitiveSequence is used (of course).

(37) OC and VOC implementations widely expanded to support PrimitiveSequence creations. Svx contains now 27 (master uses 13) VC implementations and 12 (master uses 3) VOC implementations. SD also uses some specialized ones. This greatly simplifies MasterPage handling and all those exceptions there regarding the DrawHierarchy (draw page or not, grid in front of or behind objects, helplines – and if yes – visible or not, etc...).

(38) Adaptions and fine tuning for SD, SC, SW and chart2 display.

CWS handling descriptions

A overview of problems which showed up in working on the CWS aw033 until now. This is a good example for a long-lastingand big CWS (created on SRC680 m130 and resynched already 10 times, see the link to aw033).

In the CWS history, You can see that this CWS is resynched 10 times already; when You think about resync times of 4-5 days (lot of conflicts, global header moves, changes for warning free code, removed projects, ...), the time to invest here is not trivial. Nonetheless, when time occurr where i cannot work on the CWS and i need to resync, that time needs to be invested since the versions on the build repository are not living too long nowadays. At the last resync, i needed 3-4 extra-days to work around an compiler-error in wntmsci10 which happened in SW and SD due to precompiled headers. Things like that are impredictable in their time effort.

I need to build incompatible from basegfx and tools, this means 99 projects when preparing the build. Since i need wntmsci10 and one unix (mostly unxlngi6) for development for HDU and others, i do not only need to build, but also need to copy back wntmsci10 output trees to the cws server for common work. When You follow discussion groups, this is error-prone, too.

After every resync there are unavoidable and undetected changes/errors which lead to display changes. After each resync 2-3 debugging days are needed to get everything completely working again.

All development changes done for SCH are lost. This is good to no longer need to support it, but very sad when i think about the work time spent there.

The last resync to SRC680 m232 went relatively smooth. Well, CVS had some problems. The 2nd resync step came back (after running through the night) with 353 failures, but i could just start it once again and it went better. Conflicts of step 1 were not too hard this time. I built wntmsci10 and unxlngi6. Both run, the latter needed changes from HDU. Started wntmsci10.pro build and unxlngi6.pro build for performance tests/measurements. Prepared work environment with basegfx, drawinglayer, svx and sd with debug. Ready to rumble again...

Resynched to m238 since m232 slowly running out. This time it worked better, in only two days i completed the whole resync (22 projects) and builds are nearly done. Lesser conflicts than in earlier resyncs.

Resynching to SRC680 m244 since m238 will soon be removed. Committed all stripping stuff. The resync itself went not too bad (2 days), but the move to wntmsci11 needed some fine tuning. Preparing work version with wntmsci11.

Resynching to SRC680 m246. Main reason is that CL did some visualisation changes in SD for PageObject visualisations which need to be adapted to primitives. It makes no sense to test aw033 when this change is not refrected already.

Resync is done, went relatively smooth. Working version is running, compiling with debug right now. Also used callgrind on unxlngi6.pro version, looks well. Unfortunately CL told me that he was wrong and that his changes are not yet integrated in m246, so i will have to resync soon again.

CL's changes are in the DEV300 m3, so he will this time do the resync to it (thanks and Kudos to CL). Resync is done, working version is back. In the meantime i fixed the Chart display problems. Merged into the new resync state and committed. Works as expected. Needed some time to copy the changes to the local environment in n: to my local machine, though... Let's hope that this time all to-be-adapted stuff is in the current version and that no resync needs to be done soon (CL had quite some work with it...).

Resynched to DEV300 m12 done, needed some days again to adapt everything.

All major problems solved, unxlngi6.pro and wntmsci12.pro updated. Sent a first version to testing for automatic tests. This will bring up some issues (with this huge changes) which will give me good hints for missing/overseen things hopefully.

Testing took a look at DEV300m12 version and did not found too many issues, time to resync to m21. As usual, some problems occurred, but i got the resync done in 3 days this time (why o why do i always find modules which cannot be butlt when buiding incompatible from basegfx/tools/drawinglayer?).

Solved some problems QA told me about. To prepare giving aw033 to testing again, i will start a fresh resync to DEV300 m24. Started now...

Transitions to primitives and stripping old code

This was part ofthe Todo List. Made an own point since it is a huge work with several sub-tasks. To keep an overview about it's sub-tasks, i make it an own main chapter.

P1: Remove all no more needed stuff, the complete DoPaintObject stuff and all involved; the ExtendedOutputDevice and its problems, much potential.

 Candidate: AW
 TimeEffort: 4-6 Weeks
 Clearness: 1

Done: Started to check for DoPaintObject calls. Found some in SW which i need to replace first (see 'SW uses DoPaintObject calls ...'). I did two stripping runs in the meantime which revealed a list of strippable symbols (methods, parameters, values, etc) and lead to the problematic areas where work needs to be done.


Stripped symbol list first run:


(PaintObjectAndHierarchy, isPrimitiveTest, mbPrimitiveTest, primitiveTest, CheckForAnimationFeatures, GetAnimationState, DeleteAnimationState, mpAnimationInfo, AnimationInfo, AInfoGraphic, GraphicMixer, AInfoDummy, AInfoBlinkText, AInfoScrollText, meRememberedAnimationKind, SupportsAnimation, PaintObjectAtTime, ScrollTextAnimNode, AInfoMixer, BasicMixer, ColorChangeMixer, CreateBasicMixer, AnimationState, ObjectAnimator, GetObjectAnimator, mpObjectAnimator, RemoveAnimationState, AddAnimationState, mpAnimationState, HasAnimationState, CreateObjectAnimator, HasObjectAnimator, DeleteObjectAnimator, namespace animation, AnimationEntryList, AnimationStateVector, CheckAnimationFeatures, GetAnimationInfo, SdAnimationInfo, CreateAnimationInfo, HasAnimationInfo, DeleteAnimationInfo, CreateAnimationState, rAnimator, PRIMITIVE_TEST, PaintHierarchy, PaintObject, BufferHelper, VOCBitmapBuffer, OfferBufferedData, RequestBufferedData, VOCOfMasterPageDescriptor, ViewContactOfMasterPageDescriptor::CreateObjectSpecificViewObjectContact, BufferHelperBitmap, BufferHelperBitmapEx, PaintReplacementObject, TRG_GetMasterPageVisibleLayers, PaintBackgroundObject, PaintBackgroundObjectWithItemSet, ShouldPaintObject, PaintGluePoints isMasterPageBackgroundVisibleOnLayerSet, checkMediaWindowPosition, DoDraftForCalc, positionControlForPaint, GetParentContact, doPaintObject, PaintGraphicDraft, PaintGraphicPresObj, DoPaintGraphicDraft, PaintShadowedFrame, PaintDraftBitmap, PaintDraftText, PaintCalcDraftObject, PaintPageContents, PaintPageReplacement, PaintPageBorder, PreparePagePainter, GetRidOfPagePainter, mpPagePainter, mbIsPainting, mbIsInActionChange, ViewContactOfPageObj::StopGettingViewed, OCOfPageObjPagePainter, StopGettingViewed, GetExtendedOutputDevice, SetExtendedOutputDevice, mpExtOutputDevice, GetPaintInfoRec, SetPaintInfoRec, mpPaintInfoRec, ImpCreateNewPageInfoRec, LocalPaint3D, DrawPolySceneClip, SetBase3DParams, ImpSet3DParForFill, ImpSet3DParForLine, E3D_DRAWFLAG_FILLED, E3D_DRAWFLAG_OUTLINE, E3D_DRAWFLAG_TRANSPARENT, E3D_DRAWFLAG_GHOSTED, Paint3D, SetBase3DParams, DrawAllShadows, DrawShadows, ImpDrawShadowPolygon, GetShadowColor, GetShadowTransparence, DrawShadowAsOutline, GetShadowXDistance, GetShadowYDistance, DoDrawShadow DrawWireframe, DrawObjectWireframe, ImpGetShadowPolygon, ImplGet3DLineGeometry, InitTransformationSet, ImpTakeContour3D, DrawWireframe, DrawAllShadows DrawPolySceneClip, DrawMarkedObj, SdrObject::SingleObjectPainter, GetLightGroup, GetPaintInfoRec, CopyPaintFlagsToChilds, CopyPaintFlagsFromParent, PaintReplacementObject, DoPaintGraphicDraft, PaintGraphicPresObj, PaintGraphicDraft, PaintBackgroundObject, SetViewObjectContactRedirector, PaintPageReplacement, PaintPageContents, PaintPageBorder, GetSdrObjectFromCustomShape, ImplForceGroupWithText, GetSdrObjectShadowFromCustomShape, mbSpecialTextBoxShadow, DoPaintObject, ImpDoPaintGrafObjShadow, GetTransformedGraphic, ImpDoPaintGrafObj, ImpDoPaintRectObjShadow, ImpDoPaintRectObj, ImpPrepareLineGeometry, ImpDrawShadowLineGeometry, ImpDrawColorLineGeometry, ImpDrawLineGeometry, CreateLinePoly, SdrLineGeometry, mpSetShadowAttributes PaintNeedsXPolyCirc, ImpCalcXPolyCirc, DrawGraphic, PaintGraphic_Impl, GetTextScrollMetaFileAndRectangle, UpdateOutlinerFormatting, mpSetupDrawOutlinerForPaint, ImpGetDrawOutliner, IsContourTextFrame, IsFontwork, ImpTextPortionHandler, PaintGluePoints, DoPaintForCalc, DrawPageViewGrid, SdrHelpLineList::DrawAll, setStateFlags, checkMediaWindowPosition, PaintLockAccessControl, enterPaint, leavePaint, m_nPaintLevel, initPaint, ImpTryToCreateBuffer, TryToPaintObjectWithBuffer, setStateFlags, RequestBufferedData, SetBufferedData, PageNotificationObjectContact, PaintContent, PaintPreview, PaintFrame, PaintBorder, PaintSelectionIndicator, PaintMouseOverEffect, PaintFocusIndicator, PaintDottedRectangle, PaintFadeEffectIndicator, PaintPageName, PaintPageNumber, ViewContactOfSdrObj::ActionChanged, Base3D, namespace mixer)


Stripped symbol list second run:


N ProcessDisplay, R PaintHierarchy, R PaintObjectAndHierarchy, R ShouldPaintObject, N GetControlLayerPainting, R checkMediaWindowPosition, N GetControlLayerPainting, N positionControlForPaint, N getMasterPageBackgroundCandidate, R PaintBackgroundObject, R PaintBackgroundObjectWithItemSet, N doPaintObject, R PaintObjectAtTime, R GetBasicMixer, R CreateBasicMixer, R ScrollTextAnimNode, R AInfoBlinkText, R AInfoScrollText, R AInfoDummy, R AInfoGraphic, R AInfoMixer, R HasObjectAnimator, R GetAnimationState, R ObjectAnimator, R SupportsAnimation, R CheckForAnimationFeatures, R mpObjectAnimator, R CreateObjectAnimator, R mpAnimationInfo, R GetObjectAnimator, R DeleteObjectAnimator, R DeleteAnimationState, R HasAnimationState, N SetAnimationTimer, R AnimationInfo, R AnimationState, R CheckAnimationFeatures, R HasAnimationInfo, R DeleteAnimationInfo, R AnimationInfo, R CreateAnimationInfo, R DeleteAnimationState, R CheckForAnimationFeatures, R GetAnimationInfo -> OOps, used in SD, too, but other method, R GetObjectAnimator, R BasicMixer, R ColorChangeMixer, R GraphicMixer, R TextScrollMixer, R TextBlinkMixer, R BasicMixer, R PaintObjectAtTime, R CopyPaintFlagsToChilds, R CopyPaintFlagsFromParent, R PaintReplacementObject, R PaintCalcDraftObject, R ImpPrepareForPaint, R DoAsynchGraphicLoading, R ForgetAsynchGraphicLoadingEvent, R AsynchGraphicLoadingEvent, R PaintGraphicDraft, R PaintGraphicPresObj, R DoPaintGraphicDraft, N StopGettingViewed, R mpAsynchLoadEvent, R DrawGraphic -> OOps, in SW, too, but other method, R PaintShadowedFrame, R PaintDraftText, R PaintDraftBitmap, R PaintGraphicPresObj, R PaintGraphicDraft, R CheckAnimationFeatures, R PaintHierarchy, R PaintReplacementObject, R PaintBackgroundObject, N PaintIt, R PaintPageContents, R PaintPageReplacement, R PaintPageBorder, N getMasterPageBackgroundCandidate, N TRG_GetMasterPageVisibleLayers, R PaintBackgroundObjectWithItemSet, N DrawPageViewGrid -> SC, SW, R PaintGluePoints, R SdrHelpLineList::DrawAll, R SdrGluePointList::DrawAll, R ImpDrawDashedTwoColorLine, R SdrHelpLine::Draw, R HasAnimationState, R AnimationInfo, R ObjectAnimator, R GetObjectAnimator, R PaintObjectAtTime, N setStateFlags, R PaintGluePoints, R PaintObjectAndHierarchy, R checkMediaWindowPosition, R m_nPaintLevel, R enterPaint, R leavePaint, R PaintLock, R PaintLockAccessControl, R initPaint, R doPaintObject, R BufferHelper, R VOCBitmapBuffer, R VOCBitmapExBuffer, R RequestBufferedData, R SetBufferedData, R BasicMixer, R SetupObject, R RestoreObject, R ImplLocalRedirector, N EnsureValidDrawHierarchy, N PageNotificationObjectContact, R PaintPreview, R PaintFrame, R PaintBorder, R PaintSelectionIndicator, N PaintMouseOverEffect, R PaintFocusIndicator, R PaintFadeEffectIndicator, R PaintPageName, R PaintPageNumber, R PaintContent, N GetParentContact, R PaintObject, R PaintHierarchy, R PaintGraphicDraft, R PaintGraphicPresObj, R PaintBackgroundObject, N GetSdrObjectFromCustomShape, N GetSdrObjectShadowFromCustomShape, R ImpDoPaintGrafObjShadow, N GetTransformedGraphic, R ImpDoPaintGrafObj, R ImpDoPaintRectObjShadow, R ImpSetShadowAttributes, R ImpDrawShadowLineGeometry, R ImpDrawColorLineGeometry, R ImpDrawLineGeometry, R ImpDoPaintRectObj, N CreateLinePoly, R ImpPrepareLineGeometry, N SdrLineGeometry, R ImpSetShadowAttributes, R ImpGraphicFill, N ImpCalcBmpFillSizes, R ImpDrawShadowLineGeometry, N PaintNeedsXPolyCirc, R ImpDrawColorLineGeometry, R ImpDoPaintGrafObjShadow, R ImpDoPaintGrafObj, N DrawGraphic -> used in SW, R PaintGraphic_Impl, R ImpDoPaintRectObjShadow, R ImpDoPaintRectObj, N LineIsOutsideGeometry, N ImpGetDrawOutliner, N IsContourTextFrame, N DrawTextToPath, N ImpSetupDrawOutlinerForPaint, R DoPaintObject, R mbPrimitiveTest, R primitiveTest, R isPrimitiveTest, R isPrimitiveTest, R PRIMITIVE_TEST, R PaintGluePoints, N GetPaintRectangle, N XOutputDevice, R ImpSet3DParForFill, R ImpSet3DParForLine, R SetBase3DParams, N DrawPolygonGeometry, N ImpGetShadowPolygon, R ImpDrawShadowPolygon, R LocalPaint3D, R DrawWireframe, R DrawObjectWireframe, R DrawAllShadows, R DrawShadows, N Get3DLineGeometry, N ImplGet3DLineGeometry, R E3D_DRAWFLAG_FILLED, R E3D_DRAWFLAG_OUTLINE, R E3D_DRAWFLAG_TRANSPARENT, R E3D_DRAWFLAG_GHOSTED, R Paint3D, R DrawPolySceneClip, N ImplGet3DLineGeometry, N SingleObjectPainter, R LocalPaint3D, R SDRPAINTMODE_CONTOUR, N mbSpecialTextBoxShadow, R SDRPAINTMODE_ANILIKEPRN, R GetPageRectangle, DoPaintForCalc, DoDraftForCalc, SDRPAINTMODE_SC_, GetExtendedOutputDevice, SetExtendedOutputDevice, mpXOutDev, SingleObjectPainter, pExtOutDev


Problem areas first run:


Done: CalcPaintRectangle : replace with primitive ranges

CalcPaintRectangle() is used in createViewIndependentPrimitive2DSequence() which is not possible when we want to use the primtive sequences in the long run for bound rect calculations. It is only allowed to derive primitive data in createViewIndependentPrimitive2DSequence() directly from model data; usage of getBoundRect/getSnapRect() is not allowed since it may trigger a loop in near future.

Checked all createViewIndependentPrimitive2DSequence implementations and changed them to direct model usage where it was not yet done that way.

Also need to check all createPrimitive2DSequence() implementations to use model data directly. Okay, checked all createPrimitive2DSequence() implementations and did some changes, too. Now all primitive sequence creators from VOC's and VC's should be based on model data only. Building projects to check changes. Okay, changes work as expected, also for page previews. Added another fallback to ViewObjectContactOfE3DScene::createPrimitive2DSequence to create the usual default gray frame for empty 3D scenes. Another small change: Do not print or export the fallback frames for empty 3D scenes or groups. Added to ViewObjectContactOfGroup::isPrimitiveVisible and ViewObjectContactOfE3DScene::createPrimitive2DSequence accordingly. Works as expected, next is to change CalcPaintRectangle to primitive range usage.

Tried to remove all CalcPaintRectangle calls and replace them with a unified calculation method for BoundRects. This works well in principle, but fails e.g. for hierarchical objects like Page, 3D scene or group. This is because not all primitive creators provide a view-independent description yet implementing createViewIndependentPrimitive2DSequence(). This is again because of visibility constraints which need a SdrView (and sometimes more) to decide about their visibility. This information is not available in the primitive's decomposition. Examples are layer visibility, calculation of background colors, help lines, etc. So ATM i cannot get rid of CalcPaintRectangle completely, but i can replace those implementations which are in the way with primitive bound calculations based on single objects.

I decided to completely implement createViewIndependentPrimitive2DSequence() for hierarchical objects on ViewContact (VC) base. Thus it will be possible to always get the whole hierarchical sequence of primitives, but without any visibility tests, neither geometrically nor logically (SdrView attributes, etc, see above). Need to add hierarchical calls to group, page and 3d VC's. Especially for page i will need to change the VC's/VOC's primitive creations; some may be moved to the VC's, at least all VC's need to support one.

Adapted all necessary stuff, also renamed ViewContactOfSubHierarchy to ViewContactOfPageHierarchy which makes things more clear. I could move some of the VOC::createPrimitive2DSequence() implementations completely to view-independent VC-implementations, some needed to be doubled. For Helplines and Grid the VC implementations return an empty sequence since without view neither grid nor helpline information is available (which makes sense anyways since it definitely IS view data).

Again changed ViewContact::GetPaintRectangle() to use primitive sequences for BoundRect calculations. Works well, two problems encountered. - sd::slidesorter::view::PageObjectViewContact calls ViewContact::createViewIndependentPrimitive2DSequence(). - The page previews are updated with a one step delay. How can this happen, the difference is just that CalcPaintRectangle() is not called. Need to check for both.

Looks like both was the same problem. Due to falling back to ViewContact::createViewIndependentPrimitive2DSequence primitives with the wrong size were created. This leads of course to wrong BoundRects when creating the BoundRects from the primitives. It is necessary to provide at least a replacement object in the correct size at all used VC's.

Added ViewContactOfPageObj::createViewIndependentPrimitive2DSequence and PageObjectViewContact::createViewIndependentPrimitive2DSequence (in SD) to support BoundRect calculation. Removing CalcPaintRectangle.


Done: DoPaintForCalc, SDRPAINTMODE_SC_HIDE_*

Checked and decided to remove the SDRPAINTMODE_SC_HIDE_ flags and replace them with three booleans which are accessible at the SdrPaintView and thus with the DisplayInfo, too. Adapted in SC and in SVX accordingly, need to build and test. Also added needed code to the ::isPrimitiveVisible implementations of ViewObjectContactOfSdrOle2Obj, ViewObjectContactOfGraphic and ViewObjectContactOfSdrObj. Added the access methods for that flags also to DisplayInfo, this avoids a lot of includes and unclear accesses. Building and testing.

Had to move the test solely to ViewObjectContactOfSdrObj::isPrimitiveVisible since the original does the same. When testing in OLE and Graphic VOC's and also calling the parent method (the parent implementation) as a start point, all objects will be hidden when draw objects are hidden since OLE and Graphic objects are draw objects, too. Despite this being logically corect, it's not historically compatible and has to be decided centrally.


Done: mbIsInActionChange, mbInCreatePrimitive2D, mbIsPainting

Changed those to static local bools for the to-be-protected methods, this will be better for overview


Done: E3dPolyScene::TakeContour() ohne ImpTakeContour3D, SdrObject::TakeContour(), SDRPAINTMODE_CONTOUR, E3dCompoundObject::ImpTakeContour3D() without ImpGetShadowPolygon

Experimenting with changing to primitive usage. Added a basic ContourExtractor2D to the 2d renderers. Experimenting with getting the correct sequence of primitives since this has no view data at the moment. Another problematic area is the 3D contour creation. Added an own 3D renderer to ContourExtractor2D which is able to create the projected, 3D to 2D 3DObject contours. This allows to use a single contour creator to create all needed contour data. Test code works pretty well. Had to do some more extensions and tests. E.g. the old 3D contour data produced non-closed polygons which was wrong but needs to be emulated to get the identical contour filling when the new contour is used. This was not the reason, going back to closed polygons. Trying out the new, cantral contour creator. It's now based on VC data and a default ViewInformation is used. In principle, contour is view-dependent data and will someday need to be adapted to views. E3dCompoundObject::RecalcBoundRect() ohne ImpGetShadowPolygon : Is done with this change, too. I will change ContourExtractor2D to work with a vector of B2DPolyPolygons; collecting all stuff in a single object loses the polygon topology and is wrong in principle. For compatibility, i will have to throw all polygons into a single PolyPolygon afetr collecting, but preparations for correct handling will be done. Also need to think about topology of line polygons; these should not be closed at all to express their correct topology. Done and works.


Done: With ViewContact::GetPaintRectangle() producing the BoundRect it is principally possible to completely remove GetBoundRect() stuff from SdrObjects.

In principle, a BoundRect calculation needs view information (is view dependent) which shows in the GetPaintRectangle() implementation in using ViewInformation to get the range from the primitive vector. The view information should already be used when getting the primitives and at the correct VOC, not the VC. ATM it will not be possible to change all GetBoundRect calls to provide a view, thus for now it will be okay just to use VC functionality.

Tried, but is not possible ATM since some object derivations from SdrObject use aOutRect (which holds GetCurrentBoundRect() infos) as model data (SW VirtObj's, Groups, 3D (Scenes and objects), Pages). Need to do that later in a dedicated CWS.


Done: getPageRange() is too small, page borders from the page displayed by ViewObjectContactOfPageObj disappear.

Indeed the extension to take into account the page ratio in PagePrimitiveExtractor::impInitializewas too harsh in comparing the aspect ratios of the SdrPage in logic coordinates and the SdrPageObj. These are in principle two coordinate systems, so i made the comparison less sharp by comparing for more than 0.1 percent. That fixes the getPageRange issue. Still, when the page content overlaps the page object, the page frame is not painted. This means that the renderer clips the content too strong. Looking there. Precisised pixel size calculations in impBufferDevice::impBufferDevice which is used to create the buffer for clipping. No change, but precision is better.

Compared with original, and there always a gray line is created since it anyways looks ugly when a clipped state is shown. Addiung such a gray frame creation to ViewObjectContactOfPageObj::createPrimitive2DSequence.


Stripped symbol list third run:


R PRIMITIVE_TEST, R mbPrimitiveTest, R primitiveTest, R isPrimitiveTest, R PaintObjectAndHierarchy, R PaintHierarchy, R ShouldPaintObject, R checkMediaWindowPosition, R DoPaintForCalc, R DoDraftForCalc, N positionControlForPaint, R PaintObject, R PaintLock, R PaintLockAccessControl, R enterPaint, R leavePaint, R m_nPaintLevel, R VOCBitmapBuffer, R VOCBitmapExBuffer, R VOCOfMasterPageDescriptor, R ViewContactOfMasterPageDescriptor::CreateObjectSpecificViewObjectContact, N GetMasterPageDescriptor, R MasterPageBufferEntry, R MasterPageBuffer, R BasicMixer, R AInfoMixer, R AInfoGraphic, R CreateAnimationInfo, R mpAnimationInfo, R DeleteAnimationState, R mpAnimationState, R GetAnimationState, R DeleteAnimationInfo, R HasAnimationInfo, R CheckAnimationFeatures, R CheckForAnimationFeatures, R HasAnimationState, R SupportsAnimation, R GetAnimationInfo, R AnimationState, R ObjectAnimator, R HasObjectAnimator, R mpObjectAnimator, R CreateObjectAnimator, R GetObjectAnimator, R DeleteObjectAnimator, R SupportsAnimation, R AInfoBlinkText, R AInfoScrollText, R AInfoDummy, R CreateBasicMixer, R AInfoScrollText, R ScrollTextAnimNode, R AInfoBlinkText, R GraphicMixer, R TextScrollMixer, R TextBlinkMixer, R AInfoDummy, R ScrollTextAnimNode, R PaintGraphicDraft ,R PaintGraphicPresObj, R PaintShadowedFrame, R PaintDraftBitmap, R PaintDraftText, R PaintReplacementObject, R PaintCalcDraftObject, R DoPaintGraphicDraft, R ColorChangeMixer, R AnimationInfo, R AnimationState, R AInfoDummy, R AInfoMixer, R PaintObjectAtTime, R PaintBackgroundObject, R PaintBackgroundObjectWithItemSet, R DoPaintObject, R PaintGraphic_Impl, R ImpDoPaintGrafObj, R ImpDoPaintGrafObjShadow, R ImpDoPaintRectObj, R ImpDoPaintRectObjShadow, R mbUseBitmapEx, N ImpTextPortionHandler, N DrawTextToPath, N ImpSetupDrawOutlinerForPaint, R EnableVerboseTextComments, R bVerboseTextComments, R IsVerboseTextComments, R ImpPrepareLineGeometry, N CreateLinePoly, N SdrLineGeometry, N ImpLineGeometryCreator, N LineGeometryUsageIsNecessary, R ImpDrawLineGeometry, R ImpSetShadowAttributes, N PaintNeedsXPolyCirc, R ImpGraphicFill, R ImpDrawShadowLineGeometry, R ImpDrawColorLineGeometry, R PaintGluePoints, R DrawAll, R SDRPAINTMODE_CONTOUR, R ImpDoPaintGrafObjShadow, R ImpDoPaintGrafObj, R DrawGraphic, N GetSdrObjectShadowFromCustomShape, R LocalPaint3D, R AreThereTransparentParts, R DrawWireframe, R DrawObjectWireframe, R DrawAllShadows, R DrawShadows, N DoDrawShadow, N ImpGetShadowPolygon, R ImpDrawShadowPolygon, R GetShadowTransparence, R DrawPolySceneClip, R Paint3D, R SetBase3DParams, R ImpSet3DParForFill, R ImpSet3DParForLine, N DrawPolygonGeometry, N ImplGet3DLineGeometry, R E3D_DRAWFLAG_FILLED ,R E3D_DRAWFLAG_OUTLINE, R E3D_DRAWFLAG_TRANSPARENT, R E3D_DRAWFLAG_GHOSTED, N GetDisplayGeometry, N Get3DLineGeometry, R CopyPaintFlagsToChilds, R CopyPaintFlagsFromParent, R PaintReplacementObject, N ImpPrepareForPaint, R DoPaintGraphicDraft, R PaintGraphicPresObj, R PaintGraphicDraft, R CheckAnimationFeatures, R PaintBackgroundObject, R mpMasterPagePainter, R OwnMasterPagePainter, R ViewContactOfMasterPageDescriptor::ActionChanged, R PaintPageContents, R mpPagePainter, R GetRidOfPagePainter, R ViewContactOfPageObj::StopGettingViewed, R PreparePagePainter, R PaintPageReplacement, R PaintPageBorder, R PaintIt, R OCOfPageObjPagePainter, R PaintPageReplacement, R PaintPageContents, R PaintPageBorder, R PaintGluePoints, R DrawPageViewGrid, R DrawAll, R HasAnimationState, R GetAnimationInfo, R GetObjectAnimator, R PaintObjectAtTime, R PaintGluePoints, R setStateFlags, R VOCGuard, R initPaint, R RestoreViewGraphics, R PaintLock, R doPaintObject, R preparePrintOrPrintPreview, R preparePaintOnDevice, R paintControl, R BufferHelper, R RequestBufferedData, R SetBufferedData, R ColorChangeMixer, N EnsureValidDrawHierarchy, R mpNotifier, R PageNotificationObjectContact, R PaintContent, R PaintPreview, R PaintFrame, R PaintBorder, R PaintSelectionIndicator, N PaintMouseOverEffect, R PaintFocusIndicator, R PaintDottedRectangle, R DashType, R PaintFadeEffectIndicator, R PaintPageName, R PaintPageNumber, R GetPageNumberArea, N ImplBegStructureTag, N ImplEndStructureTag, R PaintReplacementObject, N getMasterPageBackgroundCandidate, N isMasterPageBackgroundVisibleOnLayerSet, N SDRPAINTMODE_MASTERPAGE, R PaintBackgroundObjectWithItemSet, R IsAnimationAllowed, R GetAnimationState, R DeleteAnimationState, R CheckForAnimationFeatures, R HasAnimationState, N HasTransparentObjects, N IsTransparent, N IsObjectTransparent, N IsHideContour, R SDRPAINTMODE_TEXTEDIT, N DrawMarkedObj, N SDRPAINTMODE_ANILIKEPRN, R SDRPAINTMODE_VERBOSE_MTF

Removed files:

R basicmixer.hxx

R vocbitmapbuffer.hxx

R vocofmasterpagedescriptor.hxx

R ainfotext.hxx

R animationinfo.hxx

R ainfographic.hxx

R ainfoscrolltext.hxx

R viewcontactpainthelper.hxx

R SlsPageNotificationObjectContact.hxx

R animationinfo.cxx

R vocbitmapbuffer.cxx

R basicmixer.cxx

R vocofmasterpagedescriptor.cxx

R ainfographic.cxx

R ainfoscrolltext.cxx

R ainfotext.cxx

R viewcontactpainthelper.cxx

R impgrfll.cxx

R SlsPageNotificationObjectContact.cxx


This strip went smooth due to the preparations of detected problem areas in the 1st and 2nd run, i take this one. I added the Todos from 3rd run below.


Done: rPaObVOC.InvalidatePaintRectangle:

No longer needed, checked and removed. Done.


Done: bResetAnimationTimer:

In SdrEditView::SetAttrToMarked, decide if object is animated. The VOC extracts the animation info, so added isAnimatedInAnyViewObjectContact() at VC which uses the local VOCList to ask each VOC for isAnimated() which again checks if there is a local sdr::animation::PrimitiveAnimation extraction. Done.


Done: mbSpecialTextBoxShadow:

Take care of the special SC shadow for captions (used as comment objects AFAIK) in ViewContactOfSdrCaptionObj::createViewIndependentPrimitive2DSequence. I have oriented on the old paint implementation, but converted to primitives (of course) Done.


Done: DoDrawOnlySelected (3D):

Removed DrawAllMarked, replaced by DrawMarkedObj. DrawMarkedObj simplified since the given offset is needed no more (applied to OutDev directly in MetaFile recorder). Extended createSubPrimitive3DVector() to also work with the visiblility criteria of the selected booleans at E3dObject resp. E3dScene. Compiling for testing. Needed to correct AND-relationship between layer and selected tests. Trying again. Works for only visualising the selected as intended. Done.


Done: ImpAddTextToBoundRect(), SdrTextObj::ImpConvertObj without ImpTextPortionHandler

Done: DrawTextToPath because of ImpAddTextToBoundRect ?


Added a temporary CalcBoundRect-Iplementation to SdrTextObj using primitives, removed ImpTextPortionHandler as far as possible. Last rest is for ImpConvertObj, i will keep that part ATM.


Done: Draw only selected for 3D

Reused the old mechanism; 3D objects are selected using a boolean member in ther model data. Adadpted default 3D renderer to take that added visibility criteria into account.


Done: reset timer when animated object changed ?

Added a ViewContact::isAnimatedInAnyViewObjectContact() implementation which works by testing all existing VOCs for extrated animations. Work perfectly and is no longer dependent from special implementations at the objects.


Done: Automatic refresh of SdrPageObj content?

I deeply investigated in this one. Removed the necessity for SD to always Hide/Show SrrPageView in ModelChange events. This only happened since the SDrPage of the PagePane was not added to the SdrModel. This greatly speeds up rendering there. Also added using the base object's primitive gereration of the page's content; it is not used ATM but is ready for being used in the cache for re-creating the visualisation.


Done: ImpPrepareForPaint

Done: Graphics swapped in only for e.g. printing ? see old ImpPrepareForPaint

Done: ImpPrepareForPaint -> swapped graphic loading ?!?


Moved AsynchGraphicLoadingEvent from ViewContactOfGraphic to ViewObjectContactOfGraphic. Also moved impPrepareForPaint there and adapted it accordingly. It is now triggered in ViewObjectContactOfGraphic::createPrimitive2DSequence and reacted on in ViewObjectContactOfGraphic::doAsynchGraphicLoading() with a simple ActionChanged() at the ViewContact.


Done: DisplayInfo needs SdrPaintInfoRec ?

Done: XOutputDevice ?


No, it does no longer. Removed and also remove XOutputDevice usage in DisplayInfo. Also removed the SdrPageView from there, it's accessible on the ObjectContact via TryToGetSdrPageView(). Adapted all usages.


Done: Check B2DRange to Rectangle converts (floor, ...)


Corrected some usages.


Done: With CL: TextFieldHandler stuff (was: SDRPAINTMODE_MASTERPAGE):


Changed completely. The TextPrimitive is decomposed using view information. The page is view information in the sense that it's PageNumber may be relevant for decomposition. Completely changed ViewInformation2D implementation. It is no olger limited to ViewTransformation, Viewport and ViewTime, but freely extendible. Tio refrlect this at the API, i exchanged GeometryInformation2D and 3D with a uno::Sequence< beans::PropertyValue >. ViewInformation2D is used as implementation class to convert between API and basegfx representations in a central place.

This allowed to have the xDrawPage as "VisualizedPage" available at decomposition time. The concrete implementation sets the appropriate SdrPage at the used SdrOutliner. Adapted all usages and adapted all places where the correct xDrawPage needs to be used. Works well now.



Done: SdrOle2Obj activation, stuff from old DoPaintObject (SC: MS_EMBED_ACTIVATEWHENVISIBLE is in SdrOle2Obj::DoPaintObject), ole size prot (in current version done in PAINT (!)), ole activation (SC), ole HighContrast.


Discussed with MV and others (thanks for given infos) about OLE and changed again. The current state was to use the svt::EmbeddedObjectRef in an OlePrimitive by copying it to a member. This did not work since svt::EmbeddedObjectRef is NOT (as i thought and was indicated by .is() calls) a UNO API implementation with automatic RefCounting. Thus, sharing this with e.g. a boost::shared_ptr would have been a possibility. Discussions revealed that an OLE object and it's svt::EmbeddedObjectRef (as tooling class) cannot live longer than it's container (in the Document file). Since Primitives potentially live longer and the intention is to copy all needed data for visualisation, it would go too far to have an own storage for primtitive-OLEs. I just return to extract the visualisation data for the OLE at primitive creation time at the VC or VOC for the OLE2. This works well, i also already took into account that OLEs potentially need filling and bordering possibilities (for later SW sharing). The primitive itself just carries the OLE metafile as graphics primitive childs (using ViewContactOfGroup as base class). Removed the dedicated OLE primitive from Drawinglayer again.

That imlementation works well and OLE activation works again. Also added a fallback at the VOC for OLE to use the HC (HighContrast) image if needed.



Done: Needed a solution for Chart's PrettyPrinting. This is a mechanism which allows for chart OLEs to paint them directly to the screen. This is necessary when 3D charts are shown and/or Pictures embedded which would not have a correct resolution when transported via MetaFile. IHA added a tooling class for that to svx some time ago (called ChartPrettyPainter).

There are some possible solutions. In the future we certainly will get the sequence of primitives from the chart module there and render it; this will solve the problem since the primitives are resolution independent.

For the moment and to ensure that we will have no quality loss, i will use ChartPrettyPainter as it is. To be able to do that, i need to use it in the VCL renderer where access to an OutputDevice and Paint() - functionality is available. So i embed the chart model into a wrapping simple primitive derived from GroupPrimitive2D which ensures that it will simply decompose to the also included MetaFile.

Still finetuning this mechanism since ATM it does not paint at VDEVs or Windows. It is anyways switched off for those devices, but i will try to get that running. Okay, working now. I forgot thet the PixelRenderer removes the MapMode from the target OutputDevice. That MapMode needs to be restored before calling doPaint() from the prettyPrinter.

It works now, but for being 100% compatible, i added to not do the embedding when Window or VDEV is the target, which exactly mimics ChartPrettyPainter::ShouldPrettyPaintChartOnThisDevice().



Done: Added precompiled header mechanism to project drawinglayer.



Done: GetPaintRectangle implemented on primitive base. GetPaintRectangle() mo longer needed, replaced with getObjectRange() at VOC. The implementation makes sure a current ObjectRange is in place at the VOC and eventually triggers getPrimitive2DSequence(). There, when the content of the sequence of primitives did change, the ObjectRange is refreshed automatically. So, for VOCs there is alwayz a ObjectRange (a BoundRect) available. This is where it belongs and it makes clear that BoundRects are View-dependent (it's at the VOC, not the VC).



Done: ImplRenderPaintProc::createRedirectedPrimitive2DSequence change to non painting.

In sd/source/ui/unoidl.cxx a ViewObjectContactRedirector is used where for the formerly painted objects in the case of pdf export structure tag information was added. Needed to change that since we are not painting here anymore. Added a simple group-based primitive (StructureTagPrimitive2D) which decomposes to it's content when ignored and can hold a vcl::PDFWriter::StructElement. If there is content and pdf export is running and a structure tag is needed, the content is wrapped in such a primitive. At the VclPdfPrimitive renderer, these tags are used and the needed BeginStructureElement()/EndStructureElement() with the available tag are generated. The children (the wrapped sub-content) is processed in-between as needed. Tested but could not produce a case where the changes pathes were taken. Need to ask PL and CL how to produce a case using this. ATM GetIsExportTaggedPDF() is always false, but needs to be on true to activate that tagged pdf export.



Done: ole shading: // shade the representation if the object is activated

if ( bActive ) ::svt::EmbeddedObjectRef::DrawShading( aRect, pOutDev );


With the help of mv i investigated OLE shading. This can no longer be painted but needs to be added as primitives. Fortunately, a hatch pattern is used from DrawShading, so it is not a big problem to create a primitive representation for it. The original uses 5 pixel distances. I decided to use 1.25mm disntances which displays pretty much the same in standard zoom, but is view and scale independent and thus better for primitive usage. It will also be possible to do other visulalisations with ease for visualizing this. Tested and works well with normal OLE and Icon visualisation.



Done/Todo: DrawPageViewGrid : used in SC and SW

Cannot be avoided ATM. Keep as is.



Done/Todo: "ScrollText" remove from GraphicExporter::filter

Done/Todo: graphic exporter for scroll text rectangles ?!?

Needs the slideshow module to be changed first, cannot be changed ATM. Keeping as is.



Done/Todo: Base3D geometry with buckets still needed?

Done/Todo: E3dCompoundObject::RecalcBoundRect with primitives, get rid of old 3d geometry creation

Done/Todo: DoDrawShadow->RecalcBoundRect, ImpGetShadowPolygon

Done/Todo: ImplGet3DLineGeometry->ImpGetShadowPolygon

Done/Todo: Base3D removal (dialogs, etc)

Done/Todo: Base3D removal : replace in dialogs (SvxPreviewCtl3D), also in VCL and goodies

Successfully tested new primitive getRange() method in E3dCompoundObject::RecalcBoundRect(), but there are too many things relying on the old 3D geometry like HitTest and others, so i will let this as it is ATM.



Done/Todo: SdrObject::ImpConvertToContourObj without CreateLinePoly to get rid of CreateLinePoly, SdrLineGeometry

Done/Todo: CreateLinePoly, SdrLineGeometry because of ImpConvertToContourObj ?

Done/Todo: ImpConvertToContourObj -> CreateLinePoly, SdrLineGeometry, ImpLineStyleParameterPack, ImpLineGeometryCreator

Too many caveats ATM to change this and no necessity. Moving this to a later point in time.



OpenPoints from stripping (not yet evaluated or started):

I have now moved the Done/Todo points to a P2 Todo point and the Todo points to another P2 Todo. The stripping is complete now.

Todo List

Things to be done (P1: needed for integration, P2: would be nice, P3: later). Minimal things to do are P1. I will sort P1 to the top; inside P1 sort to TimeEffort.

I will also add for P1 tasks the following information:

 Candidate: who's task this will be
 TimeEffort: rough time effort estimation
 Clearness (1-6): how clear the task is defined (with german school notes since we are all used to them)

To keep the overview, things which are done will be moved back to the Done-List (the next Point).


Hint List: To not lose any upcoming stuff or information, i add a Hint List here. It will keep a shortened list of things which came to my mind (or the mind of others) and which are not (Yet?) important enough for an own point. Some of these entries may become own points, some not. All of them need to be checked.


-- empty --


P2: Open points from stripping

 Candidate: AW, FS
 Clearness: 1

- Todo: MasterPageCaching with primitives

- Todo : AsynchGraphicLoadingEvent live


P2: Evtl. THB will adapt slideshow early to primitives, this would make VCL MetaRenderer more simple (see above)

 Candidate: AW/THB
 TimeEffort: ?
 Clearness: 1

Changed candidate to AW since THB is not really available for this task.

Talked to THB recently (added again); he may try to get the time to do this. In the meantime we again and again stumbled over tasks/problems with SlideShow not using Primitives, so the arguments to do this get more and more.


P2: Create a slideshow renderer for primitives. This would include to create a primitive renderer for canvas which will be a candidate to be used in the applications for DrawingLayer paints, too.

 Candidate: AW
 TimeEffort: ?
 Clearness: 1

Changed candidate to AW since THB is not really available for this task.

This may be seen more general and not only for SlideShow; there is a possibility to improve rendering speeds by writing pure system-dependent renderers, e.g. a pure GDI+ renderer for windows residing in an own dll in drawinglayer project.


P2: Use the Canvas-PrimitiveRenderer to change DrawingLayer paints to use canvas directly instead of VCL. Also possible as example: A direct Windows (DirectX?) renderer support.

 Candidate: AW
 TimeEffort: ?
 Clearness: 1

Changed candidate to AW since THB and CL are not really available for this task.

Currently stalled; the primitive renderers all use the default VCL-Renderer. Implementation is done with some easy VCL extensions to support the needed AntiAliasing command on each system. This works pretty well since with a primitive renderer the subset of graphic commands used by the renderer is much better controllable as rendering using VCL (or beware: XOutputDevice :-)). This is sufficient for OOo 3.1, but there is room for enhancement, especially in 3D, too.


P3: Rework OverlayObjects paint part to use primitives. Not urgently necessary, may work without primitives as it is now.

 Candidate: AW
 TimeEffort: ?
 Clearness: 1

Maybe not needed at all. Discussed once with THB who stated that there is no need to do so and it may even have advantages to stay on VCL and pixel base with overlays. Another possibility is to define a standardized embedding of view-independent primitives to view-dependent ones and thus to simply stay view-oriented with the overlay objects by using those. One advantage would be that the overlay objects would no longer need to implement a getRange() and the risk of doing thos wrong would be elliminated by using the sequence of primitives getRange() call.

Currently stalled and not needed for OOo 3.1. The current state is that i implemented a OverlayObject which uses a sequence of primitives as visualisation data. This object is used as a briding object between primitive visualisation and overlay. This is currently mainly used in the Full Drag feature for OOo 3.1. The result is that most of the interactive overlay (e.g. the drag lines, too) is rendered using primitives and a primitive renderer. This was needed to have the overlay AntiAliased in OOo 3.1, too.

Still, there is plenty of room for enhancements here.


P3: Tiling support for MetaFile renderer bitmap preparation for any-transparence filled primitive. Not urgently needed ATM since with currently created primitives this will never happen.

 Candidate: AW
 TimeEffort: ?
 Clearness: 1


This List may not be complete, so Points will need to be added. If You have suggestions, feel free to contact me.

Done List

Tasks which are done. These tasks are moved here from the Todo List from the section above.


Done Hint List: Things cleared (tasks moved from Hint List in the Todo chapter)


- Done: Sometimes in AA mode, only when creating new objects, parts of the SnapLines stay on screen.


- Done: When starting a Slideshow with (F5), the first page is not shown. Looks like it gets fetched, but somehow not painted. This was because when simplifying the clippings from basegfx, i did a wrond adaption in slideshow. Thanks to THB for giving me the needed hints.


- Done: Pixel-resolution Bitmaps sometimes get scaled a little bit (only rare, but seems to happen. Need to control that, evtl. add a primitive for that purpose which decomposes centrally on bitmap pixel size and the given ViewTransformation to fet 1:1 pixel mappings. May also be the renderer, though. Re-checked but could not reproduce in current version. This is gone after reworking/optimizing the 2d scene decomposition (3D rendering) to consequent discrete resolution usage.


- Done: Just for security: Check all the page number and master page visualisations of Impress again. Checked that and reworked the schema which is used for knowing the visualizing DrawPage (whichis not the current one when you think about MasetrPage content and/or page visualisation objects). Works well now.


- Done: Need to check if getRange() from 3d scene primitive might be implemented without using decomposition. Not only checked but reworked the getRange() get2DDecomposition() and createLocalDecomposition() to work more effective with discrete target coordinates. Also changed clipping against discrete ViewPort accordingly (on Metafile recording, there is no ViewPort set which means to always show everything)


- Done: When combining polygons or objects which will be converted to polygons for being combined, straight line segments get converted to curve segments unnecessarily. Changing that.


- Done: Sometimes when curve editing, a line (probably part of the overlay) to the null point is drawn. Found and resolved. The processing of the overlay striped polygon tried to produce polygons even with only one point. Changed that and secured the used tooling methods in basegfx.


- Done: Sometimes when scrolling the DrawingLayer view the repaint is one pixel to small in X or Y resulting in srolled but not repainted 'rests' in the right and bottom pixel lines. Need to check for integer/double conversions when calculating the repaint regions. May have been a problem with incompatible working environment, not seen anymore. Still checking. Could not reproduce in current version, still keeping an eye on it. Took a look again, could no longer reproduce.


- Done: THB told me about a funny effect when text ends with '!'. Seems that there are exception handlings in EditEngine/Outliner to nove that sign to the front of the sentence ?!? Need to check this, does not happen in old mode. Checked again, could not reproduce. Need to ask THB. Asked THB, he said it was simple to reproduce. If i cannot reproduce, it probably is fixed with one of the other changes.


- Done: Had to change back IsRTL() in one of the in-between stages of text decomposition (it was wrong). Need to check RTL-modes again. Checked, looks good.


- Done: PDF export loses fillings (simple color ones). Debugged, but does happen in PDFWriter itself. Another sign that it's not the VCL MetaFileRenderer is that printing works flawlessly. Contacted PL. Found out that in filter/source/pdf/pdfexport.cxx when a META_COMMENT_ACTION uses the SvtGraphicFill, only the polygon is extracted but not the color. All other actions between XPATHFILL_SEQ_BEGIN and XPATHFILL_SEQ_END are skipped with one exception: the fill color. But the fill color is used AFTER the polygon was painted. I changed VclMetafileProcessor2D to first set Fill and LineCOlors, then to add the MetaFile comment action. Works. Will setup a task for SJ to change that in pdfexport.cxx.


P2: Stuff from stripping moved to Done/Todo later

 Candidate: AW, FS
 Clearness: 1

-Done: DrawPageViewGrid : used in SC and SW

Cannot be avoided as long as SC and SW are not completely based on primitives


-Done: "ScrollText" remove from GraphicExporter::filter

-Done: graphic exporter for scroll text rectangles ?!?

Can be removed after slideshow is changed o primitive usage


-Done: Base3D geometry with buckets still needed?

Yes. Currently, the old 3D geometry is used for 3D HitTests.


-Done: E3dCompoundObject::RecalcBoundRect with primitives, get rid of old 3d geometry creation

RecalcBoundRect is now centrally implemented for SdrObject to use a sequence of primitives and extracting the BoundRect from it. The method stays virtual since it still needs to add some offset for SdrVirtObj and SWs virtual objects.


-Done: DoDrawShadow->RecalcBoundRect, ImpGetShadowPolygon

No longer needed with central RecalcBoundRect method. Stripped together with other no longer needed stuff.


-Done: CreateLinePoly, SdrLineGeometry because of ImpConvertToContourObj ?

Completely removed.


-Done: ImpConvertToContourObj -> CreateLinePoly, SdrLineGeometry, ImpLineStyleParameterPack, ImpLineGeometryCreator

Completely removed.


P2: Unify RecalcBoundRect

 Candidate: AW
 Clearness: 1

Done: BoundRect calculations are currently spread over the SdrObject model objects. With primitives, it is possible to centrally replace those calcualtions (and code used from them) by unifiedly implementing RecalcBoundRect. Had to change another two primitive creators which did not use direct model data for primitive creation but BoundRect data which of course leads to a loop in this case. Works like a charm now. Removed all crude RecalcBoundRect calculations and all associated stuff like extra sizes for text, etra sizes for beveled lines, extra stuff for 3D, etc. Also could remove the old line geometry creators completely now. Only one central implementation at SdrObject::RecalcBoundRect stays and does the job. Anyways, it stays virtual since objects derived from SdrVirtObj (e.g. SW objects) need to add some offset to the calcualted BoundRect.


P2: Remove 3D Point objects (Labels)

 Candidate: AW
 Clearness: 1

Done: The cahrt2 module no longer used SdrLabelObjects, so the last usage of 3D Point objects is gone. This allows removal of all those and also the extractor for the 2d primitive scene. Completely removed SdrPointObj and SdrLabelObj, their VCs and VOCs, the primitives for them and extra handlings in the 2D Scene3D primitives to create text primitives for existing label objects. Also removed the renderer which was used for filtering the labels.


P2: Move 3D shadow creation to 3D object wrapper 2D objects

 Candidate: AW
 Clearness: 1

Done: With the introduced 3D geometry information it gets possible to locally create that 2D shadow geometry for 3D objects at the 3D to 2D object wrappers. This is the more correct place and will allow removal of the currently used 3Dm shadow extractor. A extractor will still be needed, but just to collect the 2D shadow geometry (if it exists). It will also allow more central BoundRect calculations for 3D objects with shadow. I could not completely move 2D shadow creation to the 3D primitives, but enhanced the 2Dto3DprimitiveWrapper to include the shadow, even when projected. The 3D shadow can be on/off and have different distances and can even be projected (see 3d properties). All this is taken care of using the same filtering 3D renderer the 2D Scene3D decompose uses. All together this embedding wrapper primitive for 3D allows to get a BoundRect in 2D for each SdrObj3D directly without the need to access the scene (and deal with 3D projections) in any way.


P2: Simplify VOC hierarchy. There is no real need anymore to have the parent and the children as members at VOC, those are reachable on demand.

 Candidate: AW
 TimeEffort: 1 Week
 Clearness: 1

Done and works and makes things much clearer and simpler. Also started to simplify access and availability to visualisation data during work with primitives. There is a drawinglayer::geometry::ViewInformation2D (and a drawinglayer::geometry::ViewInformation3D accordingly) which hold the current ViewTransformations, ViewPorts and things líke render time, visualized page (for PageNumber field decompositions). Also both correspond to a sequence of properties for UNO APIs. The implementation classes offer transformation between UNO API sequence of properties and basegfx tooling classes/implementations. Both also support free extra infos contained at the sequence of properties. The 3D version includes all needed 3D ViewTransformations, so in decompose it will be possible to do view-dependent things for 3D now. This will e.g. be needed for #i82871# where the ObjectToView transform is needed to create object outlines.


P1: Adaption after resync: Tables in Draw/Impress

 Candidate: AW
 TimeEffort: 1 Week
 Clearness: 1

Done: CL's nice new Table feature made it to DEV300 m3, so i need to adapt the there still used DoPaintObject-Stuff to primitive usage. Since tables are somewhat complicated (they need extra text formatting and the borders are quite complex) this will need ca. one week. Checked in new working version and built the unxlngi6.pro version, waiting for CL's comments. I have to admit, table borders ARE complicated. I needed three efforts to get it working properly and looking nice. The new implementation uses line creation (no fat polygons), so - when the renderer supports it - the lines will stay visible even with very zommed-out displays. Waiting for CL's comments. Tables (especially frame borders and the areas they overlap) look much better. Table display looks well and is done. Text in tables needed some extra changes since those texts need to be decomposed different from all up to now used texts. Also the chane included to adapt primitive creation to SdrText (the isolated text part of a SdrObject).


P1: Pie Charts show that perspective has a problem on extrude objects.

 Candidate: AW
 TimeEffort: 1-2 Days
 Clearness: 1

Done: I need to check B3DRange creation for extrude objects, maybe for rotate objects. I need to find out, which ones are used there. Already checked a lot of things, but no solution yet. I simply have not yet found the difference between the old and new visualisation. I am now debugging the aw033 and a current version in parallell to compare values. After checking all the transformation geometry itself for two days and comparing with the original version, i found out that the sub-classes which chart uses and which contain 3D transformations for the sub-hierarchies, were not taken into account at geometry creation. After changing this, i get correct object dimensions, but mirrored and/or translated 3D shapes. At least i have a clue now where the problem is. Another problem is that chart uses 'invisible' 3D objects to get their measurements correct. This interferes with my primitive creation strategy to not create invisible primitives. While this is correct in principle, it leads to other range definitions when using primitives for range measurements. I have to rethink this. I got the geometry problems solved now. I am using a 3D transformation primitive for representing empty 3D scenes which are used for grouping and transformation services and also got back to GetTransform() instead of GetFullTransform() since the embedded transformations are now handled by the renderer. It should have worked with GetFullTransform(), but there must be a problem there in the old code somewhere. Anyways, using the transformation group is much better. This also allowed to attach the initial transformation (that from the starting scene) to the generated primitive vector of 3d objects, so there is no longer a ObjectToWorld initial transformation given for the 3D Geometry. Cheched in after the resync and tested. Works well, done.


P1: Pie Charts with lines get no line reduction

 Candidate: AW
 TimeEffort: 1-2 Days
 Clearness: 1

Done: In the chart module, when using Pie 3D charts and adding lines to them, the line geometry is reduced to show only the top and bottom planes and not all created extruded planes, especially not at the rounded areas. Added the missing flag to 3D Primitives for Extrude and Lathe. Using that attribute in decomposes in that objects. Works well, done. Corrected a small error which got sometimes the wrong setting for the ReduceLine() flag from the ItemSet.


P1: In SW, OLE visualisation makes strange errors

 Candidate: AW
 TimeEffort: 2-3 Days
 Clearness: 1

Done: When loading/copy_pasting OLEs from another office version to current aw033 SW build, the painted Metafile shows strange offsets. This does not happen inside Draw/Impress where another OLE implementation is used. Need to check that. It's getting even more weird: If i have ony one OLE in aw033 SW, all works well, no matter where the OLE comes from. It seems like somewhere in SW OLE painting code, an offset is set/not reset properly. It looks like i have found that one. The SW OLE objects are wrapped from the FlyFrames there. Those FlyFrames again are based on SdrObjects to hold them in the DrawingLayer hierarchy properly. They currently get painted using the unavoidable decompose for a specialized SW-only primitive for that purpose. Problem is that the VCL pixel renderer resets PaintMode at the target OutputDevice and instead uses it's ViewInformation to directly ransform to pixel level. When the FlyFrame exceptional paint wrapper takes place, the original MapMode is no loger available. I need to find a way to get the original MapMode in that case. Okay, added the original MapMode to the SW View and initialize it in ViewShell::DLPrePaint2 where all paints start. That way, the exceptional SW primitive can access the original PaintMode without problems. Checked for screen display, printing and PDF export. Works well.


P2: Remove all no more needed stuff, the complete DoPaintObject stuff and all involved; the ExtendedOutputDevice and its problems, much potential.

 Candidate: AW
 TimeEffort: 4-6 Weeks
 Clearness: 1

Done: Started an own chapter for this one, see above.


P1: SW uses DoPaintObject calls and SdrVirtObj functionality to paint FlyFrames in DrawingLayer

 Candidate: AW
 TimeEffort: 1 Week
 Clearness: 1

Done: SW uses DoPaintObject() which has no future with primitives. SW uses two different virtual object derived from SdrVirtObj, SwVirtFlyDrawObj and SwDrawVirtObj. Both use DoPaintObject calls which need to be replaced. Description of both cases:

Done: SwDrawVirtObj is used to work with DrawObjects in Header/Footer which need to be represented multiple times, but exist only once (SW uses only one big DrawPage, so there is a problem with re-using the same object on the same page). There exists one original SdrObject (usually in Header/Footer of first SW Page) and one SwDrawVirtObj for each other SW Page. This does conceptually not work well with VOC/OC/VC hierarchies when SdrObjGroup (GroupObjects) are involved since in principle the sub-objects of the original SdrObject and thus their VOC would be reused when the SwDrawVirtObj would hand out the sub-hierarchy of the original object. To fulfill the VOC concept it would be necessary to mirror the sub-hierarchy with SwDrawVirtObj's for each sub-SdrObject. This is not done ATM, but solved by letting the DoPaintObject of SwDrawVirtObj paint the whole sub-group hierarchy directly. Solution for primitives: Added a VC and a VOC for SwDrawVirtObj, the VOC implements createPrimitive2DSequence and collects the primitive sequences from the referenced object, resp. recursively for group objects. For this collection, a unified (and single) TransformPrimitive2D is applied. Thus, the whole sub-hierarchy (and it's evtl expensive decompositions) is completely reused.

Done: SwVirtFlyDrawObj is used to paint FlyFrames in DrawingLayer hierarchy. Added VC and VOC classes for it. In the VOC, a SW-local primitive (SwVirtFlyDrawObjPrimitive) is implemented and incarnated in createViewIndependentPrimitive2DSequence(). This primitive has no own implementation of createPrimitive2DSequence(), so it never will have a local primitive sequence. This will force the renderers - which do not know the SW local primitive at all - to call get2DDecomposition. There, it is possible to reference back to the SW SdrObject (SwVirtFlyDrawObj) and call a modified paint there when SW is in repaint cycle. This solution does not corrupt primitive logic and allows usage of FlyFrames in their current form. Later this is exactly the point where SW has to create a primitive sequence for FlyFrame visualisation anyways.


P1: Check usages of created Metafile comments

 Candidate: AW
 TimeEffort: 1-2 Days
 Clearness: 1

Done: Works well, all extensions tested. See extended comments in drawinglayer/source/renderer2d/vclmetafilerendere2d.cxx.


P1: Decomposition of DecoratedTextPrimitive needs some more work (new primitive for waved line, ATM produres Polygon data directly). HDU is very confident to be able to cover everything.

 Candidate: HDU, AW (needs some team effort)
 TimeEffort: 2-3 Days
 Clearness: 2-3

Done: HDU did a first version for TextDecoratedPortionPrimitive2D decomposition which works reasonably, but does not support some frmatting stuff. I will need to redesign and extend this functionality (see other todo's).


P1: Migrate HDUs work for waved underlining to an own primitive with own decompose and direct VCL handling for pixel renderer. Needs stuff from aw052/aw051 to have the curve handling changes. Ready to execute after last resync.

 Candidate: AW
 TimeEffort: 1 Week
 Clearness: 2

Done: Did some experiments, first try was to add a WrongSpellVector to the TextDecoratedPortionPrimitive2D directly. This involves handling in the decompose and in the text renderer. There were two arguments against this: It is too tight bundled with the text itself and there is no start point for the evtl. view-dependent decompose of the wavelines. Changed and implemented an own WrongSpellPrimitive2D which is directly created at text layouting (in impTextBreakupHandler in svx).

Done: For waveline support, i added a createWaveline method to basegfx polygontools. Also added createEdgesOfGivenLength there which is the base for the waveline creation from any polygon and may be more commonly used.

Done: Added an WavelinePrimitive and usage of it. It decomposes to a appropriately curved polygon primitive.

Done: Change the wave-underlining in the TextDecoratedPortionPrimitive2D decompose to the new WavelinePrimitive.

Done: Reworked the whole TextDecoratedPortionPrimitive2D decomposition; it now supports emboss, engrave, outline and all underline and strikethrough modes, also word-wise.


P1: PDFExtOutDevData needs some support (need to discuss with SJ, too) :

 Candidate: AW
 TimeEffort: 1-2 Days
 Clearness: 1

Done: Added URL support to get the correct URL exported to PDF.

Done: Added Begin/EndStructureElement support for text paragraphs

Done: Added FormControl support. Had to move the support stuff from svx to toolkit, need to link pdfrenderer against toolkit now. Tested, works.

Done: Added support for Graphic stuff when IsLink() is used in Graphic (see old support for it in goodies). Need to discuss with SJ since this feature is not working/unused ATM in master and thus untestable for me ATM. Discussed with SJ and we tested it, works, done.


P1: VCL MetaRenderer needs to be created, evtl. VCL needs some adaptions when using things like ClipRegions based mostly on polygons. These preparations are mostly for printing support.

 Candidate: AW, PL (for VCL help)
 TimeEffort: 2-3 Weeks
 Clearness: 2-3

Done: Splitted the VCL Primitive renderer in VCL Pixel renderer and VCL Meta renderer. For Meta renderer, added support for filled primitives using ClipRegions. Direct support of hatch fill, color fill, gradient fill and bitmap fill. Recognition of simple transparent fills and transparent gradient fills and their VCL support. Fallback for any-transparence filled primitive groups to bitmap preparation (not trivial due to different DPIs in different devices).


P1: EditEngine needs work to deliver underline data (redlining due to spell checking) to DecoratedTextPrimitive.

 Candidate: AW
 TimeEffort: 1-2 Weeks
 Clearness: 4

Done: Added a WrongSpellVector to EditEngine/Outliner ImpEditEngine::Paint for the stripping part (bStripOnly). Also added a WrongSpellVector to the TextDecoratedPortionPrimitive2D and created the managing/copying code for data transport. Done: Handle WrongSpellVector info in decompose of TextDecoratedPortionPrimitive2D.

Done: Handle WrongSpellVector info in VCL pixel renderer Text rendering directly

Done: Needed to remember spell checking state in SdrTextPrimitive to deliver the correct decomposition on demand.


P1: EditEngine needs work to deliver Field info for text field portions.

 Candidate: AW
 TimeEffort: 2-3 Days
 Clearness: 2

Done: Added a TextHierarchyFieldPrimitive2D to encapsulate field text portions (but not limited to). It has a field type where necessary and a string for extra data (e.g. URL). ATM we need field types Page and URL for MetaCommentAction and PDFExtOutDevData support.


P1: EditEngine needs to deliver Locale info and text hierarchy info.

 Candidate: AW
 TimeEffort: 2-3 Days
 Clearness: 2

Done: To support TEXT_EOx MetaFileComment information which is used currently with the Slideshow to animate text by Paragraph/Character/Word (and others...) Locale info is needed to be able to use a BreakIterator for TEXT_EOC, TEXT_EOW and TEXT_EOS infos. To create TEXT_EOP and TEXT_EOL info, text hierarchy info is needed.

Done: Added Locale to TextSimplePortionPrimitive2D and support for BreakIterator at Vcl MetaFileRenderer to create EOC/EOW/EOS, works well.

Done: Created text hierarchy group primitives TextHierarchyBlockPrimitive2D (for Text blocks; ATM one per xShape), TextHierarchyParagraphPrimitive2D (for Paragraph encapsulation) and TextHierarchyLinePrimitive2D (for line encapsulation). Added support for creation of these in EditEngine and DrawPortionInfo. THB will be able to use these much better when he changes Slideshow to primitive support. Added support in MetaFileRenderer to create corresponding MetaFileComment tags. Works well.


P1: Metafile comments need to be 'simulated' by the VCL MetaRenderer to not break the current exports (evtl slideshow, too)

 Candidate: AW, THB
 TimeEffort: 2-3 Days
 Clearness: 3-4

Done: All currently used MetaFile comments are in place, need to be checked.


P1: EditEngine needs work to deliver sentence, word and paragraph numbers when diashow is not adapted to primitives. AW: Intensified to P1 due to THB.

 Candidate: AW
 TimeEffort: 4-5 Days
 Clearness: 3-4

Done: Uses TextHierarchyPrimitives to keep/transport the whole Paragraph/Line/Sentence information.


P1: Check Text Handling/Decomposition for CTL and vertical texts. This is a guess, but i may need extra work there.

 Candidate: AW
 TimeEffort: 1 Week
 Clearness: 2

Done: Installed Languages CH (Chinese Taiwan), JP (Japanese), CH(Chinese PRC), AR (Arabic Egypt), GU (Gujarati), HE (Hebrew) and TH (Thai). Experimented with those languages. Vertical text works well, including bullets. Languages have their problems, discussed with HDU. Base problem seems to be that the VCL text renderer needs more context for correct rendering than just the characters of the portion, HDU talked about 8 characters before and after the portion. ATM the TextPrimitive uses a OUString copied directly for portion context. I will need to change that to have the whole String and start and length indices. Doing necessary changes.

Done: Also going back to String instead of OUString and using xub_StrLen, too. Copying the whole string from the Outliner/EditEngine callback to an OUString and using sal_Int32 for the indices would work, but has no sense now since the copied string would indeed get copied multiple times instead of just referenced internally as it happens with String. This can be changed back to OUString at a point in time when we have a layouter which is able to offer OUStrings.

Done: Reworked the 'Word wise' option for underline and strikethrough. This is pretty tough to use i18n.BreakIterator here since You get indices BEFORE Your start index when looking for words and the search start is inside a word. It is necessary to take care of each necessary combination (start/end before/after portion indices, also end loop criteria). Works now, checked for all cases which came to my mind.

Done: Changed TextDecoratedPortionPrimitive completely to support the (String, start, len) schemata. This indeed solves the context problem with CTL and multiple languages. Doing some more tests.

Done: Numbers may be in arabic or in hindi. This is supported in the OutputDevice as usual. This information is stored in the tools/settings and not in the model, thus i had to adapt the VCL renderer who now inits that values at the given OutputDevice.

Done: When typing arabic and mixing with space-encapsulated numbers, the primitives are rendered wrong. Found out with HDU that again at the OutputDevice, support for TextLayoutMode is used in Outliner. This needs RTL information which i added to the FontAttributes for the TextSimplePortionPrimitive2D. Using that info in the VCL-Renderer works as expected. Also added BiDiStrong info to FontAttribures since HDU is sure this will be needed in the future, too. Just added, not used at primitive creation or primitive rendering yet.

Done: Works pretty well, still having an eye on this one. Did some more tests, no more problems detected. Moved to Done-List.


P1: Check Bullet display with primitives. This is only a guess but there is some special/exception handling in EditEngine for this, so i guess it may not work well up to now.

 Candidate: AW
 TimeEffort: 1 Week
 Clearness: 1

As i expected: There are Problems with Bullet layout, but not only with Primitives. Have You ever tried to rotate a text with graphic bullets? Or paste special as Metafile? Argh!

Done: Corrected all this for Primitives. Added callbacks, data classes and extras for bullet callbacks when layouting using Outliner/EditEngine (was of course missing/never supported). Also changed bullet layout to use the straight way to do things, the same as the paint goes (there were unnecessary exceptions which made unnecessary correction stuff with the positions, etc.). Bullets work now, SymbolFont ones, enumerations and graphic ones. Works better than the original.

Done: On primitive side, i embedded all bullet geometry (text and/or graphics) in TextHierarchyBulletPrimitive2D. This allows to parse the content more precisely and create the currently necessary „XTEXT_EOC“ MetaFile comment actions for presentations (as long as presentation needs this). Later, presentations can directly identify bullet geometry using the given tag.

Done: The changes to Outliner/EditEngine now also support „HACK #47227#“, see there for info (grep the code). Seems as if the whole specialized outline view display in Impress is coded (hacked) to be produced directly inside the Outliner (!).

Done: Still experimenting with bullets to be sure. Did some more tests, no more problems detected. Moved to Done-List.


P1: Check printing using the VCL MetaFileRenderer. This needs to work flawlessly. Take into account special problem areas like transparence or gradient transparence.

 Candidate: AW
 TimeEffort: 1 Week
 Clearness: 1

Done: Corrected problems with linear transparent objects, the detection of simple transparent color objects in VCL PrimitiveRenderer was too simple since a dynamic_cast also detects the derived classes. Made more precise using the getPrimitiveID() command for alpha primitive and unified alpha primitive.

Done: Corrected problems with transparent shadows. This was indeed because in the helper impDumpToMetafile the Rectangle for the MetaFile needed to be transformed using the current transformation (e.g. For shadow displacements).

Done: Corrected problems with gradient transparence shadows. This was because for those shadows the gradient transparence is not allowed to be modified by the color modifier primitive stack since it represents alpha channel values. Extended impConvertFillGradientAttributeToVCLGradient with a bool to allow that.

Done: Did a printing test on a postscript printer with transparence and all more complex graphic stuff and it works good.

Done: Compare postscript FileSizes. Test case produced 7k docs, the one on primitive base was 9 bytes smaller.

Done: Check for Hatches, especially with transparency. Works well on printed examples.

Done: Checking and modifying FormControl printing, see (VI).

Done: Still experimenting with roated stuff and others. I did some extesive tests, e.g with PDF export/MetaFile export and presentation. No more problems detected. Moved to Done-List.


P1: Take a 2nd look at FormControls and if they work

 Candidate: FS, AW
 TimeEffort: 1-2 Weeks (in progress already)
 Clearness: 1

Done: The ControlPrimitive2D needs to be better supported. It already creates a visualisation when in edit mode and is handled in VCL MetaFileRenderer. It also needs to be handled in Vcl PixelRenderer to create/show a VCL child window for that control type. Need to ask FS how to do that. ATM it is just displayed, but not clickable.

Done: Discussed with FS. We need positionControlForPaint() to be called at VOCs for FormControls. Also it makes sense to hand over awt::XControl to ControlPrimitive2D to reuse it if it already exists. In Principle, the whole control handling may be done view-specific by any View-Implementation when primitives are finished, but ATM the VOC usage is the current view implementation and usage of positionControlForPaint() in e.g. VOC::getPrimitive2DSequence will be the way to go.

Done: Implement as discussed. First implementation is working. Added ViewObjectContactOfUnoControl::createPrimitive2DSequence where positionControlForPaint() can be called. That implementation also adds a XControl reference to the ControlPrimitive2D so that it may be reused. Necessary changes at ControlPrimitive2D done. Now, for the SdrPaintView, all controls work in edit and non-edit mode again.

Done: Need to discuss with FS where to not handle FormControl paint processing when not in edit mode. When in life mode, it is not necessary to produce the fallback primitive mode (which decomposes to a BitmapPrimitive). There are two possibilities: Return an empty sequence at ViewObjectContactOfUnoControl::getPrimitive2DSequence() when the control is in life mode (or the on exceptional control which indeed always is a VCL ChildWindow). The other method is to handle ControlPrimitive2D at the VCL renderer and decide there. This would allow not to change the primitive description at all, but let the view decide if/what to paint. I prefer the 2nd method, but i will discuss with FS.

Done: Discussed with FS, he agrees with 2nd method and gave me code to check visibility of xControl. Built into VclPixelRenderer. Works well.

Done: Checking printing of Controls. This is different from PDFEport which is already supported. I am investigating along UnoControlPrintOrPreviewContact and it's usage of preparePrintOrPrintPreview and paintControl. Implementing this and taking a look if it works. I will also talk with FS about that code. Fixed another problem with control size when printing, added a positionControl there, works.

Done: Since the VCL PixelRendere is now capable of detecting visible controls, positioning and sizing may be done there instead of doing it at ViewObjectContactOfUnoControl::createPrimitive2DSequence. This would also be consequent with the VCL MetaFileRnderer. Need to discuss with FS. Tried this solution (and added it using static bools for testing which will be removed again), but does not work smooth. Going back to previous solution.

Done: Discuss Point above with FS. Also got this version to work, but repaints look more disturbed than the old method. I will keep the parts in the code documented if someone wants to switch back there eventually.

Done: Reworked the fallback Control display which uses BitmapPrimitives. Changed to display stuff unscaled, but also to take into account a square pixel upper limit for bitmap creation. If over that limit, a scaled bitmap is used. Made sure that in VCL PixelRenderer, the exact same pixel display gets created for Controls in edit mode. Small change to avoid always rendering the fallback visualisation behind the Control in life mode.

Done: Add Entry to DrawingLayer configuration to define that MaxSquarePixelLimit for Controls and implement it's usage. Added to configuration and implemented in SvtOptionsDrawinglayer. Used in ControlPrimitive2D::createLocalDecomposition. Wors as intended. Default is 300x150 Pixels which leads to 45000 Pixels.

Done: Add Entry to DrawingLayer configuration to define that MaxSquarePixelLimit for 3D Scenes (similar to this, so here ATM) and implement it's usage. Added to configuration and implemented in SvtOptionsDrawinglayer. Used in ScenePrimitive2D::createLocalDecomposition. Default is 1000x1000 Pixels -> 1000000 square Pixels.

Done: Still keeping an eye on this one and doing experiments. Did that, found no obvious problems. Moving to done-list.


P1: During Text Edit using the old EditEngineView, text display needs to be suppressed for Primitive display

 Candidate: AW
 TimeEffort: 1 Week
 Clearness: 1

Done: Think about and implement a clean way to hide text at objects which is in edit mode to not have display problems (double display). It may also be possible to gray out the current text during edit to visualize the current changes in edit mode. Just an idea, needs to be tested visually, may be too disturbing. Added simple support to just hide it based on IsInEditMode() in SdrTextObj. Used in drawinglayer::primitive2d::createNewSdrTextAttribute which itself is used as tooling during decomposition of high leven primitives which contain text. Works well. For the moment i think experiments with graying out or similar are not necessary.


P1: In sd, the slide pane transition to primitives needs to be completed. I created a high-level primitive which does the most necessary things like creating two frames visualizing the outer and inner border and adding the cached bitmap of the page visualisation.

 Candidate: AF, AW
 TimeEffort: 1 Week
 Clearness: 2

Done: Created a first implementation to handle the Page Previews in the Page Pane as Primitive. This includes implementing a sample Primitive fo that purpose in SD. This Primitive is view-dependent and decomposes to the needed Bitmap, frame, etc. Content. I just added showing the bitmap, inner and outer frame to demonstrate usage. Things will get easier when PagePane uses Overlay to show the interaction stuff.

Done: Changed the creation of the BitmapPrimitive which holds the bitmap visualisation to directly use the bitmap pixel size so that no scaling will happen. This works even with the enlarged bitmaps when enlarging the PagePane since the old bitmaps are reused, but already scaled at this stage.

Done: Maybe i open a CWS to first transform the hilighting stuff to Overlays. This would greatly simplify transition of the visualisation to Primitives. This would normally be a job for AF. Talked with AF, he will do the Overlay transitions in SD ASAP. Sent him an eMail with Overlay descriptions and how to use them. Also CL in copy, maybe new tipps for his usage of OverlayObjects are included.

Done: Waiting for AF's transition to OverlayObjects in SD. AF is making good progress. AF has done a first transition and moved some indicators and especially the XPR painting frames and the selection frame to Overlay. This is added to aw054. I joined it from there to aw033. This is the needed preparation to do the transition for the PagePreviews to primitives. Unfortunately AF did not move the object selection itself (the big blue Frame around the PagePreview) and the FocusIndicator (a Black/white dotted line) to the Overlay what i would have preferred. We had different opinions about that. Fact is that i need to move those to Primitives additionally and that they are painted/visualized together with the PagePreviewObject. From this follows that these object needs to be repainted when Selection and/or Focus changes. This would not be necessary with OverlayObjects.

Done: With the Overlay changes of AF ongoing, i know what parts need to be done by the displaying primitive. I can start to add the PageNumber, Page transition indicator and other stuff. Started the transition, first progress going on. Still missing is Slide Number and Slide Name. Also i need to be very critical with the exact pixel visualisation.

Done: Converted the SD PagePreview stuff to primitives. No easy task due to mixed visualisation of selections and pixel-oriented requirements. Works well. The state now is: The PreviewBitmap, the Selection, the Focus, the FadeEffect icon, the Slide Name and the Slide number are now visualized by a SdPageObjectPrimitive. The rest is done at the overlay. The overlay stuff will be converted to primitives later.

Done: There are two extra functionalities. One is to shorten the slide name text when too long (and always doing as if a fade effect indicator is used, so always leave space to the left) by using three points. Up to now i implemented this using a text clipper. The other is a box around the slide number and a strikethrough from top left to bottom right when the slide is excluded. Both need to be rebuild whereby the text shortening will be the hard part, this is currently used/implemented at the OutputDevice. It will need the UNO API TextIterator. Both work well now, checked in. I thoroughly tested the Primitive-based display. Looks good. I stumbled above often new decomposition of SdPageObjectPrimitive, but this is due to the already mentioned inclusion of selection and focus ndicator visualisation. I can only ask AF again to change that to OverlayObects, that would remove this unnecessary stuff.


P1: Stroke polygons with just one pixel effective output width need extra handling

 Candidate: AW
 TimeEffort: 1 Day
 Clearness: 1

Done: Problem is that stroke polygons which end up in 1 pixel size are not correctly painted when they are decomposed to filled polygons. Those filled polygons are geometrically correct by themselves, but since the bottom-right edge is not painted, they are painted too thin. A one pixel wide stroke will have holes. Thus, i need to handle them in the VCL PixelRenderer and directly paint them when they are < 1.0 pixels wide. Added needed code to the VCL renderer. Fallback is only done on None-AA views. Works pretty well. Code forces fallback to hairline when 0.0 < LineWidth < 1.5 discrete units and to quad hairline (three extra hairlines with one pixel offset) for 1.5 < LineWidth < 2.5.

Done: Check if this is needed at all for AA'ing views. Checked with the unxlngi6.pro version. All looks good and zooming is fine. No action needed for AA. This means: Do not execute the special fallbacks when AA is available -> this is some special handling, too.


P2: Base invalidates on ActionChanged().

 Candidate: AW
 TimeEffort: 2 Days
 Clearness: 1

ATM at a object repaint, the high-level primitive is created (normally it's just a view-independent, data-holding one, cheap to incarnate) and compared wit the current one by using it's operator==. This is a very safe mechanism which will always do the correct refreshes and only the necessary ones. Since the repaints are triggered currently by ActionChanged() at the VCs, this is not urgently necessary. It is also possible to get rid of the current Primitive Sequence at ActionChanged() and re-create it on demand on paint time. Need to test this one.

Done: It is good as it is. Getting rid of the PrimitiveSequence in ActionChanged() works of course, but this means to loose evtl. expensive decompositions, even if model has not changed (and thus the Primitive), but only a repaint was intended. No change here.


P1: The VCL 2D pixel renderer needs to control smoothing better in VCL. HDU already added B2DPolygon support methods in OutputDevice which AA, but there is no control on it ATM to switch it on/off at OutputDevice. This needs to be done for masked primitives where e.g. the mask itself may not be painted with AA.

 Candidate: HDU, AW
 TimeEffort: 1-2 Weeks (in progress already)
 Clearness: 1

Done: Discussed with HDU, he already added support for AA for unxlngi6, currently always on. To better control it, there is already a Set/GetAntialiasing method which sets a flag value (see ANTIALIASING_* values). ATM there is only one value for text, so this needs to be expanded. For wntmsci10, i have to discuss wit THB. Discussions are done, looks like we may get AA in unxlngi6, but not yet in wntmsci10. For wntmsci10 support, GDI+ would be needed for which adding control to VCL would be too expensive. So for wntmsci10 support may be added using a canvas primitive renderer earliest, maybe for 3.0 but not sure.

Done: I added another flag value for polygon rendering and THB is about to change VCL to support that switch value. HDU has updated VCL in aw033 to support the switch value.

Done: Add a AA flag to the DrawingLayer configuraion and base using AA or not on it. Added flag, is implemented in SvtOptionsDrawinglayer and used in VclPixelProcessor2D constructor to set the needed flag at the provided OutputDevice. I defaulted it to false, maybe this will be changed.

Done: When supporting AA, i need to think more about expanded BoundRects. This may need to be system- and view-specific, maybe a 2nd layer of BoundRects on VOC level. For a first try i will just expand the invalidate rectangles by one discrete view unit (Pixel). To test this i need to use the unxlngi6 version. This is currently updating and building. Added and checked, works pretty well.

Done: When supporting AA, it needs to be propagated by the VCL PixelRanderer when using sub-VDev's. This is true for the VDev content, not true for the mask and not true for alpha mask (?). Need to implement and experiment with it. Propagation itself is working.

Done: Examine masking. What to do if a sub-rasterdevice is used together with a 1-bit raster mask to e.g. create a ellipse filling? How can using pixel bounds for this be avoided? Can this be AA'ed at all? Indeed, as i guessed, this is a problem and looks very ugly.

Done: Find a solution when AA is on for masking operations (see point above). Discussed with HDU. There are several possibilities: (a) Adapt the VDev usage of the VCL-Renderer to evtl. mask with grayscale AlphaChannel and draw to mask with AA, too. (b) Handle Mask primitives different; Just set the mask polygon as ClipRegion. Method (b) would be the more convenient one since it's the graphic SubSystem which should do correct AA and masking. But with current VCL, there are a lot of problems there. The Polygons for ClipRegions are Integer. They are not completely supported when interfering/Mixing with ClipRegions built up with region bands. It's not sure how AA masking can be handed over to the current Sub-Systems. HDU and i are thinking about it and evaluating. I worked on the unxlngi6.pro version and solved that problems. In principle, the L helper BufferDevice i use (impBufferDevice) needed to be adapted to AA in copying AA flags to it's buffer and using the Alpha mask instead of the ask in AA mode. This works well for bitmap-filled objects and transparencies. For gradients, i needed to adapt the VCL GradientHelper. It is not possible to use the simple gradient painter since it uses XOR stuff to fastly blit the color steps. Instead, when AA is on, the PolyPolygonGradientPrimitive2D is not handled at all by the VCL renderer but decomposed and painted using the mask mechanism. For transparence and gradient transparences the mask mechanism also works well.

Done: Overlay needs to react on the AA-Mode, too. Also needs to work with the expanded invalidate rectangles when AA is used. Added needed code to OverlayManager and OverlayManagerBuffered. Need to check with unxlngi6.pro, though. Tested on unxlngi6.pro and added some corrections. Wotrks well so far. There is still a little glitch in leaving overlay geometry with drag lines when creating new objects. Added this to the Hint List, closing this point.


P1: Dashed and/or thick lines quality can be improved

 Candidate: AW
 TimeEffort: 2-4 Weeks
 Clearness: 1

When displaying dashed and/or thick lines (not hairlines) on the VCL PixelRenderer, they still look the same as now in contrast to hairlines of any form. This is due to the fact that the method for applying line dashing to a Polygon/PolyPolygon in basegfx (applyLineDashing) currently needs to subdivide bezier segments. For thick lines the problem is similar: The bezier segments get subdivided for geometry creation.

Done: Newly implemented an applyLineDashing with bezier segment support. It is now able to create line snippets and gaps in one piece which is very useful for e.g. black/white dash/dotted lines. It does also take care of extending the last two snippets (of each output) to a single geometry. For this a seperate tooling method was used before (which i also removed).

Done: For being able to work with length and length-oriented splits of bezier segments, i added B2DCubicBezierHelper to basegfx's beziertools (new files). It takes a B2DCubicBezier and prepares to work with it by subdividing and building up arrays for segment sub-lengths and bezier split values. The subdivision is based on an error value which defines the allowed distance between the outer and inner length of a bezier segment (direct edge and control point path). The decomposition and the given B2DCubicBezier is not kept (not copied), just the prepared length data is kept. With an incarnation of that class (where you can give the error value, default is 1%) it is possible to get the bezier segment length. This is better in quality than the given error value since for the sub-length calculation the medium of the outer and inner path is used. It is also possible to have some kind of bijective transformation between distance on segment and bezier split values (which is not linear). This is the precondition for dashing curves at all.

Done: Use B2DCubicBezierHelper in new applyLineDashing. Works well!

Done: Changed B2DCubicBezier::split to be able to only compute the right or left part or both. This was needed at many places anyways. Also added a B2DCubicBezier::snippet method to extract a part from the B2DCubicBezier from one split value to another. Replaced/optimized all usages of those two methods.

Done: Added a PolyPolygonHairlinePrimitive2D to drawinglayer. This is in principle syntactic sugar, but makes diverse primitive creators more simple since they only need to incarnate one PolyPolygon primitive instead of looping themselves over the single Polygons. Changed/adapted all places where this was useful.

Done: Use B2DCubicBezierHelper in old tooling places where ATM something similar is done using adaptiveSubdivideByCount to have a aequidistant calculation base. This was unfortunately not possible. I changed the B2DCubicBezierHelper to use adaptiveSubdivideByCount (default to 10) and make use of the aequidistant pieces. Thus i get a good semi-bijective projection between Bezier-Indices (0..1) and edge length. Experimenting showed that i get good results with about 10 subdivisions. The subdivisions are not kept, but only a length vector and binary search on it.

Done: For creating filled bezier polygons for line segments i need somehow 'simple' bezier segments. There are different criterias imaginable and i experimented with some. One aspect is cost of calculation of 'simple' and the number of subdivisions to achieve it. Currently i use a subdivision which produces sub-bezier segments with neither control vector deviations more than 30 degree from the edge and the summed lengths of the control vectors are less or equal the edge length. This is not too expensive, gives decent subdivisions and excludes self-intersectiong and/or too complicated bezier segments.

Done: Redesigned the interface to the bezier extrema finder (getAllExtremumPositions). It now adds the valid extremas ([0.0 .. 1.0]) to a given vector of doubles. Also added a method to get the minimum value (just call get all and use std::min_element). Adapted all usages of the old interface.

Done: Change/reimplement basegfx's createAreaGeometryForPolygon to work on and keep bezier segments as good as possible. This is not trivial. I have good solutions for mostly every situation, but still some problems in extreme cases. The criteria to decide that a segment is 'simple enough' to be expanded to a bezier polygon assembling the extruded line geometry is touch to formulate.

Done: Extended the polygon simplifier which is used as preparation for thick line geometry creation to use the extrema value calculator first. This avoids some problems and unnecessary subdivisions since splits at the extrema values are potentially better than splits at 0.5.

Done: Lot of changes/extensions to basegfx methods which manipulate ploygons. Adapted all used in the thick line extension methods to work with bezier curves. Tough, but works now.

Done: While checking old Fontwork (Text on curve) i detected some problems with the more complicated modes offered there (the sheared stuff). During looking for the reason (linear combination of matrices did not work ?!?) i had to dig as deep as finding that there is still a problem with matrix decomposition. Under a combination of circumstances, the mirrorring in X and/or Y (negative singn of scalings) could get lost when decomposing/recombining a matrix. Since this is necessary when working with text primitives (the scale needs to be removed, it's part of the evtl. extracted outline polygons) it makes problems. Fixed that and also took the time to no longer need to call the 3D decompose when shear is involved. Since this is a evtl. severe porblem, i added task #i83695# for early fixing this in the master version (target 2.4). Also added unit test now for decompose/compose cycles of matrix to basegfx.

Done: Reworked decomposition of simple text primitive due to some restrictions when getting Font outlines from VCL. Is much more reliable now. Also adapted the VCL renderer to get the correctly scaled font under windows when font width and height are used (width != height), also a caveat for just the windows verstion.

Done: adapted all users to new ApplyLineDashing, old code removed. There will potentially be more bezier usages now, i need to build incompatible from basegfx and take a look. Build is running.

Done: I have two different requests for evtl. buffering the subdivided polygon at the polygon to solve performance and bezier handling problems now. This way to solve is pragmatic, but does allow better performance and also opens an always possible way to handle bezier problems as polygon problems for fast solutions. It will still be better to have a clean mathematical solution, but in the open cases this is not trivial, e.g. isInEpsilonRange (which leads to an equation system of 5th degree). Thus i now added polygon subdivision buffering at polygon level. To not always subdivide the whole polygon, granularity is on edges which corresponds with single bezier segments. Also added some convenience bezier segment handling methods to B2DPolygon in that effort (isBezierSegment(), getBezierSegment()). The method is appendDefaultSubdivision() at B2DPolygon which will create/append the needed subdivision points to the given target polygon without start and end point of that segment. To also allow to get the complete segment decomposed, i added getSubdividedEdge() which will always do the right thing (bezier or not, edge exists or not), see documentation in B2DPolygon.hxx. Tested that stuff, works well. Adapted all subdivisions to the new methodology where it makes sense. Also works well.

Done: The above described buffering of subdivision worked nice and on a granularity of single bezier edges, but valgrind shows that most common cases will iterate over the full polygon anyways, so there is no need for that granularity. Further, when rewuesting the decomposed polygon, most time (much less tha before, but) is now spent in concatenating the buffered data to the asked polygon. So i decided to completely change/rework and simplify this buffering. There is now support for getDefaultAdaptiveSubdivision() at tne B2DPolygon which will return itself when no bezier at all or forward to the implementation class which will create, buffer and return the subdivision. This is done at the creation class to hold buffering over polygon return by value or polygon copying. It avoids recombination of data (the result is directly buffered as B2DPolygon), guarantees fast returns and great simplification (e.g. the buffer data creator now just used tools::adaptiveSubdivideByCount() and may be adapted to other toolings if needed).

Done: When converting to contour, thick line parts really get bezier polygons. This opens a performance problem since isInside() - methods in basegfx tooling still are not adapted to bezier usage and subdivide polygons for tests each time. There are two possible solutions: (a) Adapt isInside() to bezier usage (will do this first and check performance) (b) Implement a getDefaultSubdivision() at the B2DPolygon, buffer and use it for all common tasks where fallback to non-bezier polygons is sufficient The unxlngi6.pro build is ready and i used callgrind and kcachegrind to take a look. Most time is consumed in isInEpsilonRange() which also needs to subdivide the contained bezier segments. Looking for a solution. As written above, i now have added support fur buffered subdivisions at B2DPolygon (solution (b)). This solves the performance problem.

Done: As i was at it and buffering default subdivision and B2DRange of the polygon are related (in the sense where to flushthe buffer since both rely on the pure geometry) i abstracted the data buffering in B2DPolygon and added the polygon range. Changed tools::getRange() to use polygon internal, buffered range now. This will speed up a lot of the inside/outside/overlap actions.

Done: I saw that for conversions to contour still the newly available best quality is not used, looking for why this happens. The polygons still get decomposed somewhere, examining this. Found some places in the old svdraw codes and adapted them accordingly. Indeed, there was one unecessary decomposition left, but there were also places in ConvertToContourObj where a reduction (simplifyCurveSegments) was needed. The main object gets converted by ConvertToPolyObj which creates bezier control vectors even for straight edges. Since this is the method which is also used when converting oplygons to curve, this is wanted and necessary. Inside ConvertToContourObj is the right place to reduce again straight bezier segments. Works all well now.

Done: I stumbled upon that the merge of polygon objects ATM does not merge polygons which do not really intersect but just touch. Need to check that. Maybe this is identical to #i81852#. Investigating on this one. It IS an error and needs to be fixed. This is very tricky, polygon-to-polygon topology including beziers is not an easy task. This error was introduced with expanding clipping to beziers and needs to be fixed early in the master. Adding the task to aw054 and fixing there.

Done: I used the clipping stuff from B2DPolygonClipper.cxx in basegfx, e.g. clipPolygonOnPolyPolygon and clipPolyPolygonOnRange. The range clipping is done with clipping against all four axes which define the range. This only works for inside stuff, though. Since the clip functions offer a switch to get the outside (bool bInside = false), i need to correct that stuff and add fallbacks to polygon clipper. Also need to expand to bezier handling. Also need to correct/check the polygon clipper which uses SolveCrossovers(). Corrected and reworked the clipping functions to decide and do the right thing for all situations. E.g. when clipping a PolyPolygon against a range (Rectangle) and the outside part is wanted, this now falls back to PolyPolygon on PolyPolygon clipping which uses the full topological information. This is also done for line mode; it would be possible here to clip four times against the rectangle bounds, but would need to merge the result since unwanted cuts would have been added along the endless rays. The fallback for lines only will use an enter/leave algo anyways. Also improved all clipping methods to work with bezier segments (this was the hard part).

Done: Reworked the polygon clipping basic functionality due to #i81852#. Implemented and checked the ezier modes. Works now. Added basic clipping operations to basegfx (AND, OR, XOR, DIFF). Adapted all clipping usages to new stuff.

Done: When AA is on, the thick lines have a much better quality, but - eventually dependent from the system we run on - the edges where the line polygons meet, do not close completely, even when they are geometrically correct. Need to check this and evtl. find a workaround. One possibility will be to extend line segment length by 1 or 1/2 half pixel, but this will make line geometry creation view-dependent. Still thinking about a possibility to not get view-dependent. I now tested a simple solution for AA; just do not only paint the generated thick line geometry, but also the same geometry unfilled which closes the gaps. Works well. Teste again, speed is okay.


P1: Check and implement used display modes 'Gray' and 'Black&White'. Also take a look at HighContrast and color usage when Printing/PDFExporting

 Candidate: AW
 TimeEffort: 2-3 Weeks
 Clearness: 1

Done: Checked. When using the VCL renderer this works pretty well since VCL still applies the modes to the primitives it draws.

Done: One drawback encountered: When using thick lines, the VCL renderer does not use the falback color for lines since they are painted as filled polygons. Need to temporarily change DrawModes here when in HighContrast/Gray/B&W modes. Added taking teporarily over the draw modes for line/fill and text. Impleneted for text and line mode rendering. Added to the VCL renderers, works well.


P1: Use VCL's DrawTransparent for polygons with unfied transparence instead of current Buffer-VDev usage. This may potentially speed up unified transparence paints.

 Candidate: AW
 TimeEffort: 4-7 Days
 Clearness: 1

Done: Added code to the VCL PixelProcessor to directly use OutputDevice::DrawTransparent when the UnifiedAlphaPrimitive2D contains exactly one primitive of type PolyPolygonColorPrimitive2D. This works well, but i cannot activate it since OutputDevice::DrawTransparent still uses the old tools::polygon definitions and thus will look ugly and maybe AA will not work.

Done: Informed HDU that OutputDevice::DrawTransparent needs to be adapted to B2DPolyPolygon processing. He will evaluate if this is expensive or not. If he can adapt it, i need to change the default in VCL PixelRenderer to use OutputDevice::DrawTransparent directly (see static bAllowUsingDrawTransparent flag). HDU checked the possibilities and reports that it will take 2-3 working days to add the necessary stuff, probably after christmas. Until then i keep the option disabled. Worked today with HDU on this feature for some time, we tried to add it to VCL smoothly. Most of the stuff is in place, but even with setting the correct XRenderColor (with alpha) the result is smoothed but not transparent. HDU needs to do more investigation, but will be on holiday until next Year. Done now with aw063.

Done: HDU still had no time to do this, preparations are committed in VCL pixel renderer. Still HDU had no time (and also no X ATM). Done now in aw063; VCL supports basic transparence rendering for all systems now, and it is used by the renderers.


P1: Do some speed tests to identify bottlenecks

 Candidate: AW
 TimeEffort: 1 Week
 Clearness: 1

Done: Use a unxlngi6.pro version to do some scheduling for repaint times on a linux machine. Use valgrind,callgrind and kcachegrind. Made first speed tests. kcachegrind does not show any extremely bottlenecks what is good. Anyways it gives some suggestions, see todo's.

Done: Used the resynched and freshly build SRC680 m232 version for first tests. Committed all changes and rebuilding current version. Used that version for first valgrind tests.

Done: HDU made some good suggestions, ne is a specialized getRange() for B2DPolygon with curves. This would include to only decompose curve parts which are outside the bounds without control points. Good suggestion. Implemented and tested this, works well. Also reworked the extrema calculating method for bezier segments to make it more widely usable. Also change getRange() from basegfx polygon tooling to get the real bezier range by default and added a getRangeWithControlPoints() for the other case. Discussed and checked with THB, no cases known where getRangeWithControlPoints() is explicitely needed for now, thus this change is safe. Identifying all adaptiveSubdivideByAngle() calls which were just done due to getting the correct range from a bezier polygon and removing them. Due to the fact that i now use a real extrema calculation when a bezier overlaps the current range, we now get a range for beziers which is more precise than ever before.

Done: HDUs hint: DrawPolyPolygon is too often called with tools::PolyPolygon which is not necessary anymore if a B2DPolygon is available. Needs to be checked. Ckecked this. No transitions to tools:Polygon are done in the VCL pixel renderer; need to debug this one. Checked this one, i found no more usages when primitive renderer is in place.

Done: Valgrind lead to buffering of dfault decomposition and range at the polygon which solved all performance stuff here. The most time consuming job now is the VCL PolyPolygon painting on X which needs to dismantle the polygons to trapezoids. Before this is done, all self-intersections need to be solved, too. This is the expensive part. Together with HDU we added a clipping against the visible parts so that a much smaller part of the polygons needs to be processed. I am really surprised that X can only render triangles/TriangleStripes and trapezoids when painting filled polygons..:-(

Done: HDUs hint: BitmapEx::Scale() and indirectly ImplScaleFast() is called too often and with nearly no scaling at all. Might be a slight numerical problem which leads to unnecessary scaling. Needs to be checked. Checked and does not happen anymore. Again adapted 3D scene decomposition to create an aligned bitmap which will not be scaled at render time but perfectly fits the target pixel region.

Done: Do more valgrind tests, interpret the results. A first possibility to enchance performance is to provide a default AdaptiveSubdivide for B2DPolygon which would be buffered at the polygon incarnation itself to avoid evtl. multiple decompositions. Added getDefaultAdaptiveSubdivision() directly to B2DPolygon, see description there.

Done: Page pane content is shown slower than on original version. I did some valgrind tests on unxlngi6.pro version, but couldn't identify something concrete. Need to look again on this. Found reason, it is a conflict between primitive sequence usage and current frefresh using ModelChange events and completely rebuilding PagePane view. Currently solved this with staying at the ModelChange method. Added a deelp description to SLSPageObjectViewObjectContact.cxx in Sd and discussed with AF that we will need to solve this more general after aw033 integration.

Done: Did some fresh callgrind checks on newest unxlngi6.pro build with and without AA activated. Pretty much the same when looking at basegfx and drawinglayer, no obvious differences. Main costs are now on isInside used by solving OR-operations on polygons (from VCL painting). Check/optimize isInside() eventually (solve isPointOnPolygon internally there?). Again tested on the new m12 and looks good.

Done: Ongoing tests with callgrind using the most current unxlngi6.pro version. No extremely visible bottlenecks encountered. Maybe getB2DRangeFromPrimitive2DSequence() calls should be buffered better; this means to locally buffer the calculated BoundRects more at the instances which use that call. Changed to buffering B2DRange creation as fix in aw063.


P2: Remove XOutputDevice

 Candidate: AW
 TimeEffort: 1 Week
 Clearness: 1

Done: Time to completely remove the XOutputDevice from svx (which did all the old rendering stuff/hacks in a similar manner to VCL). Needed to remove last usages of XOutputDevice from Dialogs (used as previews for fill, hatch and similar stuff). Needed to remove usage from StyleLists (LineStyle, FillStyle, Gradient list, etc). Needed to remove in SD from PageNumber dialog preview. All removals checked and tested for their correct optical representation. XOutputDvice completely removed! Yippieh!


P2: Remove OC's, VOC's and VC's PrepareDelete()

 Candidate: AW
 TimeEffort: 1 Week
 Clearness: 1

Done: Cleanup and siplification of the ViewObjectContact mechanism. After first simplifications there was no reason left for the used PrepareDelete() method at VOCs (ViewObjectContacts), VCs (ViewContacts) and OCs (ObjectContacts). It was primarily used as pre-destructors as virtual functions to not run into the officcial destructrors' weakness to not be able to call local virtual functions. Removed and migrated all PrepareDelete()s to the destructors. At some places PrepareDelete was used to flush the current incarnations of all VOCs for a VC, replaced this with the possibility to flush (delete, these objects are created-on-demand anyways) the current incranation of a VC at the corresponding model objects (Page, MasterPage and SdrObject). PrepareDelete() comletely removed.


P2: Test SW scrolling with many controls (was: CR 6673211)

 Candidate: AW, FS
 Clearness: 1


Done: This is a after-integration task. Checked, works well. P2: Stuff from stripping moved to Done/Todo later

 Candidate: AW, FS
 Clearness: 1

-Done: ImplGet3DLineGeometry->ImpGetShadowPolygon -> CWS aw059

-Done: Base3D removal (dialogs, etc) -> CWS aw059

-Done: Base3D removal : replace in dialogs (SvxPreviewCtl3D), also in VCL and goodies

-Done: SdrObject::ImpConvertToContourObj without CreateLinePoly to get rid of CreateLinePoly, SdrLineGeometry

Created a 2D renderer which extracts the line geometry; the thick expanded line one and the hairline one. Tested in ImpConvertToContourObj and it works well. Needed to extend the geometric DoConvertToPolyObj for SdrMeasureObj to also inherit the Stale settings to newly created objects. Thinking about getting rid of that geometry changing stuff and eventually do a conversion completely using primitive decompositions, so i keep this one on Todo. Done now in CWS aw059. Still not completely on primitives, but preparations are done.

Personal tools