Adding contrast to flyline delay text so it's readable now

[dpbaines]

Description

Change the colour of the flyline delay text to black. I also gave it a very small offset so that it does get seperated from the line it's printed over if zoomed in, but is still clearly related to said path. Ideally one would also draw a white box behind the text so it's clear, but ezgl doesn't make this very ez.

Related Issue

Motivation and Context

A visual example of the issue below.
https://imgur.com/Zu5VrQd

How Has This Been Tested?

I tested it on a random circuit and architecture and verified that it only effects flyline text, in the intended manner.

Types of changes

• Bug fix (change which fixes an issue)
• New feature (change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My change requires a change to the documentation
• I have updated the documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed

[vaughnbetz]

I think the offset by 2 unit (world coordinates) is going to be problematic for circuits of different sizes and for different zoom levels. If you look in the ezgl code you'll see how the text extents (in pixels are computed) and/or how to convert from world to screen coordinates. You should work out how far you need to shift the text to be away from the flyline. Looking at the routines that do text justification should show you how; you may be able to just choose an appropriate text justification to make this happen (i.e. leverage the existing computations). Then you'll have to test the various zoom levels, flyline orientations, circuit sizes etc. to make sure it draws nicely under various scenarios.

[vaughnbetz]

@dpbaines: any thoughts?

[dpbaines]

I agree completely, I've also experimented with changing text weight, and drawing a bold white text underneath the thin black text to give it a border, however this doesn't work in practice. I'll give your suggestions a go and let you know!

[dpbaines]

I've updated the code so it now rotates the text and draws it parallel to the flyline. I also changed it to use screen coordinates instead of world coordinates as you suggested, however I wasn't able to get information on the text extents, as the variables I need are all private in ezgl. I've taken screen shots of the results of various circuits at different zoom levels, let me know if you'd like me to try some larger circuits!

See the results here:
https://imgur.com/a/jeO6r3H

[vaughnbetz]

Thanks, both the pictures and the code look good. There are two CI failures, but they both seem to be related to llvm / clang not being properly fetched and installed. Maybe their web server was down? Can you try relaunching the CI tests to see if they pass now?

[dpbaines]

Yeah for sure, I think the strong sanitized test failure is related to this issue: #1459

[vaughnbetz]

Yes, the strong sanitized test failure is unrelated.
The Travis CI branch also seems to just have a set up issue (gcc 7 test didn't download / set up). Any idea why? Not sure what it means that the branch had this error, but the PR did not.
If you try that one again does it pass (i.e. was this some intermittent web access issue, or is something someone needs to debug in the CI)?

[dpbaines]

Yeah it is strange, I have rerun it intermittently, and the odd thing is it seems to be failing on different jobs each time which is strange. I'm rerunning it again tonight, and I'll see what the result is.

[vaughnbetz]

Thanks. Maybe the symbiflow people can help if we have intermittent CI failures due to some download issues. But first we need to figure out if it's truly intermittent.

[dpbaines]

Yep it's passing now, I don't know if it's resolved but it's passed this time for me. Just for testing purposes I can rerun travis to see if it passes again? I'm not sure if its just this PR.