[@dxli and @sand1024] mslide action need help making img

emanuel wrote

2) Creating images and slides from the drawing:
Error: "ByLayer" and "black/white" are not rendered.

Not rendered - where? On screen on print or..?

Btw, could you try to export the same drawing to the image(SVG or png) - and check how such entities are rendered?

emanuel wrote

3) Overwriting and reopening slides still shows me a copy of the first slide on the screen.

Most probably, there is some logic error in your lc_actionfileviewslide.cpp code that requires debugging.  
Did you try to do interactive debugging of that action?

I see just several points that are suspicious:
1) Not sure what will be happen with your slide on resume()/suspend() - there might be some cleanup of containers and states performed. Plus, if there is a switch to another action - it may clean overlay container too.
2) the init(), in general, may be called more than one time

I suppose the simplest way will be just to follow the implementation that I've proposed you to consider earlier. It's not an issue to redraw the slide as many time as requested, considering that parsing and rile reading is performed only once.

P.S

Yet again, in general I still do not understand the purpose of this action, sorry. According to it's implementation, the action asks for the file, displays the slide and then it may be finished. That's it?

 As far as I understand, you'd like to support displaying slides - yet why it's necessary to follow stone-ages technology from AutoCAD that was necessary to support weak computers?  For supporting slide/mslide commands - it's possible just to perform the rendering of the viewport.

Thus for the user who executes the script - it will be the same commands, so they are backward compatible. Yet the implementation of commands could be different - and for me it's quite fine to rely on the renderer itself rather than on displaying slides.

@sand1024

 I found the strange memory effect and fixed it:
https://github.com/emanuel4you/LibreCAD/commit/e25dc47f5e6c82f462a232c651e0eb1806869617

@sand1024

Not rendered - where? On screen, on print, or...?
>> Can I display an image on the LC Screen?
By the way, could you try exporting the same drawing to the image (SVG or PNG) - and check how such entities are rendered?
>> Result:
SVG without colors but with "ByLayer" and "Black/White"
PNG without "ByLayer" and "Black/White"
bla.dxf
bla.svg
bla.png

other thing 'Ive found:

If I click on don't save changes when exiting LibreCAD, it is ignored since the last major patch.
Only on new files, not when opening a file.

emanuel wrote

>> Result:
SVG without colors but with "ByLayer" and "Black/White"
PNG without "ByLayer" and "Black/White"

Oh, great, thank you - I'll take a look.

emanuel wrote

other thing 'Ive found:

If I click on don't save changes when exiting LibreCAD, it is ignored since the last major patch.
Only on new files, not when opening a file.

Hm.. not sure I got this.

If "Don't save" selected in the dialog - changes should be ignored indeed. If Cancel - will break the process of saving. For Save - saves changes and continue closing process.

Or did I miss something?  

No, it's not relevant to RS_Pen settings.

I triaged with "Spline through Points":

case 1. without my change 6a138269, the spline is generated by not redrawn properly, and invisible;
case 2. With my change the spline is redrawn and visible.

I printed out the RS_Pen for both cases, RS_Pen stays the same in both case.

I added a break point in LC_SplinePoints::draw():

case 1. the method is not called for the generated spline;
case 2. the method is called for the generated spline.

I agree, this is an issue of the renderer.

sand1024 wrote

@dxli

I really suspect that this is related to adding impl class that contains pen to the RS_Entity.

    struct Impl;
    const std::unique_ptr<Impl> m_pImpl;

Actually - this issue https://github.com/LibreCAD/LibreCAD/issues/2098

As pen instance was not copied in that change - I've also seen interesting effects, where changing layer's pen leads to changing of the pen of entity.

However, I supposed I've fixed this in my last PR...

in more general sense - I'm not sure that original historical setPenToActive() is a good design (actually it's a bad one).

It adds lots of over-coupling dependencies between entity, graphics, layer and layer list.. so in the future, it's reasonable to remove that method from the entity and move to the code that creates entity (like RS_Creation, actions or so).

@emanuel

my troubleshooting pinpointed the issue to "calculateBorders()".

It appears to be invalid cached entity bounding boxes. Incorrect bounding box caused the ree nderer to skip entity drawing. A quick fix is to call the entity's calculateBorders() method.

A code review is needed to ensure the calculateBorders() methods are called automatically. Simiar to what I did for RS_Arc:

https://github.com/LibreCAD/LibreCAD/commit/522ec60a8b14bb201cd84b3d4f2165bec8302f76

I'm not sure whether it helps at your side.

emanuel wrote

@dxli: I think the error lies in the RS_Render.
simplescreenrecorder-2025-04-20_23.mp4
Please watch the video and test the attached file. The X is one line "byLayer" and the other "White/Black."
bla.dxf

@dxli

Well, you right that there is an issue with borders.  However, the source of the problem is in different place.

To be more precisely - there is a generic major issue with clipping of entities, and most probably that's the reason of the issue discussed there (it's easy to check - move line in question (that is not drawn) to the center of the screen. Most probably it will be visible on export).

Invalid clipping is mostly visible when UCS contains rotation angle, yet might be also discovered with ordinary WCS too (in areas that are close to bounds of the viewport).

The reason for clipping issue is the broken logic of clip rect related functions during the "coding style" optimization.

I've mentioned that issue previously, when we've discussed translations of coordinates.

Please take a look to my comments there: https://github.com/LibreCAD/LibreCAD/commit/cc6437f589adcdb9c8e8b4c0d5986d0646e067d9#r153917209

I've also provided a video for clipping issue.

So this is actually the root of the problem, the calculateBorders() iifself works fine in all places where it's needed.

Of course, I could fix restore to previous implementation (the working one). However, as you consider that more optimal/easier to read implementation is needed there - I've supposed that it will be up to you to fix  the implementation of LC_CoordinatesMapper:ucsBoundingBox() and worldBoundingBox()

So far the error in calculation of the clipping bound rect (in WCS coordinates) leads to returning the rect that is smaller than it is necessary (and so more aggressive clipping).

@dxli
No, the case with borders in arc is different - it occurred since previously endpoint of arc was calculated in getter, and that was switched to returning just a cached endpoint value.

sand1024 wrote

Hm.. not sure I got this.

If "Don't save" selected in the dialog - changes should be ignored indeed. If Cancel - will break the process of saving. For Save - saves changes and continue closing process.

Or did I miss something?  

see the video:
simplescreenrecorder-2025-04-24_17.mp4