Opened 8 years ago

Closed 7 years ago

Last modified 7 years ago

#13180 closed enhancement (fixed)

dojox.charting axis should support a drop label mode

Reported by: cjolif Owned by: cjolif
Priority: high Milestone: 1.8
Component: Charting Version: 1.6.1
Keywords: Cc: ccmitchellusa@…, cjolif
Blocked By: Blocking:

Description (last modified by cjolif)

When labels are too wide on a small axis, labels are overlapping. The axis should provide an optional parameter to automatically drop labels when they overlap.

In order to keep the axis understandable by the user the drop should occur consistently across the labels. For example either 1 over 2 labels should be dropped or 1 over 3 etc... but not just a single label dropped.

Attachments (2)

#13180.patch (31.0 KB) - added by cjolif 7 years ago.
draft patch, use dropLabels: true in axis to enable the feature (look at the test)
#13180.2.patch (32.8 KB) - added by cjolif 7 years ago.
second draft patch (caching the first label size computation)

Download all attachments as: .zip

Change History (19)

comment:1 Changed 8 years ago by Chris Mitchell

Milestone: tbd1.8

comment:2 Changed 8 years ago by cjolif

besides the drop to occur consistently another important point to care about is that when one will scroll the chart he does not want a different set of labels to be dropped. That means the operation must probably pre-computed on the full extend of the scale not just on the visible part.

comment:3 Changed 8 years ago by cjolif

Owner: changed from Eugene Lazutkin to cjolif

comment:4 Changed 8 years ago by cjolif

Description: modified (diff)

comment:5 Changed 8 years ago by cjolif

If it ends up being implemented, this would probably close #11088 as well, as #11088 is just a subset of that one (manual mechanism instead of automatic mechanism).

comment:6 Changed 7 years ago by cjolif

Cc: cjolif added; cjolif@… removed
Description: modified (diff)

comment:7 Changed 7 years ago by cjolif

The proposed solution is taking into account the drop mechanism that already exists for minor labels.

It means it will be a two steps process:

1/ if the max label width do not fit in minor step, then minor labels are ignored

2/ if minor labels are ignored and the max label width do not fit in a major step then the right amount of major labels are skipped to allow labels not to overlap.

Step 1/ will be enhanced compare to current implementation taken into account for example custom label function that might exist and are not taken into account currently.

Last edited 7 years ago by cjolif (previous) (diff)

Changed 7 years ago by cjolif

Attachment: #13180.patch added

draft patch, use dropLabels: true in axis to enable the feature (look at the test)

comment:8 Changed 7 years ago by cjolif

In the above patch, the computation is done each time the axis scale change. However there are two parts in this computation:

1/ compute the labels max size

2/ use that max size to know how many labels to drop

Phase 1 could be done only once and not re-done at each scale change (provided the fact the axis labels do not change on zooming in/out).

Changed 7 years ago by cjolif

Attachment: #13180.2.patch added

second draft patch (caching the first label size computation)

comment:9 Changed 7 years ago by cjolif

Resolution: fixed
Status: newclosed

In [27523]:

fixes #13180, #13257, #10962. As the new more costly drop labels mechanism does not hurt performance (because it also contains optimizations compare to previous version). I've kept it by default. !strict.

comment:6 Changed 7 years ago by cjolif

In [27614]:

refs #13180. Small code cleanup. !strict.

comment:7 Changed 7 years ago by cjolif

In [27639]:

refs #13180. Fixes a regression introduce by the enhancement when maxLabelSize is used on the axis. !strict.

comment:8 Changed 7 years ago by cjolif

#11088 is a duplicate of this ticket.

comment:9 Changed 7 years ago by cjolif

In [27769]:

refs #13180. Fixes an issue that shows up in mobileCharting demo following drop labels implementation. !strict.

comment:10 Changed 7 years ago by cjolif

In [27897]:

refs #13180. Make sure minorLabels/majorLabels true/false property are actually taken into account + small cleanups. !strict.

comment:11 Changed 7 years ago by cjolif

The implemented mechanism works well in most cases. A limitation is when the axis changed its labels sizes when being zoomed (for example if you did not specify steps to your axis it auto-compute them and the change dynamically leading to different numeric labels sizes). In this case you might want to pre-reserve more room for that. Ideally we should deal with that automatically but this would mean recomputing the size of the labels at each zoom action. Might be costly.

comment:12 Changed 7 years ago by cjolif

In [27936]:

fixes #14572. refs #13180. Workaround label overflow from gfx _getTextBox by puting limit on the # of labels we compute the size for. Also introduce a new flag for dropLabels label size to be re-computed on zoom for cases where this is necessary (and not forcing everyone to recompute if not needed). Also make sure axis minorLabels & majorLabels true/false are correctly taken into account. !strict.

comment:13 Changed 7 years ago by cjolif

In [27977]:

refs #13180. File forgotten in previous commit.

Note: See TracTickets for help on using tickets.