Charts: Peningkatan Kinerja

Hambatan kinerja asli dalam versi Android adalah banyak alokasi tambahan (array) di dalam kode rendering. Memori tidak boleh dialokasikan di dalam kode rendering. Jadi @PhilJay telah memindahkan kode itu ke Buffer yang dialokasikan sebelumnya, dan mendelegasikan kalkulasi rendering ke kelas Buffer saat rendering.

Saya memilih untuk tidak memindahkan kalkulasi rendering ke kelas Buffer, tetapi hanya mengalokasikan memori yang diperlukan dengan cara yang sama - tetapi memiliki kalkulasi rendering dalam loop yang sama dengan kode rendering. Dengan cara ini, jauh lebih mudah untuk mengelola kode.

Juga merupakan peningkatan kinerja yang kalkulasi rendering tidak dilakukan di dalam fungsi tambahan, dan data hanya diulang satu kali di dalam kode rendering, bukan dua kali.

Btw, dalam kinerja Swift JAUH JAUH lebih baik daripada Java, jadi Anda akan melihat peningkatan kinerja itu bahkan tanpa mengalokasikan array tersebut sebelumnya.

Untuk menjelaskannya secara grafis, inilah yang sedang / sedang dilakukan dalam kode rendering:

• [MULAI RENDER]
• Ulangi Kumpulan Data
• - Alokasikan array untuk titik dari Kumpulan Data ini - Sekarang dialokasikan sebelumnya di kedua platform
• - Hitung poin untuk rendering - _Pindah ke Buffer di versi Android_
• - Berikan poin itu
• [COMMIT RENDERING]

Perhatikan juga bahwa di Java, abstraksi (fungsi, kelas, warisan) memiliki harga yang mahal. Bukan tanpa alasan Google sendiri menulis rekomendasi penting :

Be careful with code abstractions

Often, developers use abstractions simply as a "good programming practice," 
because abstractions can improve code flexibility and maintenance. 
However, abstractions come at a significant cost: 
    generally they require a fair amount more code that needs to be executed, 
requiring more time and more RAM for that code to be mapped into memory. 
So if your abstractions aren't supplying a significant benefit, you should avoid them.

Kesimpulannya:

• Anda bisa merasa nyaman bekerja dengan ribuan titik data!
• Saya mencoba meyakinkan Phil untuk memindahkan kalkulasi titik kembali ke rendering loop agar lebih sederhana dalam pemeliharaannya ;-)

Terima kasih atas penjelasan Anda Daniel. Saya tidak begitu yakin apa yang harus diambil dari ini.
Apa yang telah saya lakukan adalah menyiapkan proyek paling dasar (lihat kode di bawah) dan kinerjanya tidak sebanding dengan versi Android, bahkan tidak sepenuhnya jujur. Menggunakan seribu titik data menghasilkan framedrop besar setelah Anda hampir menampilkan jumlah maksimum titik data (perkecil sepenuhnya) bahkan di sebagian besar perangkat iOS saat ini seperti iPad Mini3 dan iPhone6. Seperti yang saya katakan, MPAndroidcharts dapat merender beberapa ribu pada perangkat yang jauh lebih lambat tanpa kesulitan.

override func viewDidLoad () {
super.viewDidLoad ()

    lineChart = LineChartView(frame: view.frame);
    view.addSubview(lineChart);
    lineChart.backgroundColor = UIColor.whiteColor()
    lineChart.descriptionText = "Just a test"
    lineChart.leftAxis.enabled = false
    lineChart.legend.enabled = false

    setData(20)
}

func setData(range:Float) {

    var count = 1000;
    var xVals = Array<String>();

    for(var i = 0; i<count; i++) {
        xVals.append(String(i) + "");
    }

    var yVals = Array<ChartDataEntry>();

    for (var i = 0; i<count; i++) {
        var mult = range + 1
        var val:Float = Float(random()) * mult + 3;
        yVals.append(ChartDataEntry(value: val, xIndex: i));
    }

    var lineSet:LineChartDataSet = LineChartDataSet(yVals: yVals, label: " ");
    lineSet.drawCirclesEnabled = false;
    lineSet.drawValuesEnabled = false;

    var lineData:LineChartData = LineChartData(xVals: xVals, dataSet: lineSet);
    lineChart.data = lineData;
}

