Repository navigation
outstanding issues from jpl #4897
Description
In evaluating the most recent matplotlib code, @TD22057, myself, and others on our team have come across several issues. Some are bugs and some are performance issues that make interactive usability difficult. I am opening this issue to list them all at once. This way when I submit my pull requests with the fixes, I can just reference this issue. I am also listing them all here to give you a heads up to the issues we found and that there are fixes coming.
The issues are as follows:
- BarHCollection is very slow
- stale artists do not handle being removed from axes properly
- position of text annotations looses unit information
- polar plots do not properly handle units polar plots do not properly handle units #4905
- broken_barh does not properly support units
- figure option dialog does not properly handle units
- generating fontconfig strings from mpl FontProperties is broken generating fontconfig strings from mpl FontProperties is broken #4910
- Super short lines with arrows do not act well
- qt imports do not pick defaults properly
- animation blitting is no longer working
- mouse movement is very slow
- Agg restore_region is broken
- qt backend default bbox not set when blitting
- qt backend draw_idle doesn't work
- qt backend has more draws than necessary
- text update properties does not handle bbox properly
- bar plot fails with no tick labels
I already have fixes for almost all of these and will be submitting them in the next day or so (with more details about each one).
Edited to add a missing issue I forgot the first time.
Activity
tacaswell commentedon Aug 11, 2015
yikes.
I believe there is already a PR open addressing the short arrows.
What were you doing that you hit all of these and how many are regressions and how many never worked?
tacaswell commentedon Aug 11, 2015
What commit are you evaluating off of?
Is the mouse movement slow with all backends or just qt5? If it is just qt5 a possible fix ( #4894 ) went in for that this morning and #4612 may have reduced the number of draws.
I think #4738 has a fix for the animation blitting issue.
TD22057 commentedon Aug 11, 2015
FYI We have a fairly complicated Qt GUI that plots data in large batches (50,000+ points) as well as updates in real time as data is read over a network. Data can be in a variety of units and the user can lasso and interact w/ points (blitting issues). We recently updated the app to use PyQt5 and were retesting all of it's features to make sure things were working. So it's hard to tell exactly when things failed - there may be items that were broken but no one was using and we wouldn't know about it. I think there are probably two major groups of problems. The Qt backend (as well as the mouse move bug in qt itself) seem to be reworked recently and GUI's are difficult to test. The unit support has been an issue in the past as (newer?) people change things and don't realize that unit'ized data is possible so it's not tested (@jrevans tends to fix those as soon as we find them). I believe @jrevans is going to start submitting fixes for a lot these items tomorrow.
tacaswell commentedon Aug 11, 2015
Ah, you are probably also interest in #4813 and #4878 which work extra hard to highlight the qt5 mouse handling change.
tacaswell commentedon Aug 11, 2015
I am mostly concerned about the stale-related issues as that is a new feature which could have fatal flaws. Regressions and GUI issues, while bad, worry me less (as I have more faith they are fixable).
tacaswell commentedon Aug 14, 2015
It would be really helpful if someone who understands the unit handling
could write a unit tutorial and integrate the unit example code that is
already in the library into the automated tests.
On Mon, Aug 10, 2015, 9:36 PM Ted Drain notifications@github.com wrote:
TD22057 commentedon Aug 14, 2015
@tacaswell I think there are already tests with units - the issue is that they need to cover the whole plot API which is a big job. We can certainly help write expand them (more tests are always better of course) but it's going to take some time.
OceanWolf commentedon Aug 14, 2015
How much difference would exist between the tests? Could we for instance write a "one test to test them all", searching through the plot API, and running a test on each of them?
I have just ticked off the items already merged in the opening comment.
TD22057 commentedon Aug 14, 2015
Ideally, we'd test every plot command, axis manipulations (limits, etc), and the various artists. They all have different API's so you can't write one test. We might be able to refactor existing tests to have a "generate data" function were we can replace that function with regular data and unitized data before the main part of the test runs.
tacaswell commentedon Aug 14, 2015
If there are tests, I am not sure where they are and they are not listed in https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/__init__.py#L1403 so they are not getting run on travis. The examples are being run (due to being part of the docs http://matplotlib.org/devdocs/examples/units/index.html) but it only checks that they run with out exceptions, not that they are correct.
There is code in
https://github.com/matplotlib/matplotlib/tree/master/lib/matplotlib/testing/jpl_units that is used a couple of places in
test_axes.If I understand correctly, the datetime handling is done through the unit framework, but some of the issues reported it is not clear how to map date-time to them.
OceanWolf commentedon Aug 14, 2015
@TD22057 Damn, I had a bad feeling you were going to say that... ;).
From what I have seen of the code (and I slowly work my way through the code base), that it looks like the emphasis has been on quick fixes, rather then working on the underlying flaws. The good news though, I have a feeling that a lot of this will get addressed in 2.x though. From MEP22 and 27 dealing with the backend widgets, through to refactoring the Artists, including the Axes, which I have a suspicion will get made more generic so it can better handle Axes3d, etcetera.
tacaswell commentedon Aug 17, 2015
I ticked off 3 (mouse movement, animation blitting, and stale + remove) that I think are fixed, can you verify?
Can you be any more specific about what is wrong with qt and if it applies to both qt4 and qt5?
jrevans commentedon Aug 17, 2015
I have verified that 'mouse movement is very slow' issue that we were seeing is a result of three things:
tacaswell commentedon Aug 17, 2015
the mouse-over logic is currently optional on a per-artist basis and the only artist that implements anything is
AxesImage.2 and 3 should both be fixed on current master and we can't do anything about 1.
12 remaining items
tacaswell commentedon Jan 1, 2016
Moved to next bug-fix release target.
[-]Potential issues for 1.5 release[/-][+]outstanding issues from jpl[/+]github-actions commentedon Jan 1, 2024
This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!