Closed EulenspiegelTill closed 1 year ago
@EulenspiegelTill , have you tried with latest 2.7.2?
Yes, also tested with the actual version. The thing is, it was quite handy to use before and came much, much slower by the actual verisons.
In the attribute form expr. like the one below are used ~26x:
with_variable(
'first_snapped_point',
array_first( @snapping_results ),
attribute(
get_feature_by_id(
map_get( @first_snapped_point, 'layer' ),
map_get( @first_snapped_point, 'feature_id' )
),
'id_messtelle_art'
)
)
@EulenspiegelTill , ok. Two things would help moving this forward: 1/ provide a test case to replicate slowness 2/ go to the GitHub releases page and identify which extract version regressed
@nirvn 1/ sent private to matthias 2/ 1.9.6 😳
@EulenspiegelTill , just to double check I understand you well: 1.9.5 was fine and 1.9.6 became slow to you?
@nirvn good double check. No, we were rolling on 1.9.6 and postponed the updating on an actual version, because everything was fine 😉 . Have done the update two weeks ago and was facing the speed issue on 2.6.0.
@EulenspiegelTill , was 2.5.7 fine?
@nirvn No, also slow.. but we jumped from 1.9.6 to 2.6.0.
@EulenspiegelTill , ok, I'll look into profiling this in the coming days. In the meantime, since slowness is partially subjective ( 😃 ), what would help a lot is for you to work your way back to 1.9.6 one release at a time and identify which point release caused the perceived slowdown.
Ive tested your project over here on my pixel 6a and while I do see a 2-3 seconds is required to open the attribute form, it doesn't appear to be slower than when I tried the project on QGIS itself with my beefy workstation.
Btw, your project looks fantastic, great to see QField unlocking that kind of really advanced data entry.
@nirvn did a little rollback, sadly startet at the bottom than at the top.. 2.4.0 was running smooth. 2.5.7 was the first running version of the 2.5.x and there the editing becames slow. see the vids attached. When i use a newer tablet for sure it is a bit faster, but still not responsive enough for working productive.
https://kdrive.messtechnik.ch/app/share/121947/f272f616-0b89-4019-99cd-f0eaf1215438
since slowness is partially subjective ( 😃 )
hope the vids are explaining the feeling of slooooww..
@EulenspiegelTill , super helpful.
Was 2.5.6 also slow or you've only tried 2.5.7 in the 2.5.X series?
@nirvn there it was always crashing when editing new points.. 2.5.7 was the first working on my tablet.
@EulenspiegelTill , alright. You've been super helpful in gathering information. I'll keep you posted on findings.
@EulenspiegelTill , can you give these APKs a try: https://github.com/opengisch/QField/pull/4123#issuecomment-1498417757 -- thanks.
@nirvn, no changes in case of sloowww..
@EulenspiegelTill , can you try new APKs here: https://github.com/opengisch/QField/pull/4123#issuecomment-1498417757 (it's not a solution per say but I would like to see whether we can rule out one specific change in 2.5).
@nirvn bit less slow but still not comparable with 2.4 see the vids link on top, put the vids of 2 apk version in there.
@EulenspiegelTill , OK, good to eliminate individual editor widgets at causing the regression.
More APKs: https://github.com/opengisch/QField/pull/4123#issuecomment-1498417757 -- these tests whether the use of a scrollbar in >= 2.5 caused the regression. If you can test those, it'd be great. I have one more test in mind after that.
@nirvn nope.. vid attached in the link on top, still slow. i will be off till Tuesday from now, can test the next apke then.. happy 🐰 🥚
@EulenspiegelTill , if by any luck you are still around, one last pre-easter set of APKs to test: https://github.com/opengisch/QField/pull/4123#issuecomment-1498417757
@EulenspiegelTill , also, thinking outloud here, in QField 2.4, is it possible that you do see a freeze, but it only occur once (e.g. when you toggle digitzing mode on and/or switch active layer)?
@nirvn @EulenspiegelTill due to covid i had time to test over :egg: :rabbit:
in https://github.com/opengisch/QField/pull/4126 and https://github.com/opengisch/QField/pull/4131 i noticed a freeze/lag when i tried to enter a value in a field after the form has been opened. ->> After this freeze all values populated by @snapping_results defauts are wiped out of the form :boom:
in https://github.com/opengisch/QField/pull/4131 opening the attribute form after snapping is muuuuch faster on my fairphone3 than with the current release.
i can also confirm the freeze while toggling the digitzing mode.
@soester , thanks for testing, let's try to focus on perceived speed issue (ie there might be something else going on with the snapping result variable).
When you say that you can confirm the freezer when toggling the digitizing mode, you meant with 2.4 or with the test builds?
Is 4131 overall an improvement?
@nirvn didn't test with 2.4 just tried to reproduce the freeze with the test builds (4131 and 4126) and was not able to. anyway this is not a big probelm.
4131 is defenitly an improvement speed-wise! wiping the whole form is a bit scary, but im sure you'll be able to fix that :-)
@soester , the wiping of the whole form is replicable with the test project attached above referred to here? Is it an issue with 2.7.2?
@soester , alright, as suspected, this was a separate problem, which also affects released QField versions. Let's move the discussion on this within the PR which I hope fixes the issue here: https://github.com/opengisch/QField/pull/4138 -- you'll have some APKs to test within 10 minutes or so.
Yeah @nirvn you were right, that seems to bee another big issue in current releases. i first had to check the project versions. i was not using the exact same project @EulenspiegelTill shared with you. unfortunately the wiping attribute form issue persists in https://github.com/opengisch/QField/pull/4138. also the performance gain is not as obvious as i saw it yesterday. i will try to find out which version it was that was faster.
https://github.com/opengisch/QField/pull/4123 is a bit faster. https://github.com/opengisch/QField/pull/4131 is much faster.
@soester , #4138 has no performance gains, just working on this wiping situation. Can you provide a test project in that PR for me to test? I was seeing it fixed on the project @EulenspiegelTill had shared
@nirvn sorry for the confusion. i think i messed up the (many) qfield versions. i can confirm the fix. from now on i will test with the project from @EulenspiegelTill !
@soester , thanks for all the testing.
@EulenspiegelTill , it would be great if you could test the APKs in #4123 and #4131 and report back your experience with both builds. I think #4131 might be bring back QField performance close to what 2.4 was.
@nirvn #4123 ist still slow, but #4131 is fast as.. it is at the performance of 2.4 with the "old" tablet, would be nice to work like this again! 👍
@nirvn we further tested https://github.com/opengisch/QField/pull/4131 and there is some strange behaviour in our forms:
@EulenspiegelTill just tested one field (messtechniker in tab kampagne), this works so we didn't discover the rest.
@soester , let's deal with these as separate issues. Feel free to open PRs on specific issues you spot with replicable steps.
Fixed
Describe the issue
We have noticed a strong loss of speed since version 2.6.0 our last used QField Version was about 2.2.x we used. When capturing new object points, the opening of the attribute fields takes up to 10s.
There are many @first_snapped_point used in the attribute form, maybe they are an issue.
Samsung Galaxy Tab Active 2: https://www.gsmarena.com/samsung_galaxy_tab_active_2-8897.php Creating Point >6s
Samsung Galaxy Tab Active 3: https://www.gsmarena.com/samsung_galaxy_tab_active3-10476.php Creating Point ~2s
Maybe we just need a little hint where to search on or where the trouble is originated.
Reproduction steps
Steps to reproduce the behavior:
Expected behavior
to be faster
Observed behavior
slow
Mobile (please complete the following information)
Additional information