Saya belum menguji semua grafik untuk performanya - jadi saya harus melakukannya segera.
Hambatan mungkin adalah alokasi yang saya lewatkan di suatu tempat ... Saya akan menguji dan memberi tahu Anda! :-)

Terima kasih banyak Daniel. Menantikan apa yang dapat Anda peras dari ini. Sungguh luar biasa memiliki pendamping yang layak untuk MPAndroidCharts di iOS.

Yah, saya telah bermain sedikit dengan LineChartRenderer (yang sangat lambat dibandingkan dengan misalnya BarChartRenderer) dan Instruments mengatakan bahwa drawPath CGContext adalah penyebabnya di sini.
Saya mencoba mengurangi masalah ini dengan menggunakan UIBezierPath, tetapi kinerjanya sama segera setelah Anda memanggil stroke () di jalur. Sebelumnya, performa gambarnya bagus, tetapi jalurnya dipenuhi dengan titik awal dan akhir, bukan yang kita inginkan untuk diagram garis sederhana.
Semoga Anda sedikit lebih beruntung menemukan solusi untuk ini.

Saya sedang menguji ini sekarang, dan ya tampaknya CGContextStrokePath menderita kinerja yang buruk.
Salah satu pemukul utama adalah garis putus-putus. Saat menonaktifkannya, kinerja ~ dua kali lipat. Tapi masih miskin dengan seribu poin.
Saya sedang membaca beberapa dokumen Apple untuk mengetahui cara membuat CoreGraphics lebih cepat

Ya, Grafik Inti pasti membuat jalur menjadi lambat. Tampaknya terjadi karena resolusinya - resolusi pada perangkat Apple yang lebih baru sangat tinggi, yang berarti lebih banyak piksel untuk dirender.

Saya pikir CG dirender di CPU, bukan di GPU. Mungkin seseorang tahu cara untuk mengubahnya?

CG pasti menggunakan CPU untuk rendering dan sejauh yang saya tahu tidak ada cara untuk mengubahnya.
Sayangnya, rendering GPU berarti menggunakan OpenGL. Sayangnya CG itu lambat dibandingkan dengan cara Android menampilkan hal-hal ini di CPU.

Sebenarnya CPU perangkat yang lambat. Dalam banyak kasus sangat lambat
CPU memberikan pengalaman yang jauh lebih baik dengan iOS daripada CPU cepat dengan Android.

Tetapi Apple tidak memikirkan kasus-kasus di mana OS yang optimal tidak
cukup untuk menyimpannya dengan cepat.

Saya rasa ketika kita menggunakan banyak poin kita bisa menghindari animasi - Tapi
Saya masih berharap menemukan cara untuk meningkatkan kinerja Line
grafik berbasis.

Sepertinya secara khusus sistem gambar Path lambat, dan kapan
bermain dengan Mitre dan Flatness, dan menonaktifkan garis putus-putus dan
Antialiasing - kinerja menjadi jauh lebih baik untuk 500-700 poin pada file
iPhone 6, tapi masih dendeng dengan 1000

Mungkin ada peluang dengan menggunakan UIBezierPath. Seperti yang saya katakan, hal itu cukup cepat segera setelah Anda tidak memanggil 'stroke', yang pada dasarnya memberi tahu sistem bahwa jalurnya adalah goresan dan tidak boleh diisi dari titik awal ke titik akhir. Saya tidak tahu apa yang terjadi dengan itu di latar belakang, tetapi ini menunjukkan bahwa gambar grafik itu sendiri bukanlah masalah dengan sendirinya.

Namun, karena saya tidak dapat menemukan cara untuk menggunakan UIBezierPath dengan benar untuk diagram garis, ini mungkin merupakan kandidat yang layak untuk garis grid karena seseorang dapat mengelabui jalur untuk menggambar tanpa memanggil goresan. Meskipun itu 'salah' dari sudut pandang API, itu seharusnya menghasilkan kinerja yang lebih baik.

UIBezierPath hanyalah pembungkus UIKit di sekitar CGPath, CGContextDrawPath,
dll.
Perbedaan kinerja yang diamati dalam beberapa kasus disebabkan oleh hal itu
menyiapkan CG terlebih dahulu, dengan properti UIBezierPath dari
antialiasing, batas mitra, dll.

Sebenarnya sama sekali tidak ada alasan untuk menggunakannya bila Anda tahu cara menggunakannya
Grafik Inti.

