wishlist: layer transparency / color scheme / high contrast mode refinement

[madworm]

With copper pour enabled and some color combinations it is virtually impossible to discern whether a track is on the front or back layer, even in high contrast mode.

It would be nice to have the alpha value for each layer user-adjustable.

It would also be helpful if the 'color mixing' in normal mode could be turned off. That way e.g. a red track (front layer) doesn't change it's color when there is copper pour in the bottom layer underneath it.

[Lorenzo Marcantonio (l-marcantonio)]

On Mon, Apr 30, 2012 at 09:04:37AM -0000, madworm wrote:
> Public bug reported:
>
> With copper pour enabled and some color combinations it is virtually
> impossible to discern whether a track is on the front or back layer,
> even in high contrast mode.
>
> It would be nice to have the alpha value for each layer user-adjustable.
>
> It would also be helpful if the 'color mixing' in normal mode could be
> turned off. That way e.g. a red track (front layer) doesn't change it's
> color when there is copper pour in the bottom layer underneath it.

AFAIK is in the work in the GAL (i.e. hardware accelerated) branch; wait for it

--
Lorenzo Marcantonio
Logos Srl

[Dick Hollenbeck (dickelbeck)]

> Public bug reported:
>
> With copper pour enabled and some color combinations it is virtually
> impossible to discern whether a track is on the front or back layer,
> even in high contrast mode.
>
> It would be nice to have the alpha value for each layer user-adjustable.
>
> It would also be helpful if the 'color mixing' in normal mode could be
> turned off. That way e.g. a red track (front layer) doesn't change it's
> color when there is copper pour in the bottom layer underneath it.
>
I believe this is the way freerouter works, and it is quite nice. Although it does take
quite a bit of tuning to find something you like.

[Torsten Hueter (torstenhtr)]

Hi Dick,

> > It would also be helpful if the 'color mixing' in normal mode could be
> > turned off. That way e.g. a red track (front layer) doesn't change it's
> > color when there is copper pour in the bottom layer underneath it.
> >
> I believe this is the way freerouter works, and it is quite nice.
> Although it does take
> quite a bit of tuning to find something you like.

Pretty easy to support with the GAL, just by drawing the objects with a different alpha value.

If you have somewhere a Windows machine, you could try the Protheus demo
version:

http://www.labcenter.com/index.cfm

They use OpenGL or GDI, you can choose between them in a display options menu. Just like Freerouter there it's also possible to use different blending options. But it's faster than freerouter. That's how KiCad could look like with the GAL.

Bye,
Torsten

> --
> You received this bug notification because you are a member of KiCad Bug
> Squad, which is subscribed to KiCad.
> https://bugs.launchpad.net/bugs/991774
>
> Title:
> wishlist: layer transparency / color scheme / high contrast mode
> refinement
>
> Status in KiCad:
> New
>
> Bug description:
> With copper pour enabled and some color combinations it is virtually
> impossible to discern whether a track is on the front or back layer,
> even in high contrast mode.
>
> It would be nice to have the alpha value for each layer user-
> adjustable.
>
> It would also be helpful if the 'color mixing' in normal mode could be
> turned off. That way e.g. a red track (front layer) doesn't change
> it's color when there is copper pour in the bottom layer underneath
> it.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/kicad/+bug/991774/+subscriptions

--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

[Dick Hollenbeck (dickelbeck)]

On 05/01/2012 12:28 PM, Torsten Hueter wrote:
> Hi Dick,
>
>>> It would also be helpful if the 'color mixing' in normal mode could be
>>> turned off. That way e.g. a red track (front layer) doesn't change it's
>>> color when there is copper pour in the bottom layer underneath it.
>>>
>> I believe this is the way freerouter works, and it is quite nice.
>> Although it does take
>> quite a bit of tuning to find something you like.
> Pretty easy to support with the GAL, just by drawing the objects with a
> different alpha value.
>
> If you have somewhere a Windows machine, you could try the Protheus demo
> version:
>
> http://www.labcenter.com/index.cfm
>
> They use OpenGL or GDI, you can choose between them in a display options
> menu. Just like Freerouter there it's also possible to use different
> blending options. But it's faster than freerouter. That's how KiCad
> could look like with the GAL.
>
> Bye,
> Torsten

