You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by 王 <ki...@gmail.com> on 2012/05/15 10:44:40 UTC
Drawing layer performance issue
Hi,
Currently the performance of drawing layer is not good enough.
Does anybody know that is it possible to use a mature third-party graphic
component to replace drawing laywer for improving performance?
Antonio.Wang
Re: Drawing layer performance issue
Posted by Armin Le Grand <Ar...@me.com>.
Hi Antonio,
"Antonio.Wang" <ki...@gmail.com> wrote:
> 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?
That's one of the paradigm changes I've made in aw080 already. Background:
When doing primitives this was my first concept, but it showed that the
other needed mechanism - to detect core changes and ensure recreation of
the primitive - did not work reliably. Thus, the safest was to create the
most high-level primitive, compare it with the existing one and detect
every evtl. change reliably. Remark that the old primitive is used in the
most no-change case, thus all the decompositiopns and the low-level
primitives are reused most of the time.
Done in aw080, plus the needed ensurement of invalidations.
But anyways, that's not where the time is spent, see
https://issues.apache.org/ooo/show_bug.cgi?id=118984
> 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.
That's true, but a lot of preps need to be done for that. The idea is to
not use sal/vcl at all, but to use UNO API renderer modules on surfaces
(API will hand over handle to window (however) the sequence of primitives
and info (transformation, etc.)). For each OS a UNO API module should be
implemented containing a renderer implementation (see drawinglayer module).
To be able to do so, the surfaces which are created from vcl as Window need
to be controlled, too. E.g. on win ther will not be the fastest renderiung
when the Window implementation creates just any HDC-type, but not e.g. a 3d
surdace one. OTOH Vcl will always have to work on that surfaces, too
(EditEngine paints, controls, ...) and the rendering will me a mixture of
both accesses.
> 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.
It is, but I'm on it. We should evtl. clarify the terms you used, they do
not match 1005 of the stuff in the source and/or the current mechanisms
work.
> 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. :-)
Also true. Do you have any idea what renmderer would be best to use under
Linux? AA is needed, speed of course, and it should be able to paint
PolyPolygons (what X is not,, argh...). I see no big problems of choosing
on Win and Mac, and we still have the Vcl fallback which is used today...
HTH!
Sincerely,
Armin
> Antonio
>
> 2012/5/16 Armin Le Grand <Ar...@me.com>
>
>> Hi Liang and Antonio,
>>
>>
[..]
>> --
>> ALG
>>
>>
--
ALG
Re: Drawing layer performance issue
Posted by "Antonio.Wang" <ki...@gmail.com>.
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. :-)
Antonio
2012/5/16 Armin Le Grand <Ar...@me.com>
> 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 http://wiki.services.**openoffice.org/wiki/**
> DrawingPrimitives<http://wiki.services.openoffice.org/wiki/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
> https://svn.apache.org/repos/**asf/incubator/ooo/branches/**alg/aw080/<https://svn.apache.org/repos/asf/incubator/ooo/branches/alg/aw080/>.
> 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
> --
> ALG
>
>
Re: Drawing layer performance issue
Posted by Armin Le Grand <Ar...@me.com>.
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
http://wiki.services.openoffice.org/wiki/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
https://svn.apache.org/repos/asf/incubator/ooo/branches/alg/aw080/. 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
--
ALG
Re: Drawing layer performance issue
Posted by 王 <ki...@gmail.com>.
Hi Armin,
Thanks a lot for your reply.
I'm very interested in your work, what's the techinical detail? or your
plan? or Where could I found them?
Antonio
2012/5/16 Liang Weike <we...@cs2c.com.cn>
> 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!
>
>
>>
>>> Antonio.Wang
>>>
>>>
>> Sincerely,
>> Armin
>> --
>> ALG
>>
>> --
> Regards,
> Liang Weike
>
>
Re: Drawing layer performance issue
Posted by Liang Weike <we...@cs2c.com.cn>.
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!
>
>>
>> Antonio.Wang
>>
>
> Sincerely,
> Armin
> --
> ALG
>
--
Regards,
Liang Weike
Re: Drawing layer performance issue
Posted by Armin Le Grand <Ar...@me.com>.
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 :-)
> 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!
>
> Antonio.Wang
>
Sincerely,
Armin
--
ALG
Re: Drawing layer performance issue
Posted by Armin Le Grand <Ar...@me.com>.
Hi Clarence,
On 28.05.2012 08:11, Clarence GUO wrote:
> HI~ Armin,
> May I know after aw80 is done, will we have much perfomance improvement on
> rendering?
Some, but not much. aw080 is about security and basic paradigm changes
(I'm preparing documentation, could be ready later today). It is
aprerequisite to some needed stuff. One of the next steps will then be
to create system-specific renderes.
> If we will have, how much improvement can we get from it? Do we
> have some performance test result data or estimation number?
Not yet, aw080 is on progress but will need time and stabilisation. I
did not build the pro version for some time (needed for performance),
but of course feel free to do so (it's on
https://svn.apache.org/repos/asf/incubator/ooo/branches/alg/aw080/)
> Thanks& regards,
> Clarence
>
>
> 2012/5/15 ����<ki...@gmail.com>
>
>> Hi,
>> Currently the performance of drawing layer is not good enough.
>> Does anybody know that is it possible to use a mature third-party graphic
>> component to replace drawing laywer for improving performance?
>>
>>
>> Antonio.Wang
>>
>
Sincerely,
Armin
--
ALG
Re: Drawing layer performance issue
Posted by Clarence GUO <cl...@gmail.com>.
HI~ Armin,
May I know after aw80 is done, will we have much perfomance improvement on
rendering? If we will have, how much improvement can we get from it? Do we
have some performance test result data or estimation number?
Thanks & regards,
Clarence
2012/5/15 ���� <ki...@gmail.com>
> Hi,
> Currently the performance of drawing layer is not good enough.
> Does anybody know that is it possible to use a mature third-party graphic
> component to replace drawing laywer for improving performance?
>
>
> Antonio.Wang
>