kicad-developers team mailing list archive
Mailing list archive
Re: EESchema XOR-Artifacts
Dick Hollenbeck <dick@...>
Thu, 13 Mar 2008 00:04:17 -0500
Thunderbird 220.127.116.11 (X11/20080227)
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
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
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
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
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
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.