Hi Antonio, "Antonio.Wang" <[email protected]> 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 <[email protected]> > >> Hi Liang and Antonio, >> >> [..] >> -- >> ALG >> >> -- ALG
