ANN: ongoing emf+ parser & rendering rework

classic Classic list List threaded Threaded
5 messages Options
Thorsten Behrens-6 Thorsten Behrens-6
Reply | Threaded
Open this post in threaded view
|

ANN: ongoing emf+ parser & rendering rework

Dear fellow hackers,

as of Saturday, a first cut of a new emf+ parser & rendering framework
from Armin has hit master (thx to Moggi and Stephan for fixing up the
ODR / unit test breakage fallout!).

The old implementation is a source of significant pain & issues
(separate implementation, only able to render into offscreen bitmaps,
no real vector, incomplete import etc etc). There have been various
efforts & plans in the past to address that (some of the heroes of
fixing the existing impl, and those interested in a rewrite in Cc) -
so I'm most happy to announce that the Technical University Dresden /
Germany stepped up & in the person of Prof. Oliver Sander is funding
this re-factoring.

That out of the way, here's how to play with it & hack it:

* in recent master (Tuesday or later, to avoid unit test issues)
* get yourself a dbgutil build
* either change in the cxx, or set in the debugger:
  bTestEMFPDecomposition to true
  (drawinglayer/source/processor2d/vclpixelprocessor2d.cxx:500
  currently)
* of course stick an emf+ graphic into your document ;)
* for directly comparing old vs. new, also set bUseChangedColorObject
  to true (gets you a blended overlay for new and old renderer)

Right now, it's all pretty bare-bones - technically, wmf/emf/emf+
parsers have been moved to emfio, and code is in place to convert wmf
& friends data into a vector scene graph just like svg is currently
imported & rendered. End-to-end, currently only polygons and colors
are working though - any help to expand functionality there
appreciated. But the framework & preparation work has landed now,
including carrying the original binary files around for proper
roundtrips, and holding a buffered preview graphic for quick repaints.

Next steps (again, help much appreciated!):

- add more GraphicPrimitive generators, complete up to a state that
  the filter at least covers what the current direct canvas renderer
  delivers:
   * clip regions
   * text rendering - it's parsed, but graphic primitive generation is
     missing
   * gradients/hatches
