Topics

Version 5.2.0GA, Zoom out causes abrupt close #V5dot2dot1


Russell Shilling
 

Version 5.2.0GA, Windows 10

If I open this plan and immediately zoom out with the mouse wheel, the program abruptly closes with no message.

--
Russell Shilling
http://shilling-or.com


Adam Richards
 

OK - works fine on Mac - so is most likely Windows platform specific. 

If you use Ctrl+"-" repeatedly to zoom out, does the same thing happen? 

And are you using a trackpad or some other way to simulate a mouse wheel, or a real mouse wheel? 

Adam


Joost van der Waa
 

Tried this on Windows 10 and 5.2.0GA with your layout, but no problem at all.


Dave Bullis
 

5.2.0GA on Win10 - no problem
But no mouse wheel.

What was the initial zoom when you started the program?

Dave


Russell Shilling
 

Rats. I thought I had a reproducible event, but I can't make it happen again, either. I should have saved and posted the xtrkcad.ini file. I've had several times where XTC will just close unexpectedly, but I didn't know how to make it happen on command so it could be diagnosed. 
--
Russell Shilling
http://shilling-or.com


Adam Richards
 

So the question is - what sort of operation(s) were you doing just before it happened because that may focus on a likely area? 

Known GA issues that have cause abends and have fixes - 

  1. Flipping Bezier Lines
  2. Joining Tracks that are Cornus or Beziers with easement not set to Cornu. 
  3. Ungrouping Structures

Areas of code probably more likely to have issues because they have newer code - 
- Adding a more exotic type (like a Bezier or a Cornu or a Flex Track)
- Modifying a more exotic type
- Parallel Lines to Track
- Joining Lines
- Using the Parm Library 
- Protractor
- Joining with the desired radius set
- Grouping and Ungrouping (new path logic)

Adam


Russell Shilling
 

The abrupt close seems to happen when I'm zooming in (mostly) or out. Several times I wasn't doing any modification - just scrolling and zooming. I experimented today, the program (reliably) closes when I zoom in about the time I reach the tie drawing magnification. Then I removed the background image, and no abrupt close. 
--
Russell Shilling
http://shilling-or.com


Adam Richards
 

OK - a lot to unpack. 

1. You apparently have a background. This is not in the .xtc file you attached - it would (hopefully) be packaged up in an archive format. (Save As..->SaveFormat->Extended TrackPlan (.xtce)).  So that could be an issue if that is in someway breaking on Windows that we wouldn't have tested. 
2. The Ties we obviously would have seen them - did you override the tie values via config file entries, perhaps? 

Adam

 


Russell Shilling
 

1. XTCE file attached. Is that a zip format archive? (Nice feature.)
2. I did override the tie size and spacing. Once I removed the background everything works well, including tie drawing, zooming with the mouse wheel, etc. I worked on the track plan for a couple of hours today without an abrupt closing. 
--
Russell Shilling
http://shilling-or.com


Dave Bullis
 

I see 2 things.

When I zoom in to 1:4 I see xtrkcad's memory spike to over a Gb with a lot of disk noise.  Then it settles down to around 4Mb.
I'm quessing somebody is rendering the whole bitmap at the new resolution, picking the part that maps onto the screen and throws the rest aways.
I don't know if that's Windows fault or ours.

At down to 7:1 all is well, 6:1 and 5:1 no errors but no background either (some other bug?)
Then at 4:1, I hit an uninitialized variable exception at backgnd.c:206 in wDrawBackground on 'rotated'
FreeImage_RescaleRect is failing (it returns 0) which causes image_type to be 0, which is not a case in the proceeding switch so rotated is not set -> boom

The fix is to bail if FreeImage_RescaleRect fails

Checked in fix for next release.

Dave


Russell Shilling
 

The code is rescaling the whole image and possibly rotating it as well before extracting the rectangle of interest. The solution would be to work backward from the destination rectangle to get the source rectangle before scaling, but with rotation in the mix that would get pretty ugly. Unless background rotations were constrained to multiples of 90 degrees.
--
Russell Shilling
http://shilling-or.com


Dave Bullis
 

We scale scale/rotate/translate in many places.  
Check out utility.c


Adam Richards
 

The simplest change would be to first screen and then rotate before scaling up or the other way around (screen first will be slightly quicker).  That is the order cairo does it in on GTK (cairo processes transforms backwards wrt to the order they are coded). That way we get only one copy of the full scaled image to the select parts from. We could also reuse that large image if the scale and rotation is not changed. I'm not sure why the rotate is failing to produce output, but one reason the manual gives is that the memory allocation fails. At the moment we have two large copies of the scaled up image in memory during the process (and the rotate is done second)...  

Because the translated background origin on all platforms is of the post-scaled, post-rotated image rectangle the bottom left the background content is invariant at the same zoom.  So we could also store the scale and rotate angle and only recalculate bd->background if either changes (pans would be cheap, in other words). 

To go further, we could do the work to find the de-scaled window in the rotated image space and only scale that portion of the image, but that means we have to recalculate on every pan as well as zoom, trading CPU for memory. 

Adam
 


Dave Bullis
 

FreeImage_RescaleRect is failing likely because of allocation failure.
The full bitmap at 1:1 would be around 840*1200*72*72 = 5G pixels.
and I'm failing at 4:1 or about 5G/16 pixels
In any case GTK has no problem so it would be a good model
Or wait for GTK3

Dave


Adam Richards
 

Gtk is usually 64bit, of course, but even so, halving the space used by scaling last would be a good start.

Next would be only scaling the area needed which would only use the size of a full screen bitmap.

Adam

On Sun, Nov 29, 2020 at 8:59 AM, Dave Bullis <sillub@...> wrote:
FreeImage_RescaleRect is failing likely because of allocation failure.
The full bitmap at 1:1 would be around 840*1200*72*72 = 5G pixels.
and I'm failing at 4:1 or about 5G/16 pixels
In any case GTK has no problem so it would be a good model
Or wait for GTK3

Dave

--
Adam Richards