Sound didn't record, but you can see the issues:
(1) As a graph grows, the location of legends is distorted (and then lost)
(2) Reseting the simulation doesn't reset the graph.
I wasn't able to reproduce (1) on either Linux or Windows 10 running in a VM. Could you check to see if the issue persists on all the different hardware types you have?
(2) There appears to be a message not getting through to the Tk canvas to update the plot icon when the reset button is pressed. It should be simple to fix.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I wasn't able to reproduce (1) on either Linux or Windows 10 running in a
VM. Could you check to see if the issue persists on all the different
hardware types you have?
(2) There appears to be a message not getting through to the Tk canvas to
update the plot icon when the reset button is pressed. It should be simple
to fix.
Status: open Milestone: Cantillon Created: Wed Oct 21, 2015 05:23 PM UTC by Steve Keen Last Updated: Wed Oct 21, 2015 05:24 PM UTC Owner: nobody Attachments:
Sound didn't record, but you can see the issues:
(1) As a graph grows, the location of legends is distorted (and then lost)
(2) Reseting the simulation doesn't reset the graph.
--
Best, Steve
Professor Steve Keen
Head, School of Economics, Politics & History,
Kingston University London
www.debtdeflation.com/blogs
www.ideaeconomics.org
@ProfSteveKeen
Ph (W) +44 (0)20 8417-2306
I was able to reproduce the issue by rebooting my computer into Windows 7. But neither Windows XP, nor Windows 10, running as virtual machines have this problem.
It looks like a possible bug with Pango, but it could even be a bug with Windows 7.
I'll try a test using Hal's laptop, which is still running Windows 8.1 for another data point.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Weirder and weirder. The bug also manifests in Windows 7 on a VM. I could also check Windows 8/8.1 on a VM, but I don't see the point.
At this stage it looks like it is an implementation bug on Windows 7 and Windows 8, but not XP or Windows 10. It is possible it is not with Windows, but with either the Cairo or Pango, but it looks strongly like it is a Windows bug^H^H^Hfeature. The concern is that Windows 7 is still 50% of the market share. Windows 10 doesn't even show up in my figures, but according to Microsoft's (probably inflated) figures it is no more than 8%.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've finally got a solution. Placement of graphical items in the plot is in terms of "user space", which are the floating point numbers of the data to be plotted. Obviously, as the data values increasde towards infinity, user space values also increase. It appears that on the offending OSes, the conversion of user space to device space has problems when user space values get too big. Perhaps 64 bit integers are used for user space, rather than floating point values like you'd expect. Anyway, I ended up changing the calculation for plotting things like labels to be done in device space, and that appears to have solved the problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have fixed this for axis labels and legends (sort of), but there is still an issue with axis tick labels. This is an ecolab problem, so I have raised a ticket there to handle the issue.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The MKY file
I wasn't able to reproduce (1) on either Linux or Windows 10 running in a VM. Could you check to see if the issue persists on all the different hardware types you have?
(2) There appears to be a message not getting through to the Tk canvas to update the plot icon when the reset button is pressed. It should be simple to fix.
Will do. I have 3 PCs--all high res however. I'll see if I can use a
friend's with lower res.
On Sunday, 1 November 2015, High Performance Coder hpcoder@users.sf.net
wrote:
--
Best, Steve
Professor Steve Keen
Head, School of Economics, Politics & History,
Kingston University London
www.debtdeflation.com/blogs
www.ideaeconomics.org
@ProfSteveKeen
Ph (W) +44 (0)20 8417-2306
Related
Bugs:
#518Added a redraw call to all items that change their visible properties according to internal state with updateCanvas.
Still clarifying if there's a display resolution issue here.
I was able to reproduce the issue by rebooting my computer into Windows 7. But neither Windows XP, nor Windows 10, running as virtual machines have this problem.
It looks like a possible bug with Pango, but it could even be a bug with Windows 7.
I'll try a test using Hal's laptop, which is still running Windows 8.1 for another data point.
Same problem on Windows 8.1 on Hal's laptop. The laptop is not high resolution AFAICT.
Will need to download and install a test copy of Windows 7 on a VM to see if it only occurs on real machines, not virtual ones.
Weirder and weirder. The bug also manifests in Windows 7 on a VM. I could also check Windows 8/8.1 on a VM, but I don't see the point.
At this stage it looks like it is an implementation bug on Windows 7 and Windows 8, but not XP or Windows 10. It is possible it is not with Windows, but with either the Cairo or Pango, but it looks strongly like it is a Windows bug^H^H^Hfeature. The concern is that Windows 7 is still 50% of the market share. Windows 10 doesn't even show up in my figures, but according to Microsoft's (probably inflated) figures it is no more than 8%.
I've finally got a solution. Placement of graphical items in the plot is in terms of "user space", which are the floating point numbers of the data to be plotted. Obviously, as the data values increasde towards infinity, user space values also increase. It appears that on the offending OSes, the conversion of user space to device space has problems when user space values get too big. Perhaps 64 bit integers are used for user space, rather than floating point values like you'd expect. Anyway, I ended up changing the calculation for plotting things like labels to be done in device space, and that appears to have solved the problem.
I have fixed this for axis labels and legends (sort of), but there is still an issue with axis tick labels. This is an ecolab problem, so I have raised a ticket there to handle the issue.
https://sourceforge.net/p/ecolab/bugs/153/