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

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

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

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