kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 12/12/2010 12:40 PM, Marco Mattila wrote:
> Dick,
>
> The main point in my reply earlier was just that the visual results
> are not equivalent. However, I agree with you that using OR is the way
> to go if it is acceptable that things in gerbview will look a little
> different than before. At least I'm ok with that.
>
> Anyways, I think that the graphics we are talking about here is not
> very complex and should be doable. Someone mentioned wxGraphicsContext
> in the mailing list a while ago and that it should bring a performance
> boost. When working on the patch I briefly experimented with wxGCDC
> (which I think wraps wxGraphicsContext in a wxDC compatible way?).
> However, the performance was pretty bad and since it turned out that
> alpha blending was not necessary I didn't continue on that route any
> further.
>
> marco

The problem with ORing the colors is that as you get more layers, eventually the
intersections all turn white, no?
(Ok, on a normal board, we don't have so many mutliple gerber layer intersections,
true.  But if it can go wrong it eventually will.)


Again, I'd like to support both modes from a UI experience point of view.  I have some
time now to work on this.


Regarding your code, we don't know where the bottleneck is.  (If we did, we could
directly attack it.)


So we can start guessing. 

Let's assume the screen memory is slower than internal memory, this could be the
current bottleneck.  Plus I am seeing flicker with only two layers, let alone a full
stack of gerber layers.  This tends to support the theory.

I will spend some time and try buffering the screen memory in its own additional
wxMemoryDC until the very end. 
I can spend that time now.



Can you make sense of this language from here:

http://docs.wxwidgets.org/trunk/classwx_d_c.html#12bed94a15136b9080683f4151042a34

Pay attention to the algorithm used by wx for Windows when the bitmap cannot be used.


/useMask/  	If true, Blit does a transparent blit using the mask that is associated
with the bitmap selected into the source device context. The Windows implementation
does the following if MaskBlt cannot be used:

   1. Creates a temporary bitmap and copies the destination area into it.
   2. Copies the source area into the temporary bitmap using the specified logical
      function.
   3. Sets the masked area in the temporary bitmap to BLACK by ANDing the mask bitmap
      with the temp bitmap with the foreground colour set to WHITE and the bg colour
      set to BLACK.
   4. Sets the unmasked area in the destination area to BLACK by ANDing the mask
      bitmap with the destination area with the foreground colour set to BLACK and the
      background colour set to WHITE.
   5. ORs the temporary bitmap with the destination area.
   6. Deletes the temporary bitmap.

This sequence of operations ensures that the source's transparent area need not be
black, and logical functions are supported.




As a second test, maybe we can use that same algorithm, for all platforms.  It almost
sounds as if you can set the background and foreground colors in advance of doing a
blit, and have that affect the final outcome of the blit.  This is not intuitively
obvious, that setting a color in advance of a blit will go into effect during a blit.


Those are two schemes to try, and actually they both involve buffering the screen
memory, until the end.


Dick