How to hide ticks on one axis while preserving labels in Lilaq?

Questions
1

This, but only for xaxis.

2

Hi, this will be possible with the next version due to new work on elembic by @PgBiel which enables conditional show rules.

Edit: actually now I think about it, this particular thing might be trickier because of an implementation detail that improves performance. Doing anything with tick labels per axis will be easy but the ticks themselves are drawn in one batch instead of through their type because it’s just too slow to create this many elembic elements.

1 Like
3 
#show: lq.cond-set(lq.tick.with(kind: "y"), inset: 0pt, outset: 0pt)
#show lq.selector(lq.tick.with(kind: "y")): lq.set-tick(inset: 0pt, outset: 0pt)
#show lq.selector(lq.tick.with(kind: "y")): none

Doesn’t do anything. Only #show: lq.set-tick() works. For both axis.

4

Yes, I know …

That is a bit unfortunate but currently I cannot change it. We need to wait for built-in user-defined types.

The reason is that elembic types have too large of a performance overhead to use them for each and every tick. The solution I therefore went for was to “get” the fields of lq.tick and then just draw the ticks without the lq.tick type according to the values. But that also means that more fine-grained changes like conditional set rules are not picked up.

5

I think splitting just x/y ticks is pretty generic. You can get the tick data once per axis, which shouldn’t dig into performance more than now. I guess you would have to have some separate xTick and yTick elements to be able to save all metadata for both. Not sure how flexible elembic with this now.

Also, the release notes were very misleading in showing .with(kind: "x") for grid element, but the exact same thing for tick element doesn’t work, and it is not highlighted. Yet, the tick does now have kind field. The tick kind is now only works for explicitly placed tick elements, I guess.

6

Also, the release notes were very misleading in showing .with(kind: "x") for grid element, but the exact same thing for tick element doesn’t work, and it is not highlighted.

Yeah sorry, initially I also thought that this issue could now be resolved, but sadly no.

The tick kind is now only works for explicitly placed tick elements, I guess.

Exactly, for extra-ticks, this works .

I think splitting just x/y ticks is pretty generic. You can get the tick data once per axis, which shouldn’t dig into performance more than now. I guess you would have to have some separate xTick and yTick elements to be able to save all metadata for both. Not sure how flexible elembic with this now.

I don’t want to have two separate elements for x and y because then it won’t be possible to address all ticks at once which is far more common than addressing just the x or y ticks. Unfortunately, I don’t think elembic currently allows to ask for the fields in a certain conditional context.

7

I don’t get why per-axis grid works. Can’t you do the exact same number of lines as there are ticks? If so, then why performance doesn’t matter with grid, but with ticks it does?

8

For the grid, there are actually instances of the type lq.grid generated internally. This is not the same as with ticks. Here, no lq.tick is created, but just a regular function that draws the tick.

Now why does the performance matter? The grid lines are mostly just shown for regular ticks, not for subticks. That’s an average of, say, 3-4 times fewer grid lines than ticks. Plus, the ticks are by default shown at the left+right, top+bottom while grid lines are just created once. That makes another factor of 2. All in all almost an order of magnitude less grid lines.

Of course, this only holds in the default case. But it’s the most common one and at the time I did a few measurements and I was not willing to pay the loss in performance when tick elements are created (I actually spent far too much time trying to fix this).

1 Like