kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@...>]

Vesa Solonen wrote:
> On Mon, 9 Mar 2009, Wayne Stambaugh wrote:
> 
> Thanks, Wayne for your through explanation.
> 
>> Vesa Solonen wrote:
>>> On Mon, 9 Mar 2009, jean-pierre charras - INPG wrote:
> 
>>>> The grid is a reference, so i think the dots positions must be exact.
>>>> Perhaps creates a grid line in memory and using a blit function could be
>>>> faster; (to do)
>> Be very careful about the decision to use blitting. Remember, depending
>> on what zoom level you draw your initial bitmap you will be stretching
>> and/or shrinking a bitmap of the drawing instead of scaling the drawing
>> objects to the current zoom level.
> 
> I think Jean-Pierre meant blitting _only_ the resulting line of dots to 
> speed up drawing.

I'm not sure you will save much by drawing the grid to a wxBitmapDC and
blitting it to the device then update the rest of the drawing over top
of it. I suppose as long as the zoom level or scroll position doesn't
change, you have the benefit of having the grid already drawn.

> On every zoom a line of dots is calculated as now and then that line is copied.

Actually, it happens on every refresh of the drawing.

> So no dot grid scaling at all. My guess is that using wxGC that is already
> solved because there is no need to scale from
> internal unit to screen units as wxGC handles it all. I may be wrong 
> though...

The grid would have to be scaled to properly to match the scaling of the
drawing even if it is handled internally by wxGC. I have played around
the the wxGC sample in wxPython and found that it suffers from the same
problems that scaling a fixed image always presents although to a lesser
extent than using a wxBitmapDC. I don't know if wxGC will try to scale
a single pixel into a small circle as you zoom in. I suspect it will
because that makes sense in terms of scaling.

> Most I'm waiting a proper hw accelerated drawing for Xorg.
> 
>> I have been working on some drawing (along with a whole bunch of other
>> stuff) improvements but I have been slowed by fragility of the current
>> drawing code. It seems like I always end up having to fix five other
>> things along the way when making what seems to be a fairly simple
>> change. I am willing to make the changes above to see if that improves
>> things but I will wait until after the next Kicad release. I have been
>> holding off on committing any code SVN because I have made some major
>> changes and I don't want to jeopardize pushing back the next release
>> schedule.
>>
>> Wayne
> 
> I'm very interested to test and I think there is a need for 'testing' 
> branch and 'bug fix' or 'stable' branch. Something to consider is 
> http://repo.or.cz/ for hosting your devel tree, isn't it?

I would rather see a development or experimental branch as part of the
main project that could be merged into HEAD after any new code became
reasonably stable. I personally do not have time or desire to maintain
a separate SVN branch of the code. I have no experience at setting up a
public SVN repository and I would prefer to leave that task to someone
who knows what they are doing. I am already getting quite a few
conflicts when I update my local development branch with the latest
changes in HEAD. I can't image how much effort would be involved trying
to merge a development branch into HEAD would be.

Wayne

> 
> -Vesa
> 
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
> 
>