kicad-developers team mailing list archive
Mailing list archive
Re: [PATCH] Option to subtract soldermask from silkscreen in gerber output
On 12/12/2010 08:37 AM, jean-pierre charras wrote:
> Le 12/12/2010 12:04, Marco Mattila a écrit :
>> Using OR instead of COPY in blitting does not produce equivalent
>> resuilts. Now the appearance of one layer depends on what was drawn
>> "below" it.
>> On Sun, Dec 12, 2010 at 4:33 AM, Dick Hollenbeck<dick@xxxxxxxxxxx> wrote:
>>> However, I found some significant speed ups:
>>> 1) not using GR_OR mode when erasing the background of a negative layer.
>>> 2) not using the mask in the Blit() function but rather use wxOR there, which seems to
>>> be signicantly faster for some reason.
>>> The two changes together are extremely snappy.
>>> Please test to make sure this code is equivalent with respect to display results.
> I now fixed issue when compiling with USE_WX_ZOOM defined,
> i.e. when the device context is responsible to calculate zoom and draw offset.
> (blit function seems work only when user scale = 1 and no offset).
> About OR and COPY, each image (gerber layer) is drawn into its memory DC using COPY, so each image should be OK.
> Combining different images using OR is better than COPY, because one can see all images (transparency effect),
> like all layers in Pcbnew, and do not change Gerber images.
> This code need to be tested now under MacOSX.
I did not mean to give the impression that I was done working on the code. It is a
little disconcerting having the code change in my editor right out from underneath me,
after doing a bzr update. The key to grasping this was *my* question about whether my
commit functioned the same as Marco's patch: this implied an intent on my part to fix
it if it was not yet working OK. Marco's response should have been taken to mean that
I was back to the drawing board.
Perhaps I was not clear. But I tried to be.
Out of respect for Marco, the statement that using "OR is better than COPY", should be
flagged as an opinion.
We need to remain respectful of the work of contributing developers if we are going to
ever evolve beyond a small team. And today, frankly, even my nose is a little bent
out of shape.
I do not think we have found the best overall solution yet. I'd ask for the ability
to work on the code without having it change underneath me again.
I can see advantages to supporting both a blended color view, like we have in PCBNEW
and like what I committed, and a solid color view like what Marco presented, perhaps a
toggle button can alternate the two drawing effects.
Thanks for your patience.
Your code is technically correct, but it has severe performance problems on my
system. I have the fastest computer of anybody that I personally know. 64 bit
machine, very high end graphics card.
Taking from a comment I added to my portion of the Draw function this AM:
// On Linux with a large screen, this version is much faster and without flicker,
// but gives a PCBNEW look where layer colors blend together. Plus it works
// only because the background color is black. But it may be more useable for some.
// The difference is due in part because of the cpu cycles needed to create the
// monochromatic bitmap above, and the extra time needed to do bit indexing
// into the monochromatic bitmap on the blit above.
The cost of testing the individual monocromatic bit for each device context bit is
proportional to X * Y of the screen, so with "O squared" on screen area. I have a
very large screen. And I am having problems with drawing only two layers, not 10
which will be even worse.
If we cannot find a faster way to get your desired behaviour, I think we we will have
to support it in a toggle mode. So I am happy to spend some more time searching for
an optimal solution with you if you do not mind.
How do you feel about the toggle button? Both modes have some advantages from a user
experience perspective. My code is obviously dependent on the background being black,
and that may not always be the case in the future, so I have put a comment in to that
I do not think we are done yet.