Defining waveform thicknesses and colors on a white background in VIVA

Whoops! I just quit and got back in again - now the colorBank variable seems to be working. For now, you can disregard the color part of my question. The line thickness is the remaining issue.

I don’t believe there are any controls to alter the definition of the line thicknesses in ViVA. This is the first I’ve heard of anyone objecting to the default definitions (I didn't find any requests to control this so far) - if you need control over this, it would need an enhancement request.

Also a bit surprised about your comment about the default colours being lousy; we actually do automatic contrast adjustment in ViVA when altering the background colour - I often set my background to white because I frequently give demos on projectors, and a black background is often bad on a projector, but the colours usually are good when projected with a white background without me needing to adjust. Still, each to their own - that’s why we allow you to control it!

Regards,

Andrew.

Yea, perhaps my "lousy" comment about the default colors was a tad harsh (apologies). I'll take your advice regarding dealing with the line thickness. Thanks Andrew.

No worries. One man's  "lousy" is another man's "fabulous" ;-)

Andrew.

Sorry for dredging up this old topic, but something happened a few days ago and now all my viva plot colors are no longer respecting the y0-y9 definitions in my display.drf (and when I bring up the Display Resource Manager I also confirm my y0-y9 definitions are still what I want). A typical plot command from my ocean script is:

awvPlotWaveform(awvGetCurrentWindow() \
list(L("/sig1") L("/sig2") L("/sig3") L("/sig4") L("/sig5") L("/sig6")) \
?expr list("sig1" "sig2" "sig3" "sig4" "sig5" "sig6") \
?stripNumber list(3 4 5 6 7 8) \
?color '("y5" "y5" "y6" "y7" "y2" "y2") )

And for bonus points, is there any way to specify the plot colors with real, intuitive color names like "red", "green" etc..

I believe the code uses the packet names y0-y9 rather than the layer names y0-y9 (which might be bound to different packet names in a particular technology). This is because awvPlotWaveform doesn't know which technology library is in use (note, this is from a quick scan of the code).

I'm hopefully going to gain bonus points though as it appears (from looking at the code) that you can pass Hex color numbers to awvPlotWaveform so you use this code:

/* abColorNameToHex.il

Author     A.D.Beckett
Group      Custom IC (UK), Cadence Design Systems Ltd.
Language   SKILL
Date       Jul 02, 2018 
Modified   
By         

Convert friendly color (or colour!) names to RGB hex strings
as suitable for passing to awvPlotWaveform. Invalid color names
result in string when gets handled as black (or white) when plotting in
ViVA.

abColorNameToHex("pink") => "0xffc0cb"
abColorNameToHex(list("yellow" "purple" "lightgreen")) => 
    ("0xffff00" "0xa020f0" "0x90ee90")

Uses SKILL++ methods just to avoid having a case statement!

***************************************************

SCCS Info: @(#) abColorNameToHex.il 07/02/18.13:41:05 1.1

*/

(defmethod abColorNameToHex ((colorName string))
  (strcat "0x"
          (buildString
            (mapcar 
              (lambda (intensity) 
                (sprintf nil "%02x" (round (times intensity 0.255))))
              (nameToColor colorName)
              )
            ""
            )))

(defmethod abColorNameToHex ((colorNames list))
  (mapcar 'abColorNameToHex colorNames)
  )

and then do:

awvPlotWaveform(awvGetCurrentWindow()
   list(v("/OUTM") v("/OUTP") v("/SAMPLE"))
  ?expr list("a" "b" "c")
  ?stripNumber list(3 4 5)
  ?color abColorNameToHex(list("lightgreen" "pink" "orange"))
)

Regards,

Andrew.

Just back from a week's vacation for the 4th of July so sorry for the delayed response. Thanks for your "friendly color (or colour!) names to RGB hex strings" code - it works great! 

Side-track regarding the colors vs colours comment - in the UK I believe they refer to the USA's 4th of July Independence Day event as an American civil war event. It all depends on who's writing the history books :-).

I still can't make any sense of why the y0-y9 colors stopped working right in ViVA. Here is a stripped down display.drf file that describes what I'm doing with e.g. y6:

drDefineDisplay(
;( DisplayName )
( display )
)

drDefineColor(
;( DisplayName ColorsName Red Green Blue Blink)
( display CCcolor7 0 220 220 )
)

drDefinePacket(
;( DisplayName PacketName Stipple LineStyle Fill Outline FillStyle )
( display y6_drawing blank thickLine2 CCcolor7 CCcolor7 outline )
( display y6Flt blank thickLine2 CCcolor7 CCcolor7 outline )
( display y6 blank thickLine2 CCcolor7 CCcolor7 outline )
)

I have also attached a couple screenshots from the Display Resource Editor that shows y6* is a cyan color, but whenever I specify "y6" in any of the  awvPlotWaveform commands I get an orange color. It really looks like awvPlotWaveform simply isn't using the y0-y9 colors at all (but at some point in the past it certainly did) :-(   

Hmm - I just tried dragging those Display Resource Editor screenshots into the online posting editor (per the instructions) but they just show as boxes with a question mark inside. Bummer. Anyway, all they depict is the Display Resource Editor with ALL LPPs selected and y6 entered into the search bar resulting in only the Cyan colored CCcolor7 packets. Nothing orange - the color used when selecting y6 in the awvPlotWaveform command. Any ideas about that part?

From doing some experiments (sat on an aeroplane waiting to take off, unfortunately faulty, it seems!), it only picks up the display.drf found via the setup.loc mechanism - and if not that, it finds the default.drf file at <INSTDIR>/share/cdsetup/dfII/default.drf - and it's looking just at the packets with the name y0-y9 - i.e. nothing to do with the layers y0-y9.

BTW, in the Display Resource Editor you can search for "All Packets" Rather than All LPPS but that doesn't help you if the display.drf has been updated in memory.

We really should document this - or hopefully improve it so that it uses the real packet information.

I'll check at some point about the uploading of images - it does break from time to time for me, but usually switching browsers fixes it for a bit and by the time I get around to reporting it, it seems to have gone away...

As for 4th July - we know little about it in the UK other than it being your independence day holiday. We've moved on after almost 250 years ;-)

Andrew.

Yes - one of the images I was going to attach for the Display Resource Editor did show "All Packets" for y6 in the search bar and everything found was cyan colored (but the waveforms still plotted in orange).

I just looked at <INSTDIR>/share/cdsetup/dfII/default.drf and sure enough y6 is the offending orange color I've been seeing - even though there is no evidence of anything matching y6 that's orange when I bring up the Display Resource Editor. I'm still trying to track down which display.drf file is found via the setup.loc mechanism...

Trying not to look a gift horse in the mouth here (but apparently that's exactly what I'm doing)...

Is there a way to return an RGB list similar to what you have in abColorNameToHex.il but that caters for the name found in the display.drf world instead? Ideally the routine would scan both the Display Resource and X11 environments and return the hex list. I'm assuming that there is some sensible precedence to color naming i.e. maybe names used by the Display Resource Editor take priority over the standard X11 names (e.g. if you were dumb enough to define "red" as being 0x00ff00, i.e. green, in display.drf then that would win over the X11 definition of "red").