Hi Oliver, On Fri, 2010-03-12 at 09:59 +0100, Oliver-Rainer Wittmann - Software Engineer - Sun Microsystems wrote: > The sw painting is a complicated stuff, because the code is quite old > and it somehow never adapts the things that has been 'innovated' in the > drawinglayer.
I understood that: that's why I need the light from someone knowing the history of that code ;) > As far as I remember: > The borders are not drawn before the background. > Yes, there is method <SwFrm::PaintBaBo(..)> (paint background and > border) and here method <SwFrm::PaintBorder(..)> is called before > <SwFrm::PaintBackground(..)>. But, in <SwFrm::PaintBorder(..)> the to be > painted border lines are not painted directly. The border lines are > collected in a data structure - static variable <pLines> in source file > /sw/source/core/layout/paintfrm.cxx - and painted afterwards all > together - <pLines->PaintLines(..)> Indeed... I made a mistake here because I still haven't moved the primitives processing later like it's currently done for the pLines. I guess that one of the reason to process the border lines before is to be able to compare them with the subsidiary lines... > There are also the so called subsidiary lines (your question in your > personal email to me). These are the painted object boundaries which in > the default case are grey and only painted, if the object has no border. > The color of these subsidiary lines can be changed by the user - Menu > Tools - Options - Appearance - Text|Object|Table|Section boundaries. > These subsidiary lines are also collected. Before they are painted they > are compared with the collected border lines. When a subsidiary line is > too close to a border line, the subsidiary line is not painted. Ok, I understand that better now. > Yes, I know this is complicated. I think the reason for the complicated > sw painting is that the former developers tries to reduce the output as > much as they can. They want to paint only stuff which is really visible > - e.g. method <lcl_SubtractFlys(..)>. Ok. Is there still any reason to do that? From what I saw the background is drawn below the borders... the area for the borders is painted as well. > What also complicates the sw painting is that all painted rectangles are > "<SwAlignRect>ed". This method assures that two painted rectangles which > are side by side and non-overlapping in the Twip coordination system are > also side by side and non-overlapping in the Pixel coordination system. > Thus, the sw painting assures that two hair lines, one green and one > red, which are directly side by side in the Twip world are also painted > side by side in the Pixel world regardless of the real positions on the > screen and of the zoom factor. This is something that is still be > needed, but may be it can be improved. Ok. I'm currently not really used to the Pixel world :) I'll need to investigate that code... but the drawing layer seems to produce good results here. > I think that a lot of stuff in the sw painting shall be simplified. > Especially because Armin has introduced the painting via a virtual > output device whose complete content is copied once to the window output > device when a complete paint has finished. Would it help removing the printer specific stuffs? > Cedric, may I join your work on the sw painting? > I would like to refactor some stuff in order to simplify the sw > painting. My first job would be to translate all the German comments in > /sw/source/core/layout/paintfrm.cxx into English. Following would be: > - getting rid of stuff like <lcl_SubtractFlys> > - getting rid of the <pVout->Enter> stuff - virtual output device > painting, if paint area is "small". This is no longer needed. That would be cool. My work is still not published anywhere (not even on ooo-build master branch). I'll create a CWS today in order to have some common place where to work. Regards, -- Cedric --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