Dan ya, kita perlu memanggil "pukulan", karena kita memang ingin membelai jalur itu ...
bukan untuk mengisinya.
Membelai dalam banyak kasus lebih sulit bagi sistem daripada mengisi padatan
warna, karena perlu menjaga lebar garis, gabungan
antara garis dan bentuk sambungan.

Pada hari Jumat, 17 Apr 2015 pukul 10.50, AlBirdie [email protected] menulis:

Mungkin ada peluang dengan menggunakan UIBezierPath. Seperti yang saya katakan, hal itu
cukup cepat jika Anda tidak memanggil 'stroke', yang pada dasarnya
memberi tahu sistem bahwa jalurnya adalah goresan dan tidak boleh diisi dari
titik awal ke titik akhir. Saya tidak tahu apa yang terjadi dengan itu
latar belakang, tetapi ini menunjukkan bahwa gambar grafik itu sendiri bukanlah
masalah dengan sendirinya.

Namun, karena saya tidak dapat menemukan cara untuk menggunakan UIBezierPath dengan benar
diagram garis, itu mungkin menjadi kandidat yang layak untuk garis grid sebagai satu
bisa mengelabui jalur untuk menggambar tanpa memanggil goresan. Meski begitu
'salah' dari sudut pandang API, seharusnya menghasilkan kinerja yang lebih baik.

-
Balas email ini secara langsung atau lihat di GitHub
https://github.com/danielgindi/ios-charts/issues/29#issuecomment -93937181
.

@danielgindi pernahkah Anda berpikir tentang bahwa jika animasi memperlambat segalanya, bagaimana jika menggambar semua garis tanpa animasi, dan menggunakan tampilan topeng yang menutupinya, kemudian menganimasikan tampilan topeng untuk meniru animasi?

Nah, itu ide yang bagus! :)

Meskipun ada sisi negatifnya:
Ini akan melumpuhkan jenis animasi yang dapat Anda lakukan dengannya. seperti yang kami izinkan
menganimasikan sumbu Y sehingga diagram "tumbuh", dan cara garis terisi
pada sumbu X juga berbeda dengan saat hanya ada goresan.

Daftar hal yang harus saya coba adalah:

1. Entah bagaimana, tingkatkan CoreGraphics atau tingkatkan bagian rendering ke file
   GPU
   
   
   
   1. Pra-render semua bingkai animasi- ini akan menunda dimulainya animasi, dan
      
      mengkonsumsi banyak memori
   
   
   2. Ide masking Anda- yang membatasi jenis animasi
   
   

Jika ada ide lain, saya ingin mendengarnya!

Daniel, apakah Anda sudah mencoba memindahkan pekerjaan ke GPU?
Saya benar-benar tidak senang dengan solusi komersial yang saat ini kami kerjakan (API yang buruk, ditutup dengan sangat buruk, dan banyak bug yang menyebabkan aplikasi mogok), dan sangat sukses dengan MPAndroidCharts, kami ingin sekali beralih ke iOS-chart pada akhirnya jika kinerjanya setara. Yakinlah, pekerjaan Anda akan dihargai. ;)

Mencoba beberapa teknik berbeda, saya akan memberi Anda pembaruan dalam beberapa hari!

Pada hari Senin, 20 Apr 2015 pukul 12:38, AlBirdie [email protected] menulis:

Daniel, apakah Anda sudah mencoba memindahkan pekerjaan ke GPU?
Saya benar-benar tidak senang dengan solusi komersial saat ini
bekerja dengan (API yang buruk, ditutup dengan sangat buruk, dan banyak bug yang menyebabkannya
aplikasi mogok), dan sukses besar dengan MPAndroidCharts, kami akan melakukannya
senang beralih ke bagan iOS pada akhirnya jika kinerjanya setara. Beristirahat
yakin, pekerjaan Anda akan dihargai. ;)

-
Balas email ini secara langsung atau lihat di GitHub
https://github.com/danielgindi/ios-charts/issues/29#issuecomment -94408574
.

@AlBirdie, hambatan kinerja seperti apa yang Anda temui? Saat ini saya memiliki produk yang menggambar grafik seperti ios-charts, kami sudah memiliki perpustakaan grafik secara internal. Saya juga khawatir tentang kinerja, saat ini, kami baru saja memuat 100-1000 kumpulan data, sepertinya baik-baik saja sekarang.