Torsten,

I am still very excited about using the GAL, and I am aware of the alpha blending support.

My last comment on it pertained to wxDC, and I am not excited about putting another shim
on top of that API, in addition to class PAINTER. It is already a layer on top of a
number of alternatives within wx.

With the PAINTER concept, we can encapsulate the differences in API within this abstraction.

Here is the difference using a metaphor of paint brush, paint roller, and spray can.

PLAN A
======
It standardizes the interface to each painting tool, such that you can pick up a brush, a
paint roller, or a spray can, and be given instructions to paint a circle, line, or
square. You cant take instructions to paint the circle filled, and with a particular
perimeter thickness, which can also be in a different color. So now you can use any tool,
and you "propagate" (there is that word again) the drawing instructions through out your
life. GAL pretty much lives at this layer.

PLAN B
======
It standardizes the interface to a PAINTER, and lets the PAINTER figure it out. If you
have a fence that needs to be painted, you tell the painter "paint the fence". Later you
pay him and go have a beer.
At no time have you "propagated" painting instructions at the line, arc, circle, square
level, throughout your life. And you can fire the painter when he fails. Switching to
GAL from wxDC.

See the header file in tools which was just a capturing of the initial idea. This is just
a conceptual argument for the time being. PAINTER uses the highest API possible, which is
like "paint the fence", or even "paint the board".

There is no problem having radically different ways of painting the fence within the realm
of the PAINTER's responsibility, especially if you are only employing ONE AT A TIME, or
even a couple of different PAINTERs for different surfaces. This can be done by having
multiple DLL/DSOs possibly, or multiple compile time options. PAINTER does not need to
be polymorphic. You can stay non polymorphic and still have multiple PAINTERs for your
various surfaces.

So if you have been reading carefully, you will have noticed that the goal is to maximize
beer drinking time.

Dick

[Torsten Hueter (torstenhtr)]

Hi Dick,

I've checked the class_painter.h in the tools folder.
Basically, the painter class is a layer above the GAL with a higher abstraction. This should work well together with the GAL.
The painter does not need to be dependent on wxDC; the simplest way would be to use an accessor to set the GAL (or within the constructor). Compare also stroke_font.cpp, there I'm using this method. It should be also totally independent of a particular GAL implementation.
If that should be too slow we could also use templates and create specialized painters; but as long as this is not required I'd prefer first keep it easy, just like in the GAL examples.

The painter should collect the information about board/schematic objects in world coordinates, calls then the GAL with the lower level functions like drawing lines/circles etc. The GAL will do all required transformations, draws objects, the grid and the cross hair cursor in screen coordinates.

Thanks,
Torsten

> Torsten,
>
> I am still very excited about using the GAL, and I am aware of the alpha
> blending support.
>
> My last comment on it pertained to wxDC, and I am not excited about
> putting another shim
> on top of that API, in addition to class PAINTER. It is already a layer
> on top of a
> number of alternatives within wx.
>
> With the PAINTER concept, we can encapsulate the differences in API
> within this abstraction.
>
> Here is the difference using a metaphor of paint brush, paint roller,
> and spray can.
>
>
> PLAN A
> ======
> It standardizes the interface to each painting tool, such that you can
> pick up a brush, a
> paint roller, or a spray can, and be given instructions to paint a circle,
> line, or
> square. You cant take instructions to paint the circle filled, and with a
> particular
> perimeter thickness, which can also be in a different color. So now you
> can use any tool,
> and you "propagate" (there is that word again) the drawing instructions
> through out your
> life. GAL pretty much lives at this layer.
>
>
> PLAN B
> ======
> It standardizes the interface to a PAINTER, and lets the PAINTER figure it
> out. If you
> have a fence that needs to be painted, you tell the painter "paint the
> fence". Later you
> pay him and go have a beer.
> At no time have you "propagated" painting instructions at the line, arc,
> circle, square
> level, throughout your life. And you can fire the painter when he fails.
> Switching to
> GAL from wxDC.
>
>
> See the header file in tools which was just a capturing of the initial
> idea. This is just
> a conceptual argument for the time being. PAINTER uses the highest API
> possible, which is
> like "paint the fence", or even "paint the board".
>
> There is no problem having radically different ways of painting the fence
> within the realm
> of the PAINTER's responsibility, especially if you are only employing ONE
> AT A TIME, or
> even a couple of different PAINTERs for different surfaces. This can be
> done by having
> multiple DLL/DSOs possibly, or multiple compile time options. PAINTER
> does not need to
> be polymorphic. You can stay non polymorphic and still have multiple
> PAINTERs for your
> various surfaces.
...

