Why drawing borders before the background

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Why drawing borders before the background

Cédric Bosdonnat
Hi all,

I'm currently hacking the borders painting methods in sw to use the
drawinglayer. I have seen that for every object the borders are drawn
before the background... and that the background's area include the
borders.

Is there any reason not to drawn the borders after the background?

Regards,

--
Cedric




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Why drawing borders before the background

Oliver-Rainer Wittmann - Software Engineer - Sun Microsystems
Hi Cedric,

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.

sw painting was my favourite when I started my work at OpenOffice.org
Writer. But, this time is long ago. Thus, please excuse, if my memory
does not correspond to the reality.

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

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.

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

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.

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.

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.


Best regards, Oliver.


On 03/11/10 17:28, Cédric Bosdonnat wrote:

> Hi all,
>
> I'm currently hacking the borders painting methods in sw to use the
> drawinglayer. I have seen that for every object the borders are drawn
> before the background... and that the background's area include the
> borders.
>
> Is there any reason not to drawn the borders after the background?
>
> Regards,
>
> --
> Cedric
>
>


--
=======================================================================
Sun Microsystems GmbH    Oliver-Rainer Wittmann
Nagelsweg 55             Software Engineer - OpenOffice.org/StarOffice
20097 Hamburg
Germany                  Fax:   (+49 40) 23 646 955
http://www.sun.de        mailto:[hidden email]
-----------------------------------------------------------------------
Sitz der Gesellschaft:
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels
Vorsitzender des Aufsichtsrates: Martin Haering

=======================================================================
Oliver-Rainer Wittmann (od) - OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Why drawing borders before the background

Cédric Bosdonnat
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Why drawing borders before the background

Fan Zheng
In reply to this post by Cédric Bosdonnat
2010/3/12 Cédric Bosdonnat <[hidden email]>

> Hi all,
>
> I'm currently hacking the borders painting methods in sw to use the
> drawinglayer.

Woo, That would be a great idea. At least, the PrimitiveAnimation could be
working better in Writer than it is currently.

And what about your design? A specified layer(s) for flying objects? Any
change for table and section?

Thanks alot!
Easyfan.


> I have seen that for every object the borders are drawn
> before the background... and that the background's area include the
> borders.
>

> Is there any reason not to drawn the borders after the background?
>
> Regards,
>
> --
> Cedric
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>