Saya juga mempertimbangkan untuk beralih ke grafik-ios jika memungkinkan di masa mendatang, tetapi perpustakaan kami memiliki isyarat yang mungkin bertentangan dengan grafik-ios.

Masalah kinerja adalah kecepatan bingkai yang lambat dalam animasi saat harus melakukannya
gambar 500-1000 garis dalam grafik garis.

Mengenai Gestur - kami menggunakan UIGestureRecognizers standar - yang Anda gunakan
dapat menonaktifkan, memodifikasi, atau bekerja dengan. Semuanya standar. :-)

Pada hari Senin, 20 Apr 2015 pukul 12:53, Xuan [email protected] menulis:

@AlBirdie https://github.com/AlBirdie kinerja seperti apa
kemacetan Anda bertemu? Saat ini saya memiliki produk yang hanya menggambar grafik
seperti ios-charts, kami sudah memiliki perpustakaan grafik secara internal. Saya juga prihatin
soal kinerja, saat ini kita baru memuat 100-1000 set data, sepertinya ok
sekarang.

Saya juga mempertimbangkan untuk beralih ke ios-chart jika memungkinkan di masa mendatang,
tapi perpustakaan kami memiliki isyarat yang mungkin bertentangan dengan diagram ios.

-
Balas email ini secara langsung atau lihat di GitHub
https://github.com/danielgindi/ios-charts/issues/29#issuecomment -94411060
.

@danielgindi baiklah, saya pikir kami menggunakan tampilan topeng untuk mengatasi animasi ... Bagan garis kami memiliki lapisan gradien. Sebagai demo Anda, animasi Anda dapat melakukan kedua arah X + Y secara bersamaan, sementara kami hanya melakukan arah X. Saya tidak yakin apakah trik topeng dapat membantu Anda.
Apa yang ada dalam pikiran saya sekarang adalah bahwa jika kita memiliki vektor untuk menggambarkan arah X + Y Anda, mungkin ada kesempatan untuk menggunakan trik topeng ... nantikan hasil Anda!

@ liuxuan30 kinerja lambat hanya umum kurasa. Animasi tidak menjadi masalah karena saya tidak mengerjakannya. Saya sedang mengerjakan grafik keuangan di mana Anda perlu memiliki beberapa kumpulan data dalam satu grafik (beberapa saham + berbagai indikator). Untuk rentang data 250 item yang dengan mudah menambahkan hingga beberapa ribu poin yang perlu diberikan sekaligus selama panning dan pinching. Solusi komersial yang saat ini saya kerjakan melakukannya dengan cukup baik (menggunakan OpenGL Anda dapat membuat ribuan poin tanpa membebani CPU), tetapi saya bukan teman perpustakaan sumber tertutup di mana Anda harus menunggu berbulan-bulan untuk perbaikan bug.
Saya akan merasa jauh lebih nyaman dengan ios-charts, terutama karena API MPAndroidCharts sangat mudah digunakan.

Begitu, data keuangan adalah bencana. Server kami memaksa untuk hanya mengirim hingga 1000 set data ke perangkat seluler, sehingga mengurangi kelebihan beban kami. Apakah ada peluang untuk menggunakan OpenGL untuk ios-charts? @danielindonesia

Dukungan OpenGL akan menjadi ace. Grafik garis yang dirender GPU mungkin sudah cukup untuk saat ini.
Sayangnya, saya sama sekali tidak tahu tentang OpenGL, jika tidak, saya akan dengan senang hati membantu.

Ada peningkatan dengan CGContextStrokeLineSegments dibandingkan dengan menggunakan jalur, jadi Anda harus mencobanya.
Masih mencoba cara lain untuk meningkatkan sesuatu :-)

Terima kasih Daniel, saya akan membuat aplikasi uji kecil yang membandingkan kedua versi tersebut untuk melihat apa. Keuntungan kinerja apa yang Anda peroleh dengan menggunakan LineSegments baru?

@AlBirdie apakah Anda merasakan perbedaan dengan segmen garis?

Juga saya baru menyadari: Di ​​android untuk mendapatkan kinerja maksimum Anda mengaturnya ke lapisan perangkat keras- dalam hal ini garis putus-putus tidak putus-putus, semuanya solid.

