kicad-developers team mailing list archive
Mailing list archive
Re: Re: OSX: pcbnew with CORE_GRAPHICS.
Dick Hollenbeck <dick@...>
Tue, 01 Apr 2008 09:13:56 -0500
Thunderbird 18.104.22.168 (X11/20080227)
Marius Kintel wrote:
On Apr 1, 2008, at 1:54 PM, jean-pierre charras - INPG wrote:
This is *exactly* the case.
I never used blend/alpha functionality instead of OR mode (it did not
exists when i started kicad), but i think this is a good idea.
Thanks for clearing this up :)
Since COPY may hide some layers, we should have some kind of blending
However, this is probably not critical, so using COPY for now (only
for the Mac port) is a good start I think.
But moving objects still must use the XOR mode
(i am not sure full redraw of the screen when moving an object is
useable for large and complex boards)
Yes XOR is used everywhere. The good news is that wxXOR seems to be
supported on the MAC, so the only problem is wxOR. I again wish to
point out the possible alternative which is to draw the current layer
last. I went through the BOARD drawing code last night and think this
is a viable option. In fact it may be an attractive option to support
as a dynamically selectable toggle, sort of like the "High Contrast
Mode" can be temporarily selected. In any case we might want to try it
and then decide.
Here are my thoughts on implementation:
**Any time you change layers, the screen gets redrawn with the current
layer on top, including a via initiated layer change.
**We put a BOARD_ITEM* vector into the frame window or drawpanel or
BOARD to record objects which are on the current layer. And this is
cleared at the beginning of the main drawing handler.
**Any drawing code which iterates over BOARD_ITEMs checks the layer and
either calls BOARD_ITEM::Draw() or puts that BOARD_ITEM* into the vector
if it is on the current layer.
**Then the iterating drawing code simply draws all the items in the
vector, they should already be in the proper sequence, and they now all
have a polymorphic Draw function as of last night. The vector capacity
will tend to expand to proper size and then stay there on subsequent calls.
The highlight and high contrast modes might cause some wrinkles in this
plan but I think we can iron those out.
The reason I take such time to elaborate this idea is because I think
this *might* be a valuable feature for any OS platform (but I might be
wrong). There are times where I just don't want to take time to turn
off the display of layers that are getting in my way. It might be a
better, more stream-lined UI experience to simply put the layer of
interest "on top" conceptually.