我正在構(gòu)建一個(gè)堆積條形圖，但是當(dāng)我為軸指定一個(gè)最小值時(shí)，條形圖的渲染會變形，并且軸比例/步長是錯(cuò)誤的。然而，我添加的系列確實(shí)按預(yù)期工作。這是初始圖表：當(dāng)我向軸提供最小值/最大值時(shí)：NumericAxis<MarketDataDetailsDecorator> axis = new NumericAxis<>();axis.setPosition(Chart.Position.BOTTOM);axis.setMinimum(995); // only this lineaxis.setMaximum(1016);// and this line get added您可以看到條形圖適用于完全不同的值，但藍(lán)線仍然正確。此外，軸以非線性方式遞增：995,997,999、1001,1003,1006,1008、1010、1012、1014,1016這是一個(gè)錯(cuò)誤，還是兩個(gè) - 還是我在 api 中遺漏了什么？這是突出問題的要點(diǎn)： https://gist.github.com/NimChimpsky/b4dc3dddc629ffefc7be2469eaa87d3a我正在嘗試顯示放大版本的條形圖，值范圍為 1002.5 - 1005.5，第一個(gè)圖表是正確的，但第二個(gè)圖表似乎是隨機(jī)分配值？
1 回答
尚方寶劍之說
TA貢獻(xiàn)1788條經(jīng)驗(yàn) 獲得超4個(gè)贊
我用這個(gè)條形圖以及我本地的 OP's gist 進(jìn)行了測試。
非零軸最小值問題
這絕對是繪制邏輯的錯(cuò)誤（相同的問題，但在 extjs 上）。忽略值的變化，這也給這個(gè)問題增加了進(jìn)一步的麻煩，假設(shè)我們將底軸的值maximum更新為，如果繪制圖表上條形圖的原始高度應(yīng)該是，它將減少到(derived from?)。minimumnhh - nh * (h-n)/h
例如;
在這里
h ~= 1000, 和n = 500, 所以我們看到繪制的條的無效高度是1000 - 500 = 500, 所以50%條的長度...
這里h ~= 100, 和
0n = 750, 和1000 - 750 = 250,25%
并且以 OP 的示例
h ~= 1000, 和n = 995, 因此我們看到極短的0.5%長度條。
可悲的是，我無法僅通過用戶可用的方法修復(fù)此問題，而無需訪問 中的糟糕代碼BarSeries，即使這樣做維護(hù)起來也很麻煩，而不是修改第 3 方非開源代碼的最佳選擇。我建議創(chuàng)建一張到這家公司的票...
超出軸范圍的數(shù)據(jù)問題
當(dāng)?shù)撞枯S的范圍減小到 時(shí)[95-105]，行為變得不穩(wěn)定，條形圖堆積在 x 軸后面。
所以看起來當(dāng)數(shù)據(jù)超出范圍時(shí)，就會出現(xiàn)這種錯(cuò)誤，圖表上的數(shù)據(jù)集沒有固有的隱藏/過濾邏輯。
軸標(biāo)簽步驟不一致問題
這似乎是使用默認(rèn)設(shè)置進(jìn)行步長計(jì)算近似的問題，即10 steps（實(shí)際上還有其他邏輯，但除非使用了一些更多的自定義設(shè)置，否則它將是10）。如果您給出一個(gè)手動(dòng)范圍，并且如果(max - min) % 10 != 0，那么由于步驟計(jì)算的近似值，您將遇到這樣的問題。
例如，讓我們使用[90-115], with?max - min = 25，這會產(chǎn)生以下問題；
如果你只是做數(shù)學(xué);
step?=?(max?-?min)?/?10?=?25?/?10?=?2.5
標(biāo)簽的價(jià)值；
90 + (2.5 x 0) = 90
90 + (2.5 x 1) = 92.5 ~= 93
90 + (2.5 x 2) = 95
90 + (2.5 x 3) = 97.5 ~= 98
...
所以這只是范圍和默認(rèn)步數(shù)之間的不匹配。您可以通過使用自定義步長量來調(diào)制它，axis.setSteps()在底部軸上使用一個(gè)將平均劃分該值的值max - min。
添加回答
舉報(bào)
0/150
提交
取消