Jadi hal pertama jika Anda menonaktifkan garis putus-putus di iOS Anda juga mendapatkan dorongan yang signifikan!

Tapi saya pikir saya benar-benar bisa menggambarnya menggunakan OpenGL ES di CIImage, tetapi harus sangat berhati-hati karena jika satu garis GL berjalan saat aplikasi tidak aktif - itu akan macet.

Juga ada kemungkinan saya masih bisa mengizinkan tanda hubung dengan pra-rendering tekstur. Ini akan membutuhkan beberapa pekerjaan dan itu bukan prioritas utama saya, tetapi saya memulai proyek sampingan dari lapisan OpenGL yang dapat menggantikan CGContext dengan mulus.

Daripada membuka OpenGL untuk menggambar, Anda juga bisa mencoba menurunkan ke Animasi Inti. Mungkin kelas CAShapeLayer bisa bekerja. Apple merekomendasikan untuk menggunakan beberapa CAShapeLayer s saat membuat jalur yang rumit, jadi Anda mungkin perlu memecah segmen garis menjadi beberapa segmen. Menggunakan Animasi Inti harus memindahkan pekerjaan ke GPU.

Selama bertahun-tahun dalam pekerjaan saya, kami telah menggunakan produk komersial yang seperti disebutkan di atas oleh @AlBirdie menggunakan OpenGL secara ekstensif, dan dengan demikian melewati CoreGraphics untuk segala hal kecuali anotasi. Tentunya mereka tampaknya mampu menangani kumpulan data yang cukup besar dengan rendering yang cukup mulus dan mereka mengklaim menggunakan GPU untuk ini. Namun pendekatan mereka datang dengan sakit kepala besar, tidak terkecuali bug yang tampaknya tidak dapat direpotkan untuk diperbaiki seperti panggilan rendering asinkron yang macet di OpenGL karena aplikasi telah beralih ke latar belakang, struktur kelas idiot dan pembatasan gila pada kemampuan penyesuaian. Apa yang saya inginkan tidak ada hari ini, tetapi di iOS-Charts saya melihat bahwa itu mungkin cara untuk sampai ke sana. Bagaimanapun, bagi saya keandalan menang atas kinerja setiap saat, tetapi dengan margin terkecil, keduanya sangat penting.

ps menurut pendapat saya garis putus-putus adalah mabuk dari hari-hari ketika komputer tidak memiliki opsi untuk membuat warna atau bahkan skala abu-abu - mereka tidak diperlukan kecuali kita menampilkan hitam dan putih murni dan membuat sesuatu yang terlihat seperti tua buku teks cetak letterpress, tentunya? ;) Jadi jauh lebih penting untuk mengoptimalkannya daripada mengoptimalkan untuk kasus 10K poin umum.

Terima kasih kepada Anda @onlyforart tentang garis putus-putus.
Berdasarkan deskripsi Anda tentang pustaka diagram komersial Anda, saya bertanya-tanya apakah kami telah menggunakan produk yang sama. :) Kami akhirnya membuangnya. Apa yang membuat saya membutuhkan waktu tiga bulan untuk mengimplementasikannya (bahkan itu tidak cukup lama untuk mengatasi bug dan batasan yang parah (misalnya crosshair), hanya butuh dua minggu dengan iOSCharts ('struktur kelas idiot';)). Buang-buang waktu dan uang.

@AlBirdie ya itu dia. Jangan sebutkan garis bidiknya. Dibuat dengan bantuan terlalu banyak Newcastle Brown Ale dan tidak diragukan lagi ditujukan untuk pasar korporat (di mana API gnarly sebenarnya merupakan faktor penjualan yang positif, karena mengunci pelanggan ke dalam siklus dukungan / pemeliharaan yang mahal). Tahukah Anda sejarah orang-orang itu? sebenarnya (di masa lalu) mereka adalah pelopor nyata dalam industri perangkat lunak. Pokoknya saatnya untuk melangkah maju dan melihat ke masa depan sekarang.
Kami kebanyakan menggambar grafik Candlestick (ini adalah aplikasi sektor keuangan). Yang benar-benar saya inginkan untuk iOS dan Android adalah sesuatu yang sebenarnya sangat mudah dengan HighCharts / HighStock di dunia HTML5 / Javascript:

