incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Le Grand <>
Subject Re: Drawing layer performance issue
Date Thu, 17 May 2012 11:40:14 GMT
Hi Antonio,

"Antonio.Wang" <> 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

> 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

>      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...



> Antonio
> 2012/5/16 Armin Le Grand <>
>>        Hi Liang and Antonio,
>> --
>> ALG


View raw message