[Dick Hollenbeck (dickelbeck)]

On 05/05/2012 08:39 AM, Torsten Hueter wrote:
> Hi Dick,
>
> I've checked the class_painter.h in the tools folder.
> Basically, the painter class is a layer above the GAL with a higher abstraction. This should work well together with the GAL.
> The painter does not need to be dependent on wxDC; the simplest way would be to use an accessor to set the GAL (or within the constructor).

No.

> Compare also stroke_font.cpp, there I'm using this method. It should be also totally independent of a particular GAL implementation.
> If that should be too slow we could also use templates and create specialized painters; but as long as this is not required I'd prefer first keep it easy, just like in the GAL examples.
>
> The painter should collect the information about board/schematic objects
> in world coordinates, calls then the GAL with the lower level functions
> like drawing lines/circles etc. The GAL will do all required
> transformations, draws objects, the grid and the cross hair cursor in
> screen coordinates.
>
> Thanks,
> Torsten

You are trying to persuade me into something I don't want, and its not working, and
probably won't work.

The PAINTER was partially conceived as a coffin for wxDC. This means we let wxDC live its
last days in ITS OWN PAINTER, maintained by anyone who actually cares about it after the
OpenGL support is working in ITS OWN PAINTER. There was never a decision on a project
basis to continue supporting wxDC after the OpenGL stuff is working. But even without the
group decision, I can tell you I will be spending no time on wxDC after the OpenGL under
GAL under PAINTER is working. I do not want to co-mingle the code, because I want to be
able to shoot the wxDC support in the head at the proper time (short of special bitmap
support if needed.)

Although I cannot tell somebody that they can no longer support obsolete code, because
they can, I can decide what I am willing to support, and I can have a strong say on where
code lives, and how easily it can be killed off in the future.

PAINTER is a compile replaceable interface, it is not to be polymorphic, because that
would entail having wxDC and OpenGL support in the same link image. I do not want that,
and if you had seen my original posting on this subject you would have seen that point of
view.

That is one argument, another is that for the person maintaining wxDC, he probably wants
to keep the same API we already have for each BOARD_ITEM, and not have to worry about yet
another mapping layer, a new shim for something that has a limited lifespan.

I don't think you have to address ANY objections to abandoning wxDC, I think you can stay
focused on making the GAL on OpenGL and Cairo work. Because if they work, then there will
be near zero political support for wxDC, perhaps one person or two. And they can do their
own PAINTER for that, we do not have to do it for them, IF your new stuff works great.

So the PAINTER class is actually not only one class, but any number of them having the
same interface. Under this plan, the PAINTERs in play would be chose at compile time, not
runtime using polymorphism.

Polymorphism can still be useful in your GAL to support cairo...

[Torsten Hueter (torstenhtr)]

Hi Dick,

no, I don't think that we have a disagreement. I assume you mean the stuff that I mentioned about a wxDC GAL implementation. This was/is just an experiment to see if that works and how well it works, also as kind of benchmark. I'll definitely don't spend more time with that - I see wxDC as deprecated. wxDC has also many disadvantages, it does not support transparency for instance and the object drawing is broken (problems with objects outside the screen).
However I'd like not thow away my implementation at the moment; perhaps there is still some use for it. At least it helped me to test my transformation matrix functions.

Bye,
Torsten