1. sejumlah besar titik data (10K atau lebih)
2. penggabungan otomatis data OHLC ke dalam batang berskala yang masuk akal (misalnya, menampilkan bilah 1 jam saat faktor zoom sesuai, atau bilah 1 m atau 1 saat diperbesar)
3. menggeser dan menggeser dengan mulus
4. cubit untuk memperbesar
5. overlay beberapa seri data dan anotasi dan crosshairs, beberapa secara terprogram dan beberapa oleh interaksi pengguna misalnya untuk menetapkan harga batas, semua ditampilkan dengan lancar
6. (inilah kickernya - HighStock tidak membantu dengan ini! meskipun tampaknya cukup jelas bagi saya) pengambilan data secara bertahap (dengan lookahead) misalnya mengambil data resolusi rendah untuk seluruh dataset dan, seperti halnya aplikasi peta, mengambil hi-rez data (mis. data "centang" milidetik) hanya untuk area yang dilihat dari grafik
   Kami belum menggunakan iOS-Charts meskipun itu ada di daftar "yang harus dilakukan" dan semakin dekat ke atas, jadi saya belum terlalu banyak melihat ke dalam kode, tetapi segera setelah saya melakukannya - mungkin bulan depan - Saya akan memeriksa semua itu.
   Kembali ke rendering, kecenderungan OpenGL untuk crash jika situasinya kurang sempurna adalah sebuah kekhawatiran. GLKit dapat membantu menggambar GPU; Saya juga bertanya-tanya beberapa waktu yang lalu apakah SpriteKit dapat membantu (rendering grafik bukanlah jutaan mil dari membuat game), tetapi saat ini GLKit tampaknya merupakan kandidat yang lebih baik.

LOL @onlyforart , Anda memiliki saya di Newcastle Brown Ale. : +1: :)
Saya setuju dengan kebutuhan Anda (mengerjakan produk keuangan juga), tapi ya, mari kita kembali ke gambar sebenarnya dari grafik ini. Menantikan temuan Anda di masa mendatang.

@onlyforart , @AlBirdie terima kasih atas wawasan Anda :-)

Senang sekali melihat orang-orang membuang produk perusahaan komersial untuk perpustakaan kita, meskipun saya merasa tidak enak untuk mereka ... saya berkonflik!

Saya ragu-ragu untuk membiarkan OpenGL memiliki bagian dari ini karena saya tahu ada kemungkinan crash jika tidak dikelola dengan sempurna, dan itu tidak mungkin dilakukan dalam aplikasi UIKit. Jika Anda menggunakan OpenGL untuk membuat game, semuanya adalah kanvas OpenGL dan Anda tidak perlu khawatir tentang panggilan UIKit yang mencoba menyebabkan rendering OpenGL saat berada di latar belakang.

@onlyforart poin Anda tentang garis putus-putus benar, tetapi sayangnya saya memiliki pengalaman dengan klien yang menuntut garis putus-putus. Ada kasus di Android di mana untuk meningkatkan kinerja pengembang harus mengubah lapisan menjadi lapisan perangkat keras, dan memberi tahu klien bahwa garis putus-putus akan menjadi garis padat, itulah biayanya. Dan tentu saja ada opsi untuk memindahkan semua kode gambar ke OpenGL, tetapi menggambar satu baris saja memusingkan, tetapi Anda dapat membuat tekstur untuk garis putus-putus dan mengerjakannya. Mereka tidak ingin membayarnya, jadi garis putus-putus jelas tidak terlalu kritis, tetapi mereka membuat banyak keributan tentang hal itu.

Catatan untuk saya sendiri: Coba gunakan GLKit untuk rendering. Lihat apa yang terjadi.

Dan jika saya mengambil daftar Anda:

1. _ "sejumlah besar titik data (10K atau lebih)" _ - kami sedang mengerjakannya :) Saya tidak bisa mengatakan tentang Android, karena memindahkannya ke GL akan menjadi PITA yang lebih besar, tetapi sudah memiliki kinerja yang cukup bagus dengan memanfaatkan lapisan perangkat keras, yang melakukan semua penggambaran pada GPU.
2. _ "konsolidasi otomatis data OHLC ke dalam batang berskala yang masuk akal" _ - kita akan segera menggunakan filter perkiraan, jadi saya pikir itu akan membereskannya. Alih-alih memiliki banyak bilah 1m yang tidak dapat Anda baca, Anda akan memiliki perkiraan bilah 1 jam, dll.
3. _ "menggeser dan menggeser dengan mulus" _ - selesai :-)
4. _ "cubit untuk memperbesar" _ - selesai :-)
5. _ "menghamparkan beberapa seri data dan anotasi serta garis silang" _ - Saya tidak tahu apakah saya memahaminya dengan benar, tetapi saat ini ada diagram Gabungan yang dapat menghamparkan beberapa jenis diagram, dan setiap jenis diagram dapat menerima beberapa set data. Selain itu, Anda selalu dapat terhubung ke ViewPortHandler dan mengambil koordinat sehingga Anda dapat melapisi apa pun yang Anda inginkan di atas karakter.
6. pengambilan data secara bertahap - kami berencana mengabstraksi sumber data, sambil tetap memiliki API lama untuk menyetel set data statis (ini hanya akan menjadi sumber data bawaan yang berfungsi dengan itu). Saya rasa ini juga akan sesuai dengan kebutuhan Anda, tetapi kami belum tahu kapan kami akan melakukannya

@danielgindi , jangan merasa kasihan pada mereka. Jika produk yang Anda kembangkan pada dasarnya adalah tomat busuk, namun Anda masih meminta sedikit biaya untuk itu, orang-orang pada akhirnya akan pindah ke produk lain. Tidak ada yang salah dengan itu. Saya telah mengembangkan bagan keuangan selama beberapa tahun sekarang, telah menggunakan hampir semua solusi untuk iOS yang saat ini ada di luar sana, dan sebenarnya telah menulis mesin bagan saya sendiri di ActionScript3 pada masa itu, jadi saya merasa cukup percaya diri mengatakan itu iOSCharts dan MPAndroidCharts sebenarnya adalah satu-satunya produk yang saat ini saya rekomendasikan kepada pengembang mana pun yang membutuhkan pembuatan bagan di aplikasinya. Segala sesuatu yang lain di luar sana tidak cukup.

Mengenai persyaratan kedua, jika kalian akan menerapkan ini, itu harus opsional. Kami memiliki jenis konsolidasi seperti ini di salah satu produk pembuatan bagan kami dan sebagai gantinya pelanggan beralih dengan mantap ke frekuensi tetap. Mengubah frekuensi saat melakukan zooming ternyata tidak hanya membingungkan pengguna grafik keuangan rata-rata, pengguna listrik pun jengkel karena mereka menginginkan frekuensi tetap.

Kami tidak pernah membayangkan memaksakan ini pada pengguna! Anda dapat melihat bahwa kode sudah menyertakan Filter, dan di MPAndroidCharts Anda dapat melihat filter secara historis diaktifkan oleh properti yang menyetel filter (filter khusus apa pun atau filter bawaan), tetapi dihapus nanti karena perubahan struktural.

Ketika kami menerapkannya, fungsinya akan tetap sama - itu hanya akan menjadi fitur keren lainnya :-)

@AlBirdie Re "Mengenai persyaratan kedua, jika kalian akan menerapkan ini, itu harus bersifat opsional. Kami memiliki jenis konsolidasi seperti ini di salah satu produk charting kami dan pelanggan terus berpindah ke frekuensi tetap sebagai gantinya. frekuensi selama zooming ternyata tidak hanya membingungkan bagi pengguna grafik keuangan rata-rata, pengguna listrik merasa terganggu karena mereka menginginkan frekuensi tetap. " Sepenuhnya setuju - ini untuk grafik untuk pengguna informasional / non-perdagangan. Pengguna perdagangan memiliki kebutuhan yang berbeda.

@danielgindi Re "mengabstraksi sumber data" mungkin ini adalah sesuatu yang dapat kami sumbangkan, jika kami punya waktu. Tidak ada janji, tapi saya akan menambahkannya ke backlog kami.

Apakah ada yang bermain-main dengan membagi kode gambar ke utas terpisah (CALayer.drawsAsynchronously)? Itu mungkin membantu jika ini memungkinkan untuk menggambar ekstra grafik, setiap dataset, grid dan sumbu secara terpisah. Mengingat pengalaman saya yang sangat sederhana dengan CoreGraphics (baca; tidak ada sama sekali ;-)), saya belum melakukan eksperimen apa pun dengan ini, saya baru menemukannya ketika saya mencari GLKit dan bagaimana hal itu dapat meningkatkan kinerja grafik.

Saya perlu menunjukkan grafik candle stick dengan 10k poin data jadi saya menjalankan beberapa pengukuran waktu di CandleStickChartRenderer.drawDataSet ().

Ternyata sebagian besar waktu dihabiskan untuk memanggil dataSet.entryIndex (baris 76,77).

Saya mungkin salah, tetapi sepertinya panggilan dataSet.entryIndex () berlebihan karena _minX, nilai _maxX selalu sama dengan minx, maxx dikembalikan dari dataSet.entryIndex ()

Saya telah berhasil membuat grafik candle stick dengan 10k titik data pan / zoom dengan lancar. dengan mengganti
CandleStickChartRenderer.swift, baris 76,77 dari:

var minx = max (dataSet.entryIndex (entri: entryFrom, isEqual: true), 0);
var maxx = min (dataSet.entryIndex (entri: entryTo, isEqual: true) + 1, entries.count);

untuk

var minx = max (_minX, 0);
var maxx = _maxX + 1;

Saya telah membuat perubahan yang sama pada LineChartRenderer dan dapat menunjukkan grafik candle stick / garis gabungan dengan 2 seri data (masing-masing 10k poin data)

Wow, itu peningkatan kinerja yang luar biasa @dorsoft !

Saya baru saja menguji ini dan saya tidak bisa mempercayai mata saya. Bahkan pada iPad 2 dengan 4 CombinedChart yang menampilkan hingga tiga kumpulan data masing-masing dengan 250 titik data dan perhitungan min / maks otomatis dari sumbu y, kami sekarang dapat menggeser dan memperbesar semua grafik secara bersamaan dengan cara yang cukup mulus. Ini bukan 60fps, tapi mendekati. Mengesankan untuk perangkat lama dan JAUH (!) Lebih cepat daripada solusi OpenGL komersial yang telah kita bicarakan sebelumnya.

Saya rasa saya harus mencoba ini :) Dan perlu berdiskusi dengan Phil juga untuk
mengerti jika ada implikasinya ...

Saya baru saja membaca ini, terlihat sangat menarik tetapi perlu beberapa pengujian intensif untuk melihat apakah ini benar-benar cocok untuk semua skenario :-)

Saya telah membuat PR dengan peningkatan kinerja grafik lilin.
Peningkatan telah diuji secara menyeluruh menggunakan skala otomatis min / max dan nilai nihil.

Saya telah menemukan kemungkinan kemacetan. Dalam grafik waktu nyata Menambahkan banyak entri per detik ke grafik, saya perhatikan bahwa secara otomatis calcMinMax dari kumpulan data dipanggil tepat setelah SETIAP values.append(e)

Fungsi calcMinMax menentukan nilai min dan max menggunakan .forEach yang menyebabkan CPU menghabiskan lebih dari 60% untuk mengulang nilai, apalagi di thread utama.

Saya melakukan beberapa eksperimen yang menonaktifkan kalkulasi min / max atau menggunakan native for loop alih-alih array .forEach

@danielgindi tolong lihat, apakah benar-benar calcMinMax pada semua nilai yang dibutuhkan? Saya menghitung nilai min / maks Y secara manual dalam kode saya dan hanya pada nilai yang terlihat , jadi mungkin Anda dapat mengekspos beberapa boolean untuk mengaktifkan / menonaktifkan penghitungan otomatis min / maks dan meningkatkan kinerja dengan menghapus fungsi forEach dan menghindari pemanggilan fungsi.

```
open override func calcMinMax()
{
    guard !values.isEmpty else { return }

    _yMax = -Double.greatestFiniteMagnitude
    _yMin = Double.greatestFiniteMagnitude
    _xMax = -Double.greatestFiniteMagnitude
    _xMin = Double.greatestFiniteMagnitude

    values.forEach { calcMinMax(entry: $0) }
}

``

@samueleperricone Tolong jadikan ini tiket terpisah dan saya akan memprioritaskan ini.

@jjatie Terima kasih, Buka saja # 3166

Saya memuat lebih dari 13000 rekaman di bagan garis untuk iOS. Namun, bagan membekukan UI saat memuat. Selain itu, setelah memuat Jika pengguna memilih titik mana pun, maka dibutuhkan terlalu banyak waktu untuk menyorot pilihan tersebut.