Poor performance under Linux

[iGreybear]

Fidocad under linux (tested from fedora 2x to fedora 30) is very slow when the magnification is not rounded to the tens. For example, a 237% magnification greatly slows fidocad execution. To solve it I need to put manually a magnification of 230% or 240%. This happens when I "fit" the design to the page.
It's possible to round automatically to the tens?

Many thanks

[DarwinNE]

Hi and thank you for observing that.
I am wandering what causes the behaviour. In theory, calculations should not be different for 237% and 240%.
If you have a drawing and you manually put 237% (hence, not with "zoom to fit"), is the redraw noticeably slower than 240%?
Cheers,
D.

[iGreybear]

Yes, it's the same.

[DarwinNE]

That's intriguing, however, all calculations are done with double precision floats. I don't see why 237% would be different from 240%. Is there any difference that appears, apart that the redraw is much slower?

[iGreybear]

Hi DarwinNE,
no other problems are visible to me. It probably doesn't depend on your software. I would suggest solving the problem by adding a "round to tens / not round" item in the "Options" menu.

[DarwinNE]

Is there a possibility to trace the origin of the issue? For example, is this linked to a certain version of the JRE or to the graphics driver? I think that would be much better than trying to circumvent the issue.

[iGreybear]

Hi DarwinNE,

I have this problem from Fedora 2x onwards. in this period many things have changed in the operating system including java and graphics server. I have always had the same problem as in my previous ticket (2017) but it was never possible to find the origin of the problem and a solution, for this reason I proposed that trick. It is practical and solves the problem. Furthermore, a magnification of 500% or 503% does not give appreciable differences.
The only thing I could see is that during the movement of a symbol the java process rises to 100% for several seconds while setting rounded magnification values ​​to tens this time is worth fractions of a second.
I hope I was helpful.

[DarwinNE]

Thank you for the information.
If you hide the grid, by chance, do you see any difference in the redraw speed?

[iGreybear]

Great! The grid is the problem.
I always use the grid.

[DarwinNE]

Ok, I think I have an idea of the origin. The grid code is much more complex than one would expect and I think I can see why it can slow down things in certain situations.

[DarwinNE]

@iGreybear can you compile and test the code in the repository to see if the situation improved? If not, I think I will publish a new preliminary version in a few days.

[iGreybear]

Hi DarwinNE,
I'm sorry, but I don't have a compilation environment into my pc. Normally I install binaries.
I tried to do a stupid "make" but I have an error (./dev_tools/compile: riga 70: javac: comando non trovato) so I imagine I have to learn...
Can I do something else?

[DarwinNE]

Hi @iGreybear,
first of all, many thanks to have tried!!!
From what I see, you only have the Java runtime environment installed, you would need the Java Development Kit. Then, to clean, compile and run the code the command would be make rebuild.

If you don't want (or can't) install the JDK, don't worry, I will publish a jar archive in a few days.

Cheers,
D.

[iGreybear]

Tomorrow morning I will try Il dom 19 apr 2020, 22:35 Davide Bucci <[email protected]> ha scritto:

…

Hi @iGreybear <https://github.com/iGreybear>, first of all, many thanks to have tried!!! From what I see, you only have the Java runtime environment installed, you would need the Java Development Kit. Then, to clean, compile and run the code the command would be make rebuild. If you don't want (or can't) install the JDK, don't worry, I will publish a jar archive in a few days. Cheers, D. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#166 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACQM472C5VZTNDQFQAEMJNDRNNOAJANCNFSM4KAPQ4HQ> .

[iGreybear]

Hi DarwinNE,

It's all ok! It's fast enough to work on a complex wiring schema.
Just a notice: in the following component "Simboli Elettrotecnica -> Contatti a due o tre vie -> Commut. bipolare due vie tre pos. centr. di apertura", two pins do not reach the point of grid. This is not related with the compilation.

Here the warnings after the make rebuild:
[domenico@localhost FidoCadJ-master]$ make rebuild
warning: [options] bootstrap class path not set in conjunction with -source 7
warning: [options] source value 7 is obsolete and will be removed in a future release
warning: [options] target value 7 is obsolete and will be removed in a future release
warning: [options] To suppress warnings about obsolete options, use -Xlint:-options.
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
4 warnings
Cannot save the library status.

Here my
PC: Linux version 5.4.18-100.fc30.x86_64 ([email protected]) (gcc version 9.2.1 20190827 (Red Hat 9.2.1-1) (GCC)) #1 SMP Fri Feb 7 14:37:00 UTC 2020
JDK: jdk-14.0.1_linux-x64_bin.rpm

[DarwinNE]

Hi @iGreybear
thank you very much, that is great!

Just a notice: in the following component "Simboli Elettrotecnica -> Contatti a due o tre vie -> Commut. bipolare due vie tre pos. centr. di apertura", two pins do not reach the point of grid.

Can you please open another issue? I am closing this one.

Thanks again,
D.

[Max2433BO]

Sorry, @DarwinNE ,

but I have some problem on FidoCadJ 0.24.8 with Ubuntu 18.04.4.

In practice, with certain zoom levels, the scroll is slow and the movement of the selected objects follows the movement of the cursor with delay.

For example, see the following file:

[FIDOCAD]
FJC C 3.0
FJC B 0.5
TY 110 89 4 3 0 3 0 * 1
TY 116 89 4 3 0 3 0 * 1
TY 122 89 4 3 0 3 0 * 0
TY 128 89 4 3 0 3 0 * 0
TY 134 89 4 3 0 3 0 * 1
TY 140 89 4 3 0 3 0 * 0
TY 146 89 4 3 0 3 0 * 1
TY 152 89 4 3 0 3 0 * 0
TY 158 89 4 3 0 3 0 * 1
TY 161 91 3 2 0 0 0 * (2)
LI 108 95 108 81 0
LI 108 81 169 81 0
TY 86 89 4 3 0 3 0 * 1
TY 92 89 4 3 0 3 0 * 1
TY 98 89 4 3 0 3 0 * 1
TY 101 91 3 2 0 0 0 * (2)
TY 116 99 4 3 0 0 0 * 1
TY 122 99 4 3 0 0 0 * 1
TY 128 99 4 3 0 0 0 * 1
TY 110 72 4 3 0 3 0 * 1
TY 116 114 4 3 0 0 0 * 1
TY 122 114 4 3 0 0 0 * 0
TY 128 114 4 3 0 0 0 * 1
TY 122 124 4 3 0 0 0 * 1
TY 134 114 4 3 0 0 0 * 1
TY 128 124 4 3 0 0 0 * 1
TY 134 124 4 3 0 0 0 * 1
TY 122 138 4 3 0 0 0 * 1
TY 128 138 4 3 0 0 0 * 0
TY 134 138 4 3 0 0 0 * 0
TY 116 72 4 3 0 3 0 * 1
TY 140 138 4 3 0 0 0 * 0
TY 134 148 4 3 0 0 0 * 1
TY 140 148 4 3 0 0 0 * 1
TY 128 148 4 3 0 0 0 * 1
TY 122 72 4 3 0 3 0 * 1
TY 140 178 4 3 0 0 0 * 1
TY 146 178 4 3 0 0 0 * 1
TY 152 178 4 3 0 0 0 * 0
TY 128 72 4 3 0 3 0 * 0
TY 134 72 4 3 0 3 0 * 0
TY 158 178 4 3 0 0 0 * 1
TY 158 189 4 3 0 0 0 * 1
TY 152 189 4 3 0 0 0 * 1
TY 146 189 4 3 0 0 0 * 1
TY 152 197 4 3 0 3 0 * 1
TY 158 197 4 3 0 3 0 * 0
TY 146 197 4 3 0 3 0 * 1
TY 140 72 4 3 0 3 0 * 1
TY 143 74 3 2 0 0 0 * (2)
TY 146 157 4 3 0 2 0 * 1
TY 140 157 4 3 0 2 0 * 1
TY 140 165 4 3 0 2 0 * 1
TY 146 165 4 3 0 2 0 * 1
TY 152 165 4 3 0 2 0 * 0
TY 161 199 3 2 0 0 0 * (2)
TY 145 68 3 2 0 3 1 * Quoto
TY 145 85 3 2 0 3 1 * Dividendo
TY 86 85 3 2 0 3 1 * Divisore
TY 149 204 3 2 0 3 1 * Resto
LI 138 168 56 168 2
FCJ 0 0 3 2 1 0
LI 138 160 62 160 2
FCJ 0 0 3 2 1 0
LI 135 49 135 71 2
FCJ 2 0 2 1 1 0
LI 62 160 62 55 2
FCJ 0 0 3 2 1 0
LI 62 55 129 55 2
FCJ 0 0 3 2 1 0
LI 56 49 135 49 2
FCJ 0 0 3 2 1 0
LI 129 55 129 71 2
FCJ 2 0 2 1 1 0
LI 56 168 56 49 2
FCJ 0 0 3 2 1 0
TY 147 183 3 2 0 0 7 * 0
TY 123 143 3 2 0 0 7 * 0
TY 117 119 3 2 0 0 7 * 0
TY 117 94 3 2 0 0 7 * 0
TY 141 183 3 2 0 0 7 * 0
TY 111 94 3 2 0 0 7 * 0
LI 80 75 108 75 8
FCJ 2 0 2 1 1 0
LI 126 151 68 151 8
FCJ 0 0 3 2 1 0
LI 50 43 141 43 8
FCJ 0 0 3 2 1 0
LI 144 192 50 192 8
FCJ 0 0 3 2 1 0
LI 117 67 117 71 8
FCJ 2 0 2 1 1 0
LI 80 102 114 102 8
FCJ 0 0 3 2 1 0
LI 50 192 50 43 8
FCJ 0 0 3 2 1 0
LI 68 61 123 61 8
FCJ 0 0 3 2 1 0
LI 141 43 141 71 8
FCJ 2 0 2 1 1 0
LI 68 151 68 61 8
FCJ 0 0 3 2 1 0
LI 74 127 74 67 8
FCJ 0 0 3 2 1 0
LI 123 61 123 71 8
FCJ 2 0 2 1 1 0
LI 80 75 80 102 8
FCJ 0 0 3 2 1 0
LI 74 67 117 67 8
FCJ 0 0 3 2 1 0
LI 120 127 74 127 8
FCJ 0 0 3 2 1 0
TY 146 175 3 2 0 0 11 * 1
TY 128 135 3 2 0 0 11 * 1
TY 128 86 3 2 0 0 11 * 1
TY 140 135 3 2 0 0 11 * 1
TY 122 108 3 2 0 0 11 * 1
TY 146 172 3 2 0 0 11 * 1
TY 128 83 3 2 0 0 11 * 1
TY 152 175 3 2 0 0 11 * 1
TY 140 132 3 2 0 0 11 * 1
TY 122 86 3 2 0 0 11 * 1
TY 116 86 3 2 0 0 11 * 1
TY 134 135 3 2 0 0 11 * 1
TY 152 172 3 2 0 0 11 * 1
TY 122 111 3 2 0 0 11 * 1
TY 116 83 3 2 0 0 11 * 1
LI 135 96 135 113 12
FCJ 2 0 2 1 2 0
LI 159 96 159 176 12
FCJ 2 0 2 1 2 0
LI 147 96 147 155 12
FCJ 2 0 2 1 2 0
LI 141 96 141 131 12
FCJ 2 0 2 1 2 0
LI 153 96 153 163 12
FCJ 2 0 2 1 2 0
LI 140 195 161 195 13
LI 110 105 131 105 13
LI 122 154 143 154 13
LI 116 130 137 130 13

FidoCadJ opens it with a zoom set to 521%, and at this level the defect occurs.

Making a little text I found that:

at these levels the defect occurs
513% 514% 518% 521% 522% 526% 527%

but not to these
511% 512% 515% 516% 517% 518% 523% 524% 525% 528% 529% 530%

As mentioned in another post, even in this case, if you disable the grid, the problem disappears.

Bye, Max

[DarwinNE]

Hello @Max2433BO,
thank you, I reopen the issue.

The problem is as usual drawing the grid in an efficient way.

Cheers,
D.

[JoopN]

I have big complex drawings too (I think, it takes 10 seconds before opening and correct placement in screen). I noticed on a Raspberry Pi 400 that it matters if you are on the standard values of the zoom setting or if you are on a figure somewhere in between. Also grid on or off matters. Special placing (complex) items somewhere in the workarea takes a while. I'm not sure if this is the edge of the Raspberry Pi or if this is Java or if this is FidoCadJ.