kicad-developers team mailing list archive

[Dick Hollenbeck <dick@...>]

Jonas Diemer wrote:
> Am Mittwoch 12 März 2008 23:58:09 schrieb Dick Hollenbeck:
>
> > 3) Make changes to the code so it uses the new PostDirtyRect() rather
> > than subverting an existing function. This is what we have done in
> > pcbnew, and I think the same function would work in eeschema if you can
> > calculate a proper bounding box.
>
> True, I did not mention that option (see below). Actually, even the 
> panel->refresh() function optionally takes a dirty rect. A PostDirtyRect() 
> function is currently not available in eeschema, so I am not subverting 
> anything.

PostDirtyRect() is there. And yes by changing the behavior of 
RedrawOneStruct( panel, DC, DrawStruct, g_XorMode ) to redraw the entire 
screen, yes that looks like an outright lie to anybody who reads this 
code 6 months from now.

There are many infrastructure features which are common to pcbnew and 
eeschema. Jean-Pierre and I worked out the mechanism of 
PostDirtyRect() two days ago, and I posted a few messages about that 
function already as being infrastructure to use for this type of screen 
cleanup. I even asked for a volunteer to start tucking it in.

> Irrespective of that, calculating the bounding box is a more difficult part, 
> at least compared to the current patch (which is a few lines only).

No, it is about 12 lines of code for a line segment, and I wrote it in 
15 minutes.


> The 
> current structs in eeschema do not have the corresponding properties, and the 
> elements drawn can be fairly complex (hierarchical components)...
It is the region on the screen that needs to be redrawn, and it does not 
need to be "pixel precise", just within a few pixels. It is an 
orthogonal rectangle.
> I don't know when I will have time to look at improving the performance of my 
> patch. Until then, do you think the current patch should stay out (leaving 
> eeschema _plain ugly_) or get in (with possible future improvements)?

I think it should stay out. However you should look at how easy it is 
to do what I am saying by looking at
EDA_Rect EDA_DrawLineStruct::GetBoundingBox() const, which I wrote in 
about 15 minutes,
and where it is called from block.cpp, which took another two minutes to 
add.


I have said before that I think the XORING technique is preferred for 
drag operations, and that at the *end of the drag* is when we should do 
a complete redraw.
My opinion on that has not changed.

PostDirtyRect() was put into play for deleting single wire segments in 
eeschema in under 1/2 hour. So I think you may be over estimating the 
amount of work required here. Why not do it right the first time?

What I think needs to be done is to

1) add GetBoundingBox to other drawable objects in eeschema, probably 
making that function virtual to EDA_BaseStruct with a default 
implementation so that non visual objects which derive from 
EDA_BaseStruct do not have to re-implement it.

2) remove the if( DrawStruct->Type() == DRAW_SEGMENT_STRUCT_TYPE ) 
test above the call to PostDirtyRect() in block.cpp so that technique is 
used for all visual objects, not just
line segments.

3) Use PostDirtyRect() where ever else we must erase objects from the 
screen and where the XORing technique is in adequate.

I also disagree with your other posting that these bounding boxes need 
to be computed ahead of time. It is easier to simply call the virtual 
function when you need one, not to have to remember when to recalculate 
it and make storage for it.

Hopefully it is not looking so daunting to you now.


Thanks,

Dick