> On 05/05/2012 08:39 AM, Torsten Hueter wrote:
> > Hi Dick,
> >
> > I've checked the class_painter.h in the tools folder.
> > Basically, the painter class is a layer above the GAL with a higher
> abstraction. This should work well together with the GAL.
> > The painter does not need to be dependent on wxDC; the simplest way
> would be to use an accessor to set the GAL (or within the constructor).
>
> No.
>
> > Compare also stroke_font.cpp, there I'm using this method. It should be
> also totally independent of a particular GAL implementation.
> > If that should be too slow we could also use templates and create
> specialized painters; but as long as this is not required I'd prefer first keep
> it easy, just like in the GAL examples.
> >
> > The painter should collect the information about board/schematic objects
> > in world coordinates, calls then the GAL with the lower level functions
> > like drawing lines/circles etc. The GAL will do all required
> > transformations, draws objects, the grid and the cross hair cursor in
> > screen coordinates.
> >
> > Thanks,
> > Torsten
>
> You are trying to persuade me into something I don't want, and its not
> working, and
> probably won't work.
>
> The PAINTER was partially conceived as a coffin for wxDC. This means we
> let wxDC live its
> last days in ITS OWN PAINTER, maintained by anyone who actually cares
> about it after the
> OpenGL support is working in ITS OWN PAINTER. There was never a decision
> on a project
> basis to continue supporting wxDC after the OpenGL stuff is working. But
> even without the
> group decision, I can tell you I will be spending no time on wxDC after
> the OpenGL under
> GAL under PAINTER is working. I do not want to co-mingle the code,
> because I want to be
> able to shoot the wxDC support in the head at the proper time (short of
> special bitmap
> support if needed.)
>
>
> Although I cannot tell somebody that they can no longer support obsolete
> code, because
> they can, I can decide what I am willing to support, and I can have a
> strong say on where
> code lives, and how easily it can be killed off in the future.
>
>
> PAINTER is a compile replaceable interface, it is not to be polymorphic,
> because that
> would entail having wxDC and OpenGL support in the same link image. I do
> not want that,
> and if you had seen my original posting on this subject you would have
> seen that point of
> view.
>
>
> That is one argument, another is that for the person maintaining wxDC, he
> probably wants
> to keep t...

[Lorenzo Marcantonio (l-marcantonio)]

On Sat, May 05, 2012 at 08:28:03PM -0000, Dick Hollenbeck wrote:
> OpenGL support is working in ITS OWN PAINTER. There was never a decision on a project
> basis to continue supporting wxDC after the OpenGL stuff is working. But even without the

At least please don't make opengl mandatory since not everyone can use it...

> I don't think you have to address ANY objections to abandoning wxDC, I think you can stay
> focused on making the GAL on OpenGL and Cairo work. Because if they work, then there will

Could cairo be actually fast enough to use? I hope so

--
Lorenzo Marcantonio
Logos Srl

[Maciej Suminski (orsonmmz)]

Now, with OpenGL GAL in place you can modify alpha value per layer (shift + [ / ]). Still, there is no GUI to change setting, so I am keeping it in a wishlist.

[xzcvczx (xzcvczx)]

could this be added to the Layer Setup dialog or would be be better as its own dialog with it available as a right click option in the layer widget? Does wxwidgets allow slider bars as menu items if so it could just be implmented as a slider bar in right click in layer widget

[Jeff Young (jeyjey)]

This has been implemented, right? (Right click layer and chose "Change Layer Color for {layer name}".)

[Wayne Stambaugh (stambaughw)]

Yes, GAL canvases now support full color and transparency settings. I'll set the status to fix committed.

[Hildo Guillardi Júnior (hildogjr)]

I think is solved int he old Legancy Canvas. But still needing improvements on OpenGL mainly abou t the transparency (because of the filled zones).

[Chris Pavlina (pavlina-chris)]

Can you elaborate? I didn't think legacy had _any_ transparency support. I'm not sure we're talking about the same thing.

[Hildo Guillardi Júnior (hildogjr)]

It is what @Lorenzo said.
In OpenGl I can't see the top-bottom crossing with the copper pour ON. But in Legancy mode I can.
This could be solved with some transparecy/alpha layer configuration.