I will try to experiment more tomorrow and maybe find out what legit feature I have misconfigured (several other apparent new bugs so far were just features that confused me).
But so far as I can tell, this is a new bug.
I zoom in and my text and lines remain visible, while polylines (created with the rectangle tool) vanish. They reappear again when I zoom out.
Edit: The objects vanish when the origin (the 0,0) point is zoomed or scrolled off of the screen. But it doesn’t happen in a simpler document and I haven’t yet found the relevant difference.
Edit2: This only happens when I use 2.2.2 to work on dxf files originally created in 2.2.1, and not even all of those. Still trying to narrow it down, but it is very frustrating, because it ruins every file I care about.
I can’t adjust things correctly without snap to grid, but in either 2.2.1 or 2.2.2 it snaps to the wrong grid when zoomed out (another “feature” I’d like to know how to correct) but in the later isn’t visible at all whn zoomed in.
@jsf67
Please report issues on GitHub. Also, for similar issues, it’s very helpful if you could just attach zipped dxf where the issue may be reproduced, as in many cases they significantly depends on the data in the drawing.
In general, 2.2.2-alpha is under active development, so it is not as stable as 2.2.1 branch.
I will search for or recreate the GitHub login I misplaced years ago. But I haven’t yet.
Meanwhile, this forum won’t let me upload a .zip file.
I have a file (that I can’t easily reproduce) with one rectangle with serious problems in it and no other visible objects. I created it by deleting everything but that one rectangle from one of the files I’m trying to do real work on.
What creates bad rectangles, I don’t know. Maybe a bug in 2.2.1 that has since been fixed. Maybe a back incompatibility issue: create in 2.2.1, edit in 2.2.2 on Fedora, edit more in 2.2.1 on Windows where I haven’t built 2.2.2, reopen in 2.2.2
Whatever created them, they are all or almost all of the many rectangles in my working files. I’m trying to find out what is wrong with them, that makes them displayable (so long as the origin is in the window) and they can be modified and copied etc. (remaining bad) in many other ways.
I’m trying to first figure out what is wrong with them and then add code to fix them. No information has been lost, so they can be fixed. I just don’t yet understand that source code well enough yet.
Based on a lot of symptoms, I’m guessing getMin() and getMax() are giving incorrect answers, maybe reversed. But I haven’t figured out how that can happen in an object that can be drawn correctly some of the time.
I set a grid of 2 inches. I want to snap to that 2 inch grid no matter how much I’m zoomed in or out.
If zoomed way in, the program displays that 2 inch grid and a 12 inch meta grid (I can change other setings to have the default 20 inch meta grid, which is inferior for my use and have no affect on the issue I’m describing here).
If I zoom out just a little, it changes to displaying a 4 inch grid (keeping the 12 inch meta grid). That display change is fine, because otherwise the grid would be too dense. BUT it shouldn’t change what I snap to. I need to snap to the grid I specified. If I want to snap to a different grid, I want to specify that grid, not have the program invent it.
This misfeature interacts with the rectangle bug, because the rectangle bug hides the content I want to change when I zoom in, while this misfeature prevents the edits I want to make unless zoomed in.
But meanwhile, a related bug in 2.2.2 is easily reproducible:
Start with an empty document.
Create two layers.
Create one rectangle on layer 1.
Modify attributes to switch that rectangle to layer 2.
Turn off visibility of layer 1, so only layer 2 is visible.
Scroll the origin point in and out of the window and observe that that rectangle is visible when the origin is also visible, but vanishes when the origin is out of the window.
What is the correct meaning of changing the layer of a rectangle?
I expect it should mean that the polyline AND the four lines that it is made of all switch to that new layer. If that is the intended behavior, then the fact that the polyline moves without taking its components with it is the bug.
If it were somehow intended that a polyline be on a different layer from its parts (as I think is true for a block), then there are bugs all over the place in failing to correctly handle a polyline that is on a different layer from its parts.
BTW, I still have no clue why the position of the origin matters in the manifestation of this bug and of the bug I was trying to diagnose on when I realized this bug exists and is related and simpler.
oh, I see. So basically, if I’m correct you’d like to snap to specific fixed grid, right?
By default, snapping is performed to the actual grid and the grid is automatically scaled with zoom level.
However, you may fix the grid - as well as specify non-rectangular one (sometimes it’s quite convenient feature).
Try to uncheck “Automatically scale grid” checkbox in Application Preferences. In such case - the grid should be fixed and you will be able to desired points.
The drawback of such approach - on redraw and changing zoom level - the grid will not scale.
So far, there are no separated “snap grid” and “draw grid”. From technical point of view - it could be implemented, but I suppose it could be quite confusing for the user to snap to invisible grid that could be different from visual one.
I certainly have tried that and it does not do what you say it does. I’m a bit unclear on what it does do, but anyway it doesn’t (and I think shouldn’t) do what you just said.
BTW, it has become confusing that the discussion of the grid feature I might like is in the same thread as the description from the bug in polyline behavior. (They were related in joining together to defeat my use when neither alone would have defeated me. But they are actually unrelated).
Should it correctly render a polyline that is on a different layer from its parts? What would “correctly” mean? Was that ever correct?
I still lean toward the theory that a polyline should always drag its parts with it. The bug is that the program ever changed the layer of a polyline without changing the layer of its parts. If that is a bug, then the fact that it is long standing just means the dxf reader should correct input that is wrong in that regard (I can’t find the right place in the code to make that easy change).
Yes, it appears that the bug filled behavior when the layer doesn’t match has dramatically changed (and for the worse). But chasing through the code, I saw so many places it would subtly break due to that layer mismatching that I don’t think supporting the mismatch was intended.
Or maybe you meant the fact that whether the origin is in view matters. On top of the bug (that I wouldn’t call a rendering bug) that the layers mismatch, there might well be a semi-related bug (maybe the one I still haven’t tracked down) that the visibility of the origin matters.
oh, It seems that I’ve forgot to mention a couple of thing:
In Drawing Preferences, it’s necessary to specify the grid size for current drawing (on Grid Tab)
As per you comment - depending on zoom, fixed (not scaled) grid could be too dense - if cell size is less than minimal grid cell size, it will not be drawn. Or grid cell may be larger than viewport.
So for the fixed grid - it might be that the grid is not visible on the screen.
Other that that - I’ve just quickly check fixed not scaled grid with imperial and metric units - it seems it works as expected.
I have only tested this with inches and with “engineering” (which changes the way the inch grid behaves). I doubt it is different in metric, but I don’t know.
I always set the grid size for the current drawing (on the grid tab of current drawing preferences).
I wonder what it is that you tested or what you mean by “as expected”.
Zoom out so far that the “fixed” grid cannot be displayed. It displays a different grid and snaps to what it displays (despite the grid being supposedly fixed).
Use the new feature that lets you turn off the display of the grid and still snap to it (thanks for that new feature) and it still snaps (when zoomed out) to the modified grid that doesn’t need to exist at all since it isn’t displayed and it doesn’t matter that the fixed grid is too dense to display.
In case anyone else cares, the fix is that the children of a polyline are forced to be on the same layer as the polyline (as opposed to the less plausible idea I asked about of having meaningful support for having children of a polyline on a different layer)