Problem displaying multiple text labels with same x value

[dtzikas]

The file display_labels.gds.txt contains 3 text labels a, b and c that have identical x-coordinates. After opening it with klayout version 0.27.7, only labels a and b are displayed. Label c is not shown unless it selected with mouse. I would expect all 3 text labels to be displayed. If I change the x-coordinate of any of the text labels, then all three labels are displayed as expected.

[Kazzz-S]

I reproduced this problem using KLayout 0.29.1 on Linux Mint 20.3.

Out of curiosity, I permutated the order of [a, b, c] in the GDS text files and saw what would happen.
As shown in the movie below, the last entry is not displayed correctly.

gh1709.mp4

This looks like the visual field test I took last week :-)
gh1709.zip

Regards,
Kazzz-S

[klayoutmatthias]

Hi,

there is a know problem with cells having degenerated bounding boxes - width and/or height being zero.

The root cause is deeply hidden in the drawing optimization code. Such cells are not recognized properly as drawing candidates, because the do not overlap with the drawing box (they do not share more than one pixel with the box). The problem exists since the stone ages. I am afraid fixing it will have undesired side effects, such as doubling or tripling drawing time for high-density hierarchical layouts.

I have not encountered reasonable use cases for such cells in my career, so I considered that a boundary case without practical relevance. It is somewhat annoying when you start creating a cell from scratch and start with texts. As soon as you draw your first polygon, the problem goes away.

But you can try convincing me this problem is important :)

Matthias

[Kazzz-S]

Hello @klayoutmatthias,

Thank you for the explanations.

As soon as you draw your first polygon, the problem goes away.

I confirmed this :-)

But you can try convincing me this problem is important :)

For me, this problem is not important :-)

Best regards,
Kazzz-S

[dtzikas]

Hi,

The root cause is deeply hidden in the drawing optimization code. Such cells are not recognized properly as drawing candidates because they do not overlap with the drawing box (they do not share more than one pixel with the box). This problem has existed since the early days. I'm afraid fixing it will have undesired side effects, such as doubling or tripling the drawing time for high-density hierarchical layouts.

KLayout is such excellent software that it's surprising this issue can't be fixed without significant side effects, but of course, I'll take your word for it.

But you can try convincing me this problem is important :)

I realize this is a very rare use case, for me it was important enough to open a ticket, but not important enough to consider fixing it myself :)

Since you asked, consider the following scenario:

There are two versions of an algorithm that automatically places pins on a cell. Someone works on evaluating them and applies both algorithms to the same cell, then computes the differences in another cell. They use KLayout to visualize the changes and notice that only two text labels are displayed, but in reality, there are many more. This could lead to using the wrong algorithm, potentially causing significant issues

Best regards,
D.

[klayoutmatthias]

Well, I am not saying it can't be fixed, but to fixed it in all cases, I have to change something fundamental as to replace "overlapping" by "touching". That for sure has side effects, but it will be difficult to tell which.

I have too much on my plate to deal with this problem quickly, but I can try to fix in once I come across that code again.

[klayoutmatthias]

I think I found an easy and acceptable patch for the three-text problem described here.

The general topic of dropping texts for small cells remains. However, I'd like to point you to this option in "File/Setup":

If you disable this option, all texts will be rendered, even those of small cells. That way, the display will be accurate, but drawing performance may suffer and your screen may be filled with texts.

Matthias

[Kazzz-S]

Thank you for adding the new option. I have tested it on Linux Mint 20.3.
These test cases do not seem suitable for detecting the differences between the enabled and disabled states of the new option.
However, the three texts a,b,c are always displayed as expected.

gh1709-disabled-Lazy.mp4

gh1709-enabled-Lazy.mp4

Kazzz-S

[klayoutmatthias]

Hi @Kazzz-S,

I owe you an answer for your question about the difference when you use different settings for "lazy text rendering": this option does not display texts, when the cell is very small (smaller than 8x8 pixels).

So there should be a difference when you zoom out, or when the cell is point-like - i.e. only containing a single text.

Matthias