- once this works, cut over to new impl, bin the old code in cppcanvas
  (there's sadly a small amount of duplicate code now in the parsers)
- iteratively expand, to cover near-100% of EMF+ (mostly lacking around
  gradients & effects):
   * more complex fill types like bitmaps/tiles
   * path gradient
   * xor & stuff

Cheers,

-- Thorsten

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice

signature.asc (968 bytes) Download Attachment
Thorsten Behrens-6 Thorsten Behrens-6
Reply | Threaded
Open this post in threaded view
|

Re: ANN: ongoing emf+ parser & rendering rework

I wrote:

> Next steps (again, help much appreciated!):
>
> - add more GraphicPrimitive generators, complete up to a state that
>   the filter at least covers what the current direct canvas renderer
>   delivers:
>    * clip regions
>    * text rendering - it's parsed, but graphic primitive generation is
>      missing
>    * gradients/hatches
>
That's now done to a point where we're ~on par with the old renderer's
functionality - thx to Patrick, Noel and Armin for all the nice work!

> - once this works, cut over to new impl, bin the old code in cppcanvas
>   (there's sadly a small amount of duplicate code now in the parsers)
> - iteratively expand, to cover near-100% of EMF+ (mostly lacking around
>   gradients & effects):
>    * more complex fill types like bitmaps/tiles
>    * path gradient
>    * xor & stuff
>
That cut-over has now happened with

https://cgit.freedesktop.org/libreoffice/core/commit/?id=ebc11ae0b132eefd3b1b1a837a8d0ad3ba73b460

, also killing the functionality to compare the two renderers - if you
still need that, it's a rather smallish revert for now.

Next up is cleansing the old renderer under cppcanvas, I suspect
there's some easy wins there for easy hackers. :)

Cheers,

-- Thorsten

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice

signature.asc (968 bytes) Download Attachment
Armin Le Grand-2 Armin Le Grand-2
Reply | Threaded
Open this post in threaded view
|

Re: ANN: ongoing emf+ parser & rendering rework

Hiho,

here are some cleanup start points:

- m_bUseCanvas: no longer needed, no longetr interesting from outside
Metafile
- ImplPlayWithRenderer: should be removed. Adding a warning in
Metafile::Play for comments with GDIPLUS which guides to use primitive
renderer for better handling would be nice to add
- MtfRenderer: The hard part. com\sun\star\rendering\MtfRenderer.idl and
com\sun\star\rendering\MtfRenderer.idl and their should be removed. It's
not an official API and should be safe to remove
- there may be more as consequence of these...as always ;-)

Of course some UnitTests would be nice, too, best with EMF+ test data
files which make use of the new stuff.

As Thorsten already stated: Help much appreciated!

Regards,

Armin (alg)


Am 22.08.2017 um 12:48 schrieb Thorsten Behrens:

> I wrote:
>> Next steps (again, help much appreciated!):
>>
>> - add more GraphicPrimitive generators, complete up to a state that
>>    the filter at least covers what the current direct canvas renderer
>>    delivers:
>>     * clip regions
>>     * text rendering - it's parsed, but graphic primitive generation is
>>       missing
>>     * gradients/hatches
>>
> That's now done to a point where we're ~on par with the old renderer's
> functionality - thx to Patrick, Noel and Armin for all the nice work!
>
>> - once this works, cut over to new impl, bin the old code in cppcanvas
>>    (there's sadly a small amount of duplicate code now in the parsers)
>> - iteratively expand, to cover near-100% of EMF+ (mostly lacking around
>>    gradients & effects):
>>     * more complex fill types like bitmaps/tiles
>>     * path gradient
>>     * xor & stuff
>>
> That cut-over has now happened with
>
> https://cgit.freedesktop.org/libreoffice/core/commit/?id=ebc11ae0b132eefd3b1b1a837a8d0ad3ba73b460
>
> , also killing the functionality to compare the two renderers - if you
> still need that, it's a rather smallish revert for now.
>
> Next up is cleansing the old renderer under cppcanvas, I suspect
> there's some easy wins there for easy hackers. :)
>
> Cheers,
>
> -- Thorsten

--
ALG (PGP Key: EE1C 4B3F E751 D8BC C485 DEC1 3C59 F953 D81C F4A2)

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Chris Sherlock Chris Sherlock
Reply | Threaded
Open this post in threaded view
|

Re: ANN: ongoing emf+ parser & rendering rework



On Tue, Aug 22, 2017 at 11:30 PM, Armin Le Grand <[hidden email]> wrote:
Hiho,

here are some cleanup start points:

- m_bUseCanvas: no longer needed, no longetr interesting from outside Metafile
- ImplPlayWithRenderer: should be removed. Adding a warning in Metafile::Play for comments with GDIPLUS which guides to use primitive renderer for better handling would be nice to add
- MtfRenderer: The hard part. com\sun\star\rendering\MtfRenderer.idl and com\sun\star\rendering\MtfRenderer.idl and their should be removed. It's not an official API and should be safe to remove
- there may be more as consequence of these...as always ;-)

Of course some UnitTests would be nice, too, best with EMF+ test data files which make use of the new stuff.

As Thorsten already stated: Help much appreciated!

Regards,

Armin (alg)


How hard would it be to move the workbench example in VCL to use this?


 

Am 22.08.2017 um 12:48 schrieb Thorsten Behrens:
I wrote:
Next steps (again, help much appreciated!):

- add more GraphicPrimitive generators, complete up to a state that
   the filter at least covers what the current direct canvas renderer
   delivers:
    * clip regions
    * text rendering - it's parsed, but graphic primitive generation is
      missing
    * gradients/hatches

That's now done to a point where we're ~on par with the old renderer's
functionality - thx to Patrick, Noel and Armin for all the nice work!

- once this works, cut over to new impl, bin the old code in cppcanvas
   (there's sadly a small amount of duplicate code now in the parsers)
- iteratively expand, to cover near-100% of EMF+ (mostly lacking around
   gradients & effects):
    * more complex fill types like bitmaps/tiles
    * path gradient
    * xor & stuff

That cut-over has now happened with

https://cgit.freedesktop.org/libreoffice/core/commit/?id=ebc11ae0b132eefd3b1b1a837a8d0ad3ba73b460

, also killing the functionality to compare the two renderers - if you
still need that, it's a rather smallish revert for now.

Next up is cleansing the old renderer under cppcanvas, I suspect
there's some easy wins there for easy hackers. :)

Cheers,

-- Thorsten

--
ALG (PGP Key: EE1C 4B3F E751 D8BC C485 DEC1 3C59 F953 D81C F4A2)

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice


_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Armin Le Grand-2 Armin Le Grand-2
Reply | Threaded
Open this post in threaded view
|

Re: ANN: ongoing emf+ parser & rendering rework

Hi Chris,

Am 23.08.2017 um 03:58 schrieb Chris Sherlock:


On Tue, Aug 22, 2017 at 11:30 PM, Armin Le Grand <[hidden email]> wrote:
Hiho,

here are some cleanup start points:

- m_bUseCanvas: no longer needed, no longetr interesting from outside Metafile
- ImplPlayWithRenderer: should be removed. Adding a warning in Metafile::Play for comments with GDIPLUS which guides to use primitive renderer for better handling would be nice to add
- MtfRenderer: The hard part. com\sun\star\rendering\MtfRenderer.idl and com\sun\star\rendering\MtfRenderer.idl and their should be removed. It's not an official API and should be safe to remove
- there may be more as consequence of these...as always ;-)

Of course some UnitTests would be nice, too, best with EMF+ test data files which make use of the new stuff.

As Thorsten already stated: Help much appreciated!

Regards,

Armin (alg)


How hard would it be to move the workbench example in VCL to use this?



Not too hard - indirectly it will partially use it already, it will read the metafile (ReadWindowMetafile), but still paint it as metafile using vcl (maMtf.Play).
Instead you may use a Graphic (which you construct using the Metafile)/GraphicObject (which you construct using the Graphic), and something like in paintGraphicUsingPrimitivesHelper/paintUsingPrimitivesHelper like in sw, but only the parts that construct the drawinglayer::primitive2d::GraphicPrimitive2D.
You may also directly use a drawinglayer::primitive2d::MetafilePrimitive2D, then you only need the transformation and the Metafile, and a drawinglayer::processor2d::BaseProcessor2D (best is to use drawinglayer::processor2d::createProcessor2DFromOutputDevice, that will do all stuff for you).

HTH!
Regards, Armin
--
ALG (PGP Key: EE1C 4B3F E751 D8BC C485 DEC1 3C59 F953 D81C F4A2)

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice