Dimensions

When doing dimensions I only get a box above the dim line.
I have read many posts on this forum on this issue.  However, none of the fixes work.
I recently downloaded LibreCAD.  I am using  version 2.2.0.2
I am NOT in Draft mode!
I saved my drawing then closed the program.  I reopened the program and my drawing.  
The dimensions were magically shown above the dim lines.  
I can Zoom In/Out/Previous/Auto/Window and the dimension numbers continue to be shown.
However, when I Zoom/Pan, all the dimensions turn into boxes again.
Help Please.  

I have no answer why you get just a box when doing a dimension line.
But after Zoom/Pan hit Escape or click right mouse button to finish the command and the dimension numbers will return.

Thanks for the timely reply.
Unfortunately, hitting the ESC after panning doesn't restore the dimensions.  Still have empty boxes above the dim lines
PS - I am not using a mouse, just the finger pad on my laptop.

actually, there is a small optimization for text/mtext drawing - during panning, a rect is drawn instead of text (even in non-draft mode).

Dimension contains text, so that logic affects text too.

However, it's really strange that after completing pan the text is not redrawn properly (btw, try hit F5 for force redraw?)

Also, instead of using 2.2.0.2, you can try to use fresher version, even dev snapshots are quite stable (like https://github.com/LibreCAD/LibreCAD/releases/tag/2.2.2_alpha-latest)

sand1024 wrote

actually, there is a small optimization for text/mtext drawing - during panning, a rect is drawn instead of text (even in non-draft mode).

Can I switch this "optimization" off? By some option (didn't found in the options) or by some compilation options? Or even source patching?

Hi sand1024,

We should do a profiling on text/mtext performance.

If we can achieve linear complexity, those optimization can be turned off.

I am also thinking about making draft mode a setting per session, meaning any switching to draft mode will not be remembered, after LibreCAD is restarted, draft mode will be off by default.

sand1024 wrote

actually, there is a small optimization for text/mtext drawing - during panning, a rect is drawn instead of text (even in non-draft mode).

Dimension contains text, so that logic affects text too.

However, it's really strange that after completing pan the text is not redrawn properly (btw, try hit F5 for force redraw?)

Also, instead of using 2.2.0.2, you can try to use fresher version, even dev snapshots are quite stable (like https://github.com/LibreCAD/LibreCAD/releases/tag/2.2.2_alpha-latest)

Hi, dxli. Can you point me to the place of the source, where is the zoom/pan code (and the special rendering during the pan)?

I want to try to make some improvements of the logic and to experiment with the performance.

Thanks.

well, at the moment there is no setting that controls this.

However the code is quite straightforward - you can check  RS_Text::draw function (and same for RS_MText).

There is the following logic that performs drawing of simplified text:

  if (!view->isPrintPreview() && !view->isPrinting()){
        if (view->isPanning() || view->toGuiDY(getHeight()) < view->getMinRenderableTextHeightInPx()){
            drawDraft(painter, view, patternOffset);
            return;
        }
    }
......

As you can see, simplified text is drawn if

1) the height of the text is smaller than specified height of text in pixels (defined in Application Preferences)
or
2) if view is panning.

Thanks! I will play a little with this code.

Also, I need a little more help in code navigation:

I want to implement the "pan on zoom" feature - when you zoom-in with the mouse wheel, the point that is under the mouse cursor moves to the center of the drawing together with the mouse cursor. (and also, there is even better variant - on the first scroll, it only pan, and then zoom).

So, where I can read the code that makes the zoom with the mouse wheel and the code that pans with the middle button? Some combination of both should make the task.

Hi dxli,
>If we can achieve linear complexity, those optimization can be turned off.

Well, honestly, I don't think it will be possible to render texts faster without complete re-writing internal fonts implementation, text/mtext entities and rendering.  

I've already tried to speedup working/rendering texts in all places where it was possible without complete rewrite - as part of the overall rendering speed improving and yes, I've measured performance of rendering there.  

However, internally there is, well, quite a straightforward implementation of fonts that involves creation of quite a significant amount of entities internally (like lines, inserts for letters, polylines individual lines/arcs that are parts of polylines) - and direct rendering of them. So there is not such things like glyphs or so - and basically most of calculations are performed again and again (even for the same letter).  

Also, for example, previously, there was a huge performance loss on rendering in setup of painter for all that text/related stuff - for each individual entity (within letter!) individually. Now I've fixed that so if works faster, added caching calculation results where possible - yet still, the functionality for rendering texts is too far from ideal, as for me.

well, I'm not sure it will be more convenient than current implementation of zoom - yet probably I can't imagine well how it may work.

You can take look rs_graphicview.cpp - and there are a set of functions related to zoom and scroll.
Plus, the starting point may be void QG_GraphicView::wheelEvent(QWheelEvent *e).

However, please note that there are lots of code related to zoom/pan, so quite a careful testing is needed if something is modified in that area - just to ensure that no unexpected side-effects or issues were introduced.  And it might be that it may be harder to implement such feature than it might be expected initially.

Thanks for the help. Very useful!

sand1024 wrote

well, I'm not sure it will be more convenient than current implementation of zoom - yet probably I can't imagine well how it may work.

This behavior is pretty common approach in the electronics CAD systems, like, for example, KiCAD, but not only.

The second variant (first pan, then zoom) is actually more exotic, but this way works the amazing (sad, only for windows) FreePCB.