openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio.Wang" <>
Subject Re: Drawing layer performance issue
Date Thu, 17 May 2012 03:07:02 GMT
Hi Armin,
What you've done is a pretty great work.

Here is my focus area about drawing layer:
1. Refreshment
     #Currently, when refresh the window (for example, just minise and then
restore), many primitives will be created again. That will cause some
effort waste during this process. I wonder why we could not keep the
primitive unchanged and just repaint it?

2. System-specific renderers
    #This is the most intreset point of my care,  since different base
renderers especially hardware releated ones works in different ways, if the
drawing layer become more universal for high level APIs, it'll need more
work to seperate the universal items into specific items and process, and
then it could use the best performance of those System-specific renderers.
That's really a render engine work should do.

      As far as I know a render engine contains 6 basic parts at least:
Primitives, GraphicObjects, GraphicTree, Universal Rendering Process,
Universal rendering APIs to encapsulate Specific plantform rendering APIs.
The primitive is the most base items for a render engine, if our work now
is focus on the primitive converting, I think it is still a long long
way to reach the final target.
     What we mainly focus is the office production, and the the rendering
engine is a module which function is very independent, so why don't we just
to use a mature third party ones, and save lots of time and effort to do
our "professional" things? "Professional ones do professional things" is my
view, we are not a render engine group after all. :-)


2012/5/16 Armin Le Grand <>

>        Hi Liang and Antonio,
> On 16.05.2012 03:00, Liang Weike wrote:
>> Hi,
>> On 2012-5-15 22:31, Armin Le Grand wrote:
>>> Hi Antonio Wang,
>>> On 15.05.2012 10:44,  wrote:
>>>> Hi,
>>>> Currently the performance of drawing layer is not good enough.
>>> Yes, that's true :-)
>> And what is the percentage it takes within the whole performance?
>>>  Does anybody know that is it possible to use a mature third-party
>>>> graphic
>>>> component to replace drawing laywer for improving performance?
>>> Yes, I know that it's not s easy. I'm preparing this for years. Do not
>>> forget that DrawingLayer has many components (model, viewer to which
>>> you probably refer, controller) and is used hardcoded from 14 users
>>> (not only the visible apps, also dialogs, helpers, etc.). Also it's
>>> used on (at least) five systems. It's going in the right direction,
>>> but is ongoing work which will need some more time. I'm on it...
>>> HTH!
>> I'm interested in it,too. Could you please introduce the work that you
>> have done and the plan in the future? Thanks!
> I am working on the code for 15 years, concentrating on the DrawingLayer.
> I have added primitives (see****
> DrawingPrimitives<>)
> and e.g. the new SVG import based on them. All graphic rendering is done
> using primitives now (leaded to AntiAliasing). I am currently working on
> aw080 which will make further deep core changes (preparing some docu on it
> currently, will send a note if done) the code is at
> This will bring us closer to more safe DrawingLayer core objects.
> The future plan is to:
> - convert as many as possible components to primitive usage, e.g.
> SlideShow, exports (PDF, SVG, printing, ...)
> - Implement generic system-specific renderers for visualisation of
> primitives
> Of course the prerequisite is to have all graphical output based on
> primitives. Draw/Impress is, Chart is, DrawingLayer objects in Writer and
> Calc are. Missing is EditEngine in edit mode, cells and text in calc, text
> in writer.
> HTH!
>>>> Antonio.Wang
>>> Sincerely,
>>> Armin
>>> --
>>> ALG
> Sincerely,
>        Armin
> --

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message