Bisq UI very laggy/slow on Windows 8 #3308
Comments
fresheneesz
changed the title
|
This happen in my computer too. I thought that is because java is slow and my computer is old (editor Intelij IDEA/android-studio also are laggy/slow). |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
This is still a very relevant usability problem. |
ripcurlx
added
the
is:priority
|
Any updates on this? The platform is unusable. |
Update the gradle dependency to JavaFX 14. This brings to Bisq the latest JavaFX fixes and improvements, especially in the areas of UI performance, memory management and security. JavaFX can be upgraded independently of the JDK used to build the application, so this change is modular and does not affect other parts of the build process. Related / likely related to: bisq-network#350 bisq-network#2135 bisq-network#2509 bisq-network#3128 bisq-network#3307 bisq-network#3308 bisq-network#3343 bisq-network#3430 bisq-network#3657 bisq-network#3677 bisq-network#3683 bisq-network#3686 bisq-network#3786 bisq-network#3787 bisq-network#3892 bisq-network#3917 bisq-network#3918 bisq-network#3936
|
TradeStatistics and DaoState objects are growing and might be a reason for those issues. A fix for TradeStatistics is in progress. |
Update the gradle dependency to JavaFX 14. This brings to Bisq the latest JavaFX fixes and improvements, especially in the areas of UI performance, memory management and security. JavaFX can be upgraded independently of the JDK used to build the application, so this change is modular and does not affect other parts of the build process. Related / likely related to: bisq-network#350 bisq-network#2135 bisq-network#2509 bisq-network#3128 bisq-network#3307 bisq-network#3308 bisq-network#3343 bisq-network#3430 bisq-network#3657 bisq-network#3677 bisq-network#3683 bisq-network#3686 bisq-network#3786 bisq-network#3787 bisq-network#3892 bisq-network#3917 bisq-network#3918 bisq-network#3936
|
I am also on low-end hardware and the app is not usable at all. Opening a drop-down menu takes 10 seconds, scrolling is a pain. A lightweight web-interface would be in my opinion a bit faster than the current GUI. |
That might happen if the bottom bar is saying that DAO is synchronizing right now. That is generally an intensive process. In my experience, once that process is over, the UI is much more responsive. Also, depends what you mean with low-end hardware. Bisq needs at least 2-3GB free RAM. Even with "synchronizing DAO" task in progress, any UI click responds within 1-2 seconds for me on a 2014 macbook, even faster after that task is done. |
|
An API is being worked on, which will make a web-UI possible soon. |
|
An API is being worked on, which will make a web-UI possible soon.
That's very good news, thanks! Indeed the app gets a little more responsive
after the DAO is finished synchronizing.
V V ned., 18. okt. 2020 ob 23:47 je oseba cd2357 <notifications@github.com>
napisala:
… An API is being worked on, which will make a web-UI possible soon.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#3308 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AKFM2ETKF3MTXOIJQRPHF6DSLNPAHANCNFSM4IZELNSA>
.
|
|
I have the very same problem. |
What do you mean a web-UI? You mean a website that runs Bisq? Or do you mean something like a downloadable chromium app? |
|
What do you mean a web-UI? You mean a website that runs Bisq? Or do you
mean something like a downloadable chromium app?
Yes, a website, acting as an interface to the Bisq program. Not a
downloadable chromium app. Chromium is slow and why download a browser when
you already have one?
…On Thu, 5 Nov 2020, 19:48 fresheneesz, ***@***.***> wrote:
which will make a web-UI possible soon.
What do you mean a web-UI? You mean a website that runs Bisq? Or do you
mean something like a downloadable chromium app?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#3308 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AKFM2EUI2UU3II5PVPXOGZLSOLXQLANCNFSM4IZELNSA>
.
|
Because a downloaded browser is stable and doesn't change until the user opts in to upgrade. When you use a web app, you're literally installing a (potentially different) application every single time you load a page. This has massively more attack surface than a downloaded app you can verify with deterministic builds. Please don't make Bisq a web app. Just improve the downloadable program. Its perfectly fine to have Bisq information on a website that shows you what the market is doing. But as soon as you have people sending money on a website, you're asking for phishing attacks and other shenanigans. Please don't replace the desktop app with a web app! Don't make a web interface for trading at all!! |
|
The reasons why Bisq has performance issues are engineering problems which can be solved with enough dev power. But that is a scarce resource since ever. The UI technology would not make the difference. Its a highly complex application and optimization is always only done once problems occure and they are often not easy. A web-app would not work for the level of decentralisation Bisq provides. |
|
@chimp1984 I agree a web-app wouldn't work for the level of decentralization Bisq aims to provide. However, I don't think the complexity of the application has anything to do with the performance issues Bisq's UI suffers from - at least not the kinds this ticket is about. The UI technology could very well make a huge difference in the operation of the UI. Its pretty clear to me that a lot of heavy non-UI processing is done on the same thread as the UI runs on. In well designed applications, this isn't the case - UI gets a separate thread from the non-UI code for this very reason. This may not be an easy thing to fix, but changing to a new UI technology may be a simple way to fix it. |
|
I don't think you understand what a web-UI would mean in this case. It
would still work with the level of decentralization Bisq aims to provide,
as you would still host your own server that would do everything the Bisq
client does, but without the interface.
The interface would be accessed via the HTTP protocol, but since it still
just connect to the website you are hosting locally there's no issue with
decentralisation.
This brings many pros:
* The ability to have the Bisq node connected without a desktop/monitor
* the ability to write command line lightweight interfaces
* the ability to host the server on a different machine than the client
(for example on a server that is connected to the internet and turned on
24/7)
* Write APIs and wrappers for automating stuff via HTTP.
V V pet., 6. nov. 2020 ob 17:33 je oseba fresheneesz <
notifications@github.com> napisala:
… @chimp1984 <https://github.com/chimp1984> I agree a web-app wouldn't work
for the level of decentralization Bisq aims to provide. However, I don't
think the complexity of the application has anything to do with the
performance issues Bisq's UI suffers from. The UI technology could very
well make a huge difference in the operation of the UI. Its pretty clear to
me that a lot of heavy non-UI processing is done on the same thread as the
UI runs on. In well designed applications, this isn't the case - UI gets a
separate thread from the non-UI code for this very reason. This may not be
an easy thing to fix, but changing to a new UI technology may be a simple
way to fix it.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#3308 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AKFM2EUWWRKJTPW4Z44OS6DSOQQMHANCNFSM4IZELNSA>
.
|
|
@sijanec, as @cd2357 mentioned, steady progress is being made on a Once the Pushing back on all this is the lack of devs who like to work cheap -- to paraphrase @chimp1984 -- but people are working on solving the problems you've found. |
|
Thanks for the response!
I agree that the developers should focus more on the key features of Bisq
and I am sorry for not making making research. Thanks for posting the link,
I'll keep myself updated. If HTTP API would be created, some basic UIs will
probably be made by the community, and that's enough for some users.
Rgds.
…On Fri, 6 Nov 2020, 18:44 Stan, ***@***.***> wrote:
@sijanec <https://github.com/sijanec>, as @cd2357
<https://github.com/cd2357> mentioned, steady progress is being made on a
gRPC API -- see https://github.com/orgs/bisq-network/projects/17.
Once the gRPC API and CLI is stabilized, released, accepted, etc., a
closer look will be taken at a grpc-gateway (reverse proxy) that would make
the headless server able to serve HTTP 1.1 RESTful clients too, *but UIs
will not built by Bisq devs*. There is a POC for this:
https://github.com/ghubstan/bisq-grpc-gateway. There is no consensus
about going forward with the reverse proxy idea, but it will be examined,
then rejected or approved after (and if) the gRPC API achieves its
purpose.
Pushing back on all this is the lack of devs who like to work cheap -- to
paraphrase @chimp1984 <https://github.com/chimp1984> -- but people are
working on solving the problems you've found.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3308 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AKFM2ERYFQJAWQ4VP4W2C4DSOQYZJANCNFSM4IZELNSA>
.
|
Great thanks for the lecture in CS ;-) The offer views are pretty snappy on my 6 year old iMac. Maybe you have some local issues with either DAO not in sync or some other issues. Most devs are on Linux or OSX so windows is less tested, but as there are not many more reports about what you described I assume its a local issue. Only known issue is when the DAO is syncing after longer not using Bisq it slows down all, but there is work planned to improve that and it only affects users who dont regularily use Bisq. |
This is a windows issue. The underlying code is different on windows, no?
I see at least four reports above. For a small subset of users on a relatively small program like Bisq, that's a lot. I assume you are aware of the concept that if there is 1 person reporting an issue, 10 to 100 are probably seeing the issue. So I don't understand the dismissal of these reports as a "local issue". Regarding the web UI: as long as no one is advocating that anybody connect to a server they're not running themselves, I think that's perfectly reasonable. |
No. Java is cross platform. There are very tiny, for this case irrelevant differences. |
|
This is a windows issue. The underlying code is different on windows, no?
It's not just a windows issue. The code is the same for both platforms.
I have the same issue on Debian.
The problem is that you can't separate the UI and server and that the UI is
written in a way that is /expected/ to be "slow". Instead of a native GUI
the app is written in HTML as far as I know.
rgds
V V sob., 7. nov. 2020 ob 22:07 je oseba fresheneesz <
notifications@github.com> napisala:
… on my 6 year old iMac
This is a windows issue. The underlying code is different on windows, no?
as there are not many more reports about what you described I assume its a
local issue
I see at least four reports above. For a small subset of users on a
relatively small program like Bisq, that's a lot. I assume you are aware of
the concept that if there is 1 person reporting an issue, 10 to 100 are
probably seeing the issue. So I don't understand the dismissal of these
reports as a "local issue".
Regarding the web UI: as long as no one is advocating that anybody connect
to a server they're not running themselves, I think that's perfectly
reasonable.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3308 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AKFM2ET37KK7GZFRHP45RY3SOWZHPANCNFSM4IZELNSA>
.
|
|
As we are stuck on Java 10 and an outdated JavaFX version for more than a year already, I expect as soon as #4242 gets merged to get rid of a couple of nasty memory issues we are seeing right now. Maybe also delivers some improvements on CPU consumption on Windows, but I haven't tested it personally just yet. |
ghost
mentioned this issue
|
UI Laggs are impossible to work with, i'm having issues on Arch |
|
@sTiKyt have you tried waiting until after "Synchronizing DAO" finishes? That's a very taxing process from what I've seen, works much smoother for me after it finishes. |
Yes, i am "Synchronized"... And i reported UI laggs AFTER i got synchronized |
|
Should be fixed in the most recent release (v1.6.4) which brings several UI performance improvements and generally reduces system resource consumption (especially RAM). Please try it out and let us know if it's still an issue for you. |
|
Bisq 1.8.2 and it is still slow as worm. It became even slower than 1.6.4. Nothing except windows and bisq is installed. |
|
@maildeno0 if you could share your bisq.log perhaps we'll notice a reason for the slowness. Perhaps there is a network sync process going on in the background or something. From my own perspective, Bisq on Windows seems faster than Linux, so that makes me surprised to read your report. Regards. |
Bisq is very laggy. It has been this way for a while, and persists in the latest version v1.1.6. It often takes a full second to register button clicks, especially tabs like "Buy BTC" and "Sell BTC", possibly because they have lots of data to load. However these pages should be cached, especially if you've just gone to the page - there should be no reason that a new view needs to be loaded from scratch. And if those kinds of things take a long time to render, they should be preloaded.
It seems clear to me that background processes are blocking the UI. Those background processes should be run in a separate thread from the UI so that doesn't happen. For example, last time I started up Bisq, the UI took upwards of 5 seconds to respond to actions. This happens randomly at other times too.
I'm not sure if maybe memory problems are related: #3307.
The text was updated successfully, but these errors were encountered: