I've added now a first version of my planned realtime charting on the status page in the 'Query statistics'-Tab (click on "Realtime chart"). You can check it out at http://demo.phpmyadmin.net/gsoc-tyron
Currently it aggregates the average queries per second by making an ajax request every 2-2.5 seconds (2 seconds + time for one ajax request). Since it is using the differential of the status var 'questions' it takes some seconds to display a line.
For the chart I'm currently using Highcharts because it allows realtime data, animates beautifully, is really small (1 file, 77kb minified) and has a export to png/pdf/jpg plugin (6.4kb minified) which however uses a highcharts.com server for the conversion.
Some radical suggestion in this regard: What about removing the included pChart and instead using a client-side charting library? I know for some part its bad since a student wrote a whole lot of code for it just last year, but looking at some requirements for phpmyadmin (no file storage, limited possibilities for data recording, panning/zooming, realtime updates) a server-side charting library offers much less possibilities compared to a client side-one. And if we'd use highcharts it would save us like 16 files and 750kb (well most of it is that dejavu font). I think it would be pretty easy to replace actually. Instead of the graph, the server-code would just need to send the already generated chart data hidden in the document and then we add a bit of js code to display the chart. Some code from chart.lib.php is probably reusable.
Please let me know what you think and whether I should continue working in this direction. Thanks! :)
On 31-05-11 00:12, Tyron Madlener wrote:
I've added now a first version of my planned realtime charting on the status page in the 'Query statistics'-Tab (click on "Realtime chart"). You can check it out at http://demo.phpmyadmin.net/gsoc-tyron
Currently it aggregates the average queries per second by making an ajax request every 2-2.5 seconds (2 seconds + time for one ajax request). Since it is using the differential of the status var 'questions' it takes some seconds to display a line.
For the chart I'm currently using Highcharts because it allows realtime data, animates beautifully, is really small (1 file, 77kb minified) and has a export to png/pdf/jpg plugin (6.4kb minified) which however uses a highcharts.com server for the conversion.
Depending on an external service is not an option in my opinion.
Some radical suggestion in this regard: What about removing the included pChart and instead using a client-side charting library? I know for some part its bad since a student wrote a whole lot of code for it just last year, but looking at some requirements for phpmyadmin (no file storage, limited possibilities for data recording, panning/zooming, realtime updates) a server-side charting library offers much less possibilities compared to a client side-one. And if we'd use highcharts it would save us like 16 files and 750kb (well most of it is that dejavu font). I think it would be pretty easy to replace actually. Instead of the graph, the server-code would just need to send the already generated chart data hidden in the document and then we add a bit of js code to display the chart. Some code from chart.lib.php is probably reusable.
Please let me know what you think and whether I should continue working in this direction. Thanks! :)
Last year other options were also evaluated. The chosen solution had the advantage that it did not require JS, although that's becoming less of an argument these days.
Doing 'the 'hard work' on the client seems attractive and looks cool. I remember that some of the client sided options also required flash, that would not be good.
As we last year tried to setup an extensible/flexible chart structure I would be best to improve on that. Adding an additional chart system in parallel would be just too mush...
On Tue, May 31, 2011 at 9:44 AM, Herman van Rink rink@initfour.nl wrote:
On 31-05-11 00:12, Tyron Madlener wrote:
I've added now a first version of my planned realtime charting on the status page in the 'Query statistics'-Tab (click on "Realtime chart"). You can check it out at http://demo.phpmyadmin.net/gsoc-tyron
Currently it aggregates the average queries per second by making an ajax request every 2-2.5 seconds (2 seconds + time for one ajax request). Since it is using the differential of the status var 'questions' it takes some seconds to display a line.
For the chart I'm currently using Highcharts because it allows realtime data, animates beautifully, is really small (1 file, 77kb minified) and has a export to png/pdf/jpg plugin (6.4kb minified) which however uses a highcharts.com server for the conversion.
Depending on an external service is not an option in my opinion.
Some radical suggestion in this regard: What about removing the included pChart and instead using a client-side charting library? I know for some part its bad since a student wrote a whole lot of code for it just last year, but looking at some requirements for phpmyadmin (no file storage, limited possibilities for data recording, panning/zooming, realtime updates) a server-side charting library offers much less possibilities compared to a client side-one. And if we'd use highcharts it would save us like 16 files and 750kb (well most of it is that dejavu font). I think it would be pretty easy to replace actually. Instead of the graph, the server-code would just need to send the already generated chart data hidden in the document and then we add a bit of js code to display the chart. Some code from chart.lib.php is probably reusable.
Please let me know what you think and whether I should continue working in this direction. Thanks! :)
Last year other options were also evaluated. The chosen solution had the advantage that it did not require JS, although that's becoming less of an argument these days.
Doing 'the 'hard work' on the client seems attractive and looks cool. I remember that some of the client sided options also required flash, that would not be good.
As we last year tried to setup an extensible/flexible chart structure I would be best to improve on that.
Well I guess it might be possible to use that structure for a client-side graphing library aswell. It probably will require some inline-js however.
Adding an additional chart system in parallel would be just too mush...
-- Met vriendelijke groet / Regards,
Herman van Rink Initfour websolutions
Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Hi
Dne Tue, 31 May 2011 00:12:31 +0200 Tyron Madlener tyronx@gmail.com napsal(a):
I've added now a first version of my planned realtime charting on the status page in the 'Query statistics'-Tab (click on "Realtime chart"). You can check it out at http://demo.phpmyadmin.net/gsoc-tyron
Currently it aggregates the average queries per second by making an ajax request every 2-2.5 seconds (2 seconds + time for one ajax request). Since it is using the differential of the status var 'questions' it takes some seconds to display a line.
For the chart I'm currently using Highcharts because it allows realtime data, animates beautifully, is really small (1 file, 77kb minified) and has a export to png/pdf/jpg plugin (6.4kb minified) which however uses a highcharts.com server for the conversion.
Depending on external service is not something I would like to see.
Some radical suggestion in this regard: What about removing the included pChart and instead using a client-side charting library? I know for some part its bad since a student wrote a whole lot of code for it just last year, but looking at some requirements for phpmyadmin (no file storage, limited possibilities for data recording, panning/zooming, realtime updates) a server-side charting library offers much less possibilities compared to a client side-one. And if we'd use highcharts it would save us like 16 files and 750kb (well most of it is that dejavu font). I think it would be pretty easy to replace actually. Instead of the graph, the server-code would just need to send the already generated chart data hidden in the document and then we add a bit of js code to display the chart. Some code from chart.lib.php is probably reusable.
There has been lot of discussion what to use and we stick with sever side solution because it did allow saving of the images (what might be not that useful for server stats, while is definitely useful when drawing chart from query results) and does not require javascript (though this is less and less important nowadays).
However for realtime charts, server side solution will indeed perform worse. And there is also need for some client side graphics library for spatial extensions, so I'd like to see one client side library used for both drawing spatial data and for charting.
Whether it will be possible to replace pChart or not later, that's IMHO different question (mostly depending on usable way of exporting charts out of client side solution).
On Tue, May 31, 2011 at 10:13 AM, Michal Čihař michal@cihar.com wrote:
Hi
Dne Tue, 31 May 2011 00:12:31 +0200 Tyron Madlener tyronx@gmail.com napsal(a):
I've added now a first version of my planned realtime charting on the status page in the 'Query statistics'-Tab (click on "Realtime chart"). You can check it out at http://demo.phpmyadmin.net/gsoc-tyron
Currently it aggregates the average queries per second by making an ajax request every 2-2.5 seconds (2 seconds + time for one ajax request). Since it is using the differential of the status var 'questions' it takes some seconds to display a line.
For the chart I'm currently using Highcharts because it allows realtime data, animates beautifully, is really small (1 file, 77kb minified) and has a export to png/pdf/jpg plugin (6.4kb minified) which however uses a highcharts.com server for the conversion.
Depending on external service is not something I would like to see.
Thats indeed not very nice. Maybe with some hacking around I could build my own svg to png/pdf converter for phpmyadmin. There must be a library for that. The code for converting the charts is availabe from highcharts.com, but from what I've seen its partially written in java. But it cannot be that hard to build our own php-only-solution.
Some radical suggestion in this regard: What about removing the included pChart and instead using a client-side charting library? I know for some part its bad since a student wrote a whole lot of code for it just last year, but looking at some requirements for phpmyadmin (no file storage, limited possibilities for data recording, panning/zooming, realtime updates) a server-side charting library offers much less possibilities compared to a client side-one. And if we'd use highcharts it would save us like 16 files and 750kb (well most of it is that dejavu font). I think it would be pretty easy to replace actually. Instead of the graph, the server-code would just need to send the already generated chart data hidden in the document and then we add a bit of js code to display the chart. Some code from chart.lib.php is probably reusable.
There has been lot of discussion what to use and we stick with sever side solution because it did allow saving of the images (what might be not that useful for server stats, while is definitely useful when drawing chart from query results) and does not require javascript (though this is less and less important nowadays).
Actually the way how pChart is currently implemented it generates the charts in slices, so at the moment you cannot save them.
However for realtime charts, server side solution will indeed perform worse. And there is also need for some client side graphics library for spatial extensions, so I'd like to see one client side library used for both drawing spatial data and for charting.
I basically agree, since adding more and more libraries creates only more feature creep and inconsistency. The reason I'm not very fond of using the suggested svg drawing library (jQuery SVG) is that it has not been specifically built for charting. The plotting examples on the website look rather clumsy and I couldn't find any support for real-time data.
So, if I'm going to build real-time charting for pma using jQuery SVG, I will have to write and maintain some sort of real-time-charting-plugin that likely will consume between a few days and a week of time.
It seems more "future-proof" for me to invest that time in replacing pChart with a client-lib like highcharts and thus still having only 2 graphing libs in pma.
Whether it will be possible to replace pChart or not later, that's IMHO different question (mostly depending on usable way of exporting charts out of client side solution).
pChart is currently used only in 3 different place, no? - server status page - query profiling pie - query result charting
When I was looking at the code, it seemed fairly easy to replace it.
I will do some research on the code of highcharts export, jquery svg and pchart the next days so I can make a more exact estimation of the time it would require to add the missing requirements or replace with another lib in the case of pchart.
As always thanks for all the feedback and more is always welcome :)
-- Michal Čihař | http://cihar.com | http://blog.cihar.com
Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
On Tue, May 31, 2011 at 3:15 PM, Tyron Madlener tyronx@gmail.com wrote:
On Tue, May 31, 2011 at 10:13 AM, Michal Čihař michal@cihar.com wrote:
Hi
Dne Tue, 31 May 2011 00:12:31 +0200 Tyron Madlener tyronx@gmail.com napsal(a):
I've added now a first version of my planned realtime charting on the status page in the 'Query statistics'-Tab (click on "Realtime chart"). You can check it out at http://demo.phpmyadmin.net/gsoc-tyron
Currently it aggregates the average queries per second by making an ajax request every 2-2.5 seconds (2 seconds + time for one ajax request). Since it is using the differential of the status var 'questions' it takes some seconds to display a line.
For the chart I'm currently using Highcharts because it allows realtime data, animates beautifully, is really small (1 file, 77kb minified) and has a export to png/pdf/jpg plugin (6.4kb minified) which however uses a highcharts.com server for the conversion.
Depending on external service is not something I would like to see.
Thats indeed not very nice. Maybe with some hacking around I could build my own svg to png/pdf converter for phpmyadmin. There must be a library for that. The code for converting the charts is availabe from highcharts.com, but from what I've seen its partially written in java. But it cannot be that hard to build our own php-only-solution.
Some radical suggestion in this regard: What about removing the included pChart and instead using a client-side charting library? I know for some part its bad since a student wrote a whole lot of code for it just last year, but looking at some requirements for phpmyadmin (no file storage, limited possibilities for data recording, panning/zooming, realtime updates) a server-side charting library offers much less possibilities compared to a client side-one. And if we'd use highcharts it would save us like 16 files and 750kb (well most of it is that dejavu font). I think it would be pretty easy to replace actually. Instead of the graph, the server-code would just need to send the already generated chart data hidden in the document and then we add a bit of js code to display the chart. Some code from chart.lib.php is probably reusable.
There has been lot of discussion what to use and we stick with sever side solution because it did allow saving of the images (what might be not that useful for server stats, while is definitely useful when drawing chart from query results) and does not require javascript (though this is less and less important nowadays).
Actually the way how pChart is currently implemented it generates the charts in slices, so at the moment you cannot save them.
However for realtime charts, server side solution will indeed perform worse. And there is also need for some client side graphics library for spatial extensions, so I'd like to see one client side library used for both drawing spatial data and for charting.
I basically agree, since adding more and more libraries creates only more feature creep and inconsistency. The reason I'm not very fond of using the suggested svg drawing library (jQuery SVG) is that it has not been specifically built for charting. The plotting examples on the website look rather clumsy and I couldn't find any support for real-time data.
I agree with you on this. The two requirements of the charting and GIS
visualization are bit different. While GIS visualization needs to draw basic shapes such as points, lines and polygons, it will be a waste to use these basic shapes to build chats, though it can be done. It will be much easier to use a charting library where you can simple specify the dataset and get it to draw charts for you.
So, if I'm going to build real-time charting for pma using jQuery SVG,
I will have to write and maintain some sort of real-time-charting-plugin that likely will consume between a few days and a week of time.
It seems more "future-proof" for me to invest that time in replacing pChart with a client-lib like highcharts and thus still having only 2 graphing libs in pma.
Whether it will be possible to replace pChart or not later, that's IMHO different question (mostly depending on usable way of exporting charts out of client side solution).
pChart is currently used only in 3 different place, no?
- server status page
- query profiling pie
- query result charting
When I was looking at the code, it seemed fairly easy to replace it.
I will do some research on the code of highcharts export, jquery svg and pchart the next days so I can make a more exact estimation of the time it would require to add the missing requirements or replace with another lib in the case of pchart.
As always thanks for all the feedback and more is always welcome :)
-- Michal Čihař | http://cihar.com | http://blog.cihar.com
Simplify data backup and recovery for your virtual environment with
vRanger.
Installation's a snap, and flexible recovery options mean your data is
safe,
secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
On Tue, May 31, 2011 at 11:45 AM, Tyron Madlener tyronx@gmail.com wrote:
On Tue, May 31, 2011 at 10:13 AM, Michal Čihař michal@cihar.com wrote:
Hi
Dne Tue, 31 May 2011 00:12:31 +0200 Tyron Madlener tyronx@gmail.com napsal(a):
I've added now a first version of my planned realtime charting on the status page in the 'Query statistics'-Tab (click on "Realtime chart"). You can check it out at http://demo.phpmyadmin.net/gsoc-tyron
Currently it aggregates the average queries per second by making an ajax request every 2-2.5 seconds (2 seconds + time for one ajax request). Since it is using the differential of the status var 'questions' it takes some seconds to display a line.
For the chart I'm currently using Highcharts because it allows realtime data, animates beautifully, is really small (1 file, 77kb minified) and has a export to png/pdf/jpg plugin (6.4kb minified) which however uses a highcharts.com server for the conversion.
Depending on external service is not something I would like to see.
Thats indeed not very nice. Maybe with some hacking around I could build my own svg to png/pdf converter for phpmyadmin. There must be a library for that. The code for converting the charts is availabe from highcharts.com, but from what I've seen its partially written in java. But it cannot be that hard to build our own php-only-solution.
Some radical suggestion in this regard: What about removing the included pChart and instead using a client-side charting library? I know for some part its bad since a student wrote a whole lot of code for it just last year, but looking at some requirements for phpmyadmin (no file storage, limited possibilities for data recording, panning/zooming, realtime updates) a server-side charting library offers much less possibilities compared to a client side-one. And if we'd use highcharts it would save us like 16 files and 750kb (well most of it is that dejavu font). I think it would be pretty easy to replace actually. Instead of the graph, the server-code would just need to send the already generated chart data hidden in the document and then we add a bit of js code to display the chart. Some code from chart.lib.php is probably reusable.
There has been lot of discussion what to use and we stick with sever side solution because it did allow saving of the images (what might be not that useful for server stats, while is definitely useful when drawing chart from query results) and does not require javascript (though this is less and less important nowadays).
Actually the way how pChart is currently implemented it generates the charts in slices, so at the moment you cannot save them.
However for realtime charts, server side solution will indeed perform worse. And there is also need for some client side graphics library for spatial extensions, so I'd like to see one client side library used for both drawing spatial data and for charting.
I basically agree, since adding more and more libraries creates only more feature creep and inconsistency. The reason I'm not very fond of using the suggested svg drawing library (jQuery SVG) is that it has not been specifically built for charting. The plotting examples on the website look rather clumsy and I couldn't find any support for real-time data.
So, if I'm going to build real-time charting for pma using jQuery SVG, I will have to write and maintain some sort of real-time-charting-plugin that likely will consume between a few days and a week of time.
It seems more "future-proof" for me to invest that time in replacing pChart with a client-lib like highcharts and thus still having only 2 graphing libs in pma.
Whether it will be possible to replace pChart or not later, that's IMHO different question (mostly depending on usable way of exporting charts out of client side solution).
pChart is currently used only in 3 different place, no?
- server status page
- query profiling pie
- query result charting
When I was looking at the code, it seemed fairly easy to replace it.
I will do some research on the code of highcharts export, jquery svg and pchart the next days so I can make a more exact estimation of the time it would require to add the missing requirements or replace with another lib in the case of pchart.
After some testing and research I found out that: - The pma_pchart classes, by default, slice the picture into 20 pieces, and that for every browser. It was implemented that way because IE8 limits data URIs to 32kb. - Images generated by pChart are around 20-40 kb in size. - IE7 does not support data URIs (=no pcharts for IE7 at all) - Whereas Highcharts works in IE7 and IE8 (according to the website also in IE6 but I didn't test that)
So from what I can see: - Highcharts works in IE7; pChart does not - Exporting images requires a server side export feature for Highcharts (which is going to be developed anyway for OpenGIS); Exporting in pChart would require either non-sliced images and thus breaking IE8 support or alternatively a server side export feature as well. - Highcharts is fast, interactive and animated, pChart is not (except for tooltips) - Highcharts allows realtime charts, pChart does not - Highcharts requires ~90kb minified and 2 files, pChart with its wrapper classes currently requires ~850kb and 18 files - Highcharts is still being actively developed (last change march 2011), pCharts 1.x is not (last change september 2008)
- If pCharts were to be replaced by Highcharts, it would not require 12 wrapper classes. Rather just 1 that allows for easy extension with $.extend() and is client side. Highcharts is imo significantly easier to use than pCharts, mostly because coding in javascript has some clear advantages over php (OOP-wise). Since charting is used only in 3 places, it should be a matter of a few days to replace it.
- Compared with jQuery SVG: Highcharts is particularly made for charting, thus giving a great look&feel and is very easy to use as a developer; jQuery SVG is not, thus looking inappropriate for charting and will result in less readable and more complicated code (or requires time-intensive coding of wrapper classes/plugins which can maybe partly remedy those disadvantages)
Hence my question, why haven't I been ordered to replace pChart with Highcharts already? ;-)
As always thanks for all the feedback and more is always welcome :)
-- Michal Čihař | http://cihar.com | http://blog.cihar.com
Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today http://p.sf.net/sfu/quest-sfdev2dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Hi
Dne Thu, 2 Jun 2011 13:05:48 +0200 Tyron Madlener tyronx@gmail.com napsal(a):
After some testing and research I found out that:
- The pma_pchart classes, by default, slice the picture into 20
pieces, and that for every browser. It was implemented that way because IE8 limits data URIs to 32kb.
- Images generated by pChart are around 20-40 kb in size.
- IE7 does not support data URIs (=no pcharts for IE7 at all)
- Whereas Highcharts works in IE7 and IE8 (according to the website
also in IE6 but I didn't test that)
So from what I can see:
- Highcharts works in IE7; pChart does not
- Exporting images requires a server side export feature for
Highcharts (which is going to be developed anyway for OpenGIS); Exporting in pChart would require either non-sliced images and thus breaking IE8 support or alternatively a server side export feature as well.
- Highcharts is fast, interactive and animated, pChart is not (except
for tooltips)
- Highcharts allows realtime charts, pChart does not
- Highcharts requires ~90kb minified and 2 files, pChart with its
wrapper classes currently requires ~850kb and 18 files
- Highcharts is still being actively developed (last change march
2011), pCharts 1.x is not (last change september 2008)
- If pCharts were to be replaced by Highcharts, it would not require
12 wrapper classes. Rather just 1 that allows for easy extension with $.extend() and is client side. Highcharts is imo significantly easier to use than pCharts, mostly because coding in javascript has some clear advantages over php (OOP-wise). Since charting is used only in 3 places, it should be a matter of a few days to replace it.
- Compared with jQuery SVG: Highcharts is particularly made for
charting, thus giving a great look&feel and is very easy to use as a developer; jQuery SVG is not, thus looking inappropriate for charting and will result in less readable and more complicated code (or requires time-intensive coding of wrapper classes/plugins which can maybe partly remedy those disadvantages)
Hence my question, why haven't I been ordered to replace pChart with Highcharts already? ;-)
Thanks a lot for great analysis! I think it gives enough reasons to switch from pChart to Highcharts :-).
On Tue, May 31, 2011 at 1:43 PM, Michal Čihař michal@cihar.com wrote:
Hi
Dne Tue, 31 May 2011 00:12:31 +0200 Tyron Madlener tyronx@gmail.com napsal(a):
I've added now a first version of my planned realtime charting on the status page in the 'Query statistics'-Tab (click on "Realtime chart"). You can check it out at http://demo.phpmyadmin.net/gsoc-tyron
Currently it aggregates the average queries per second by making an ajax request every 2-2.5 seconds (2 seconds + time for one ajax request). Since it is using the differential of the status var 'questions' it takes some seconds to display a line.
For the chart I'm currently using Highcharts because it allows realtime data, animates beautifully, is really small (1 file, 77kb minified) and has a export to png/pdf/jpg plugin (6.4kb minified) which however uses a highcharts.com server for the conversion.
Depending on external service is not something I would like to see.
Some radical suggestion in this regard: What about removing the included pChart and instead using a client-side charting library? I know for some part its bad since a student wrote a whole lot of code for it just last year, but looking at some requirements for phpmyadmin (no file storage, limited possibilities for data recording, panning/zooming, realtime updates) a server-side charting library offers much less possibilities compared to a client side-one. And if we'd use highcharts it would save us like 16 files and 750kb (well most of it is that dejavu font). I think it would be pretty easy to replace actually. Instead of the graph, the server-code would just need to send the already generated chart data hidden in the document and then we add a bit of js code to display the chart. Some code from chart.lib.php is probably reusable.
There has been lot of discussion what to use and we stick with sever side solution because it did allow saving of the images (what might be not that useful for server stats, while is definitely useful when drawing chart from query results) and does not require javascript (though this is less and less important nowadays).
Indeed. Since gis visualizations need to be saved I moved on to generate them on the server side. I'm writing the SVG tags accordingly and for the browser that does not support SVG (IE version <9) I am using the GD library to generate PNG images. On the client side I use jQuery SVG for zooming and panning, to give a better user experience. So with this solution, even without the JS support one can view the SVG image, while someone with JS support gets better user experience.
However for realtime charts, server side solution will indeed perform worse. And there is also need for some client side graphics library for spatial extensions, so I'd like to see one client side library used for both drawing spatial data and for charting.
Whether it will be possible to replace pChart or not later, that's IMHO different question (mostly depending on usable way of exporting charts out of client side solution).
-- Michal Čihař | http://cihar.com | http://blog.cihar.com
Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Changes today: - In the tooltip of each point is now displayed what type of queries have been sent to the server. This one took a while, but very interesting to watch. For example you can see that those huge spikes on the demo server are mostly from inserts, probably from when people import their db dumps :D
- I've changed the type of the chart from "Queries per second" into "Queries since last refresh" - this seems more natural to me and removes the rather ugly comma - values.
- Slower refresh (from 2sec+ajax to 5sec+ajax); i want this to be configurable within the page later - Less bugs, better gui
On Tue, May 31, 2011 at 12:12 AM, Tyron Madlener tyronx@gmail.com wrote:
I've added now a first version of my planned realtime charting on the status page in the 'Query statistics'-Tab (click on "Realtime chart"). You can check it out at http://demo.phpmyadmin.net/gsoc-tyron
Currently it aggregates the average queries per second by making an ajax request every 2-2.5 seconds (2 seconds + time for one ajax request). Since it is using the differential of the status var 'questions' it takes some seconds to display a line.
For the chart I'm currently using Highcharts because it allows realtime data, animates beautifully, is really small (1 file, 77kb minified) and has a export to png/pdf/jpg plugin (6.4kb minified) which however uses a highcharts.com server for the conversion.
Some radical suggestion in this regard: What about removing the included pChart and instead using a client-side charting library? I know for some part its bad since a student wrote a whole lot of code for it just last year, but looking at some requirements for phpmyadmin (no file storage, limited possibilities for data recording, panning/zooming, realtime updates) a server-side charting library offers much less possibilities compared to a client side-one. And if we'd use highcharts it would save us like 16 files and 750kb (well most of it is that dejavu font). I think it would be pretty easy to replace actually. Instead of the graph, the server-code would just need to send the already generated chart data hidden in the document and then we add a bit of js code to display the chart. Some code from chart.lib.php is probably reusable.
Please let me know what you think and whether I should continue working in this direction. Thanks! :)
-
Herman van Rink -
Madhura Jayaratne -
Michal Čihař -
Tyron Madlener