← Back to team overview

kicad-developers team mailing list archive

Re: EESchema XOR-Artifacts


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.



Follow ups