Time for a complete re-write or start over with v2 of DWC
-
To be contentious, I tend to agree with the OP but not for the same reasons. IMO, the performance is OK but the layout and functionality leave a lot to be desired. I have submitted numerous requests on the forums, but nobody who can fix it takes much notice
e.g. https://forum.duet3d.com/topic/24841/anoying-behaviour-with-the-status-page-of-dwc,
and https://forum.duet3d.com/topic/27067/request-to-reduce-the-amount-of-padding?_=1656321685718
The latter was upvoted by two moderators and when I bumped it 3 months later, it was further upvoted by one user and seconded by another. But nothing has changed.
I guess the reason why these things never get fixed is that the majority of users only have a single tool and 3 axes, so they don't have any issue with the interface. Most of the replies to the OP are in the form "it works fine for me so it isn't a problem". But to those people I would say, try it with 6 or more tools and 7 axes then tell me it is just fine. It isn't - even on a large monitor - but with smart phone or similar? - well forget it. And while I'm in rant mode, I've said before that the estimates to completion are as much use as an ashtray on a motor bike and seem to have gotten worse over the years.
I use something called Home Assistant for my smart home devices which is another open source project. It has the ability for users to create their own "tabbed" views based on whatever information they want to see and where on the screen they want to see it, both on large screens and small mobile devices, all without writing any code. Just drag, drop, copy, paste, select from drop down list etc etc. I also use video editing software which enables me to hide/unhide, move, dock, and resize windows depending on what information is relevant to the task in hand. DWC on the other hand gives users almost no control over what information they want to see and uses fixed windows with acres of padding meaning that a scroll wheel mouse is an absolute essential (IMO).
-
This post is deleted! -
@deckingman I don't know if a complete rewrite is required, but I think it's worth discussing the issue at hand.
I see almost entirely identical performance numbers on my laptop which is by all means compared to the machine the original posts values were sampled a potato, so I don't think this can be blamed on a client machine.
Drilling further into the numbers, I see that the main causes for the slow load are three files: app.js (565k,3.84sec), materdialdesignicons-webfont (354k, 3.32sec, and HeightMap.js (486k, 4.3sec (I've skipped the unique identifiers for them). webfont and heightmap.js mostly overlap due to the magic of multiple HTTP connections at the same time, so deferring the load of HeightMap.js until someone clicks on the HeightMap menu item would only shave off a second (still about 10% performance increase).
Considering DOMContentLoaded is at roughly 40% of total load time, I think it should be possible to get load time down to maybe 5 seconds by carefully inspecting why those files are so big.
PS: Here is an article how to reduce the material designs icons font and javascript to only those selectors actually in use:
https://www.shedloadofcode.com/blog/reduce-material-design-icons-font-to-7kb-and-automate-with-pyautogui -- getting that under 10k certainly would be interesting.
-
@oliof I don't really understand much of that and as I said, speed for me isn't really much of an issue. But I was replying to the OP's title, rather than the OPs specific issues.
But just out of interest, I have shortcuts on my desktop to urls for both my printer and home assistant. My printer is hardwired with (Gigabit) Ethernet (running stand alone - no SBC), as is my PC and my Odroid running home assistant. With my browser open, if I click the shortcut for home assistant, the page appears fully loaded in less than a second. That's displaying data from over 40 devices, each with multiple "entities" as well as long term statistics graphs. If I click the shortcut for my printer (which is powered up) it takes around 6 seconds for DWC to connect and load. I don't know enough to say it's a DWC issue or a Duet board issue.
I'm just putting that out there - it's neither here nor there to me personally if DWC takes 6 seconds to load or 1 second but I kind of "get" what the OP is saying. The only speed issue I have is with the ancient laptop that is connected to my network via WiFi and which takes a long time to upload large gcode files. The fix is easy - I just use my (wired) desktop PC instead.
-
@deckingman surely one contributing factor is that home assistant runs on a computer (Odroid), and the DWC UI comes from an ESP chip which has it's own IO and resource limits. I don't have an SBC setup because I don't see the point, but it may be worth looking if that loads faster or not, because that would prove a hypothesis that the ESP chip is the bottleneck. Other similarily sized files of DWC load much faster by the way, so it's something specific to the JavaScript/font files and not just an issue with their size.
<>RatRig V-Minion Fly Super5Pro RRF<> V-Core 3.1 IDEX k*****r <> RatRig V-Minion SKR 2 Marlin<>
-
@oliof with a H7 board running an ESP32 at the faster transfer speed (effectively 2.4mb/s), DWC for me loads in about 3 seconds
-
@oliof It sounds like @deckingman may have an ethernet board rather than one using WiFi. My experience (with a Duet2 Ethernet based board), is that wired connections to Duet boards are significantly slower than WiFi based ones....
But for most people I'd guess that speed is not really a big deal. I'd say some of the UI issues are more important.
-
@gloomyandy his ethernet board is still about 60% faster than my STM RRF board on wifi. I agree the UI aspects are worth discussing, but this thread was about speed originally, so I am trying to stick to that topic.
-
I've no idea if any of this is relevant, especially as I'm not too concerned about the speed of DWC but I'll throw it out there anyway as people were commenting about board types and wired vs wifi etc.
Uploading a circa 40 MB gcode file from my aged wifi connected laptop to the printer via DWC takes around 58 seconds at a reported transfer speed of around 750kbits/sec. Uploading the same file via my desktop Ethernet connected PC takes about half that time at a reported speed of roughly 1.6Mbits/sec. Transferring that same file from my Desktop (Ethernet) PC to my aged (WiFi) laptop takes around 3 seconds (no idea what speed that was because it happened too quickly for me to catch it).
All that means is that transferring a file to my printer SD card is about 10 times slower than transferring the same file, from the same machine, to a (aged and slow) Laptop, but it probably proves nothing. It's not my field of expertise by any means but I guess there area number of things at play here, not least of which would be the write speed of the SD card and/or the size of any cache files? It probably has nothing to do with DWC.
-
@fcwilt that's a big part of it. Panel Due leaves a lot to be desired, doesn't it makes sense it SHOULD work on a tablet or mobile just fine?
-
@owend true, but it was written with a framework that is very hard to cone up to speed on for the sake of a hobby.
-
Thanks for the discussion. To clear up some, the point of my post wasn't entirely about speed and certainly not about speed on the desktop.
I ran out of steam and couldn't really get to the mobile device timings. I was hoping to make my point about performance through comparison using the desktop and then implying just how much more burdensome it is on mobile.
There are other points in the post besides performance, if you have the time to read the whole post, please do.
I'm happy to try do more requirements gatherings if interested.
-
@gnydick both the klipper interfaces (fluidd and mainsail) are also written in Vue and Javascript and both actually have their origins in DWC and they seem to do pretty well in terms of features etc.
Hopefully in the future we see DWC getting some more love -
@jay_s_uk yeah, it's totally possible. I have a Voron 0.1 and suspected the heritage. These interfaces are swifter but do also suffer from the interactivity issues, some are worse.
-
@gnydick said in Time for a complete re-write or start over with v2 of DWC:
@fcwilt that's a big part of it. Panel Due leaves a lot to be desired, doesn't it makes sense it SHOULD work on a tablet or mobile just fine?
I'm not a big user of my cell phone for other than calls nor my tablet.
But I know from my programming history that each of those requires a "dedicated" interface design to provide the best user experience. The interface designed for a large computer screen cannot simply be re-used on those smaller screens.
I have noticed many times that web sites I visit using my computer often have very poor implementations for cell phones in particular.
Frederick
-
@fcwilt it's not the differences between desktop and mobile designs, they're actually the same. It's the difficulty in using it with your finger. It's not very touch friendly in the way the controls respond.
For example, I'm scared to death to tap a dialog popup to dismiss it for fear of accidentally tapping whatever is underneath it. Head crash anyone?
The popups should not auto disappear, nor should they be modal.
-
@gnydick said in Time for a complete re-write or start over with v2 of DWC:
@fcwilt it's not the differences between desktop and mobile designs, they're actually the same. It's the difficulty in using it with your finger. It's not very touch friendly in the way the controls respond.
I've done both desktop and mobile designs and for anything complex, like the DWC, they needed to be quite different to be user friendly. At least my idea of user friendly.
Android phones and Apple phones can need different code. Android tablets and iPads can need different code. Apply computers and Windows computers can need different code.
It's not fun and I don't do it any more.
I have not tried to connect to DWC via anything other than my computer. I know I would find it an frustrating experience.
Thanks for the feedback.
Frederick
-
@fcwilt yeah, I was using a different meaning. I was referring to layout using css so you build one page and if you're on mobile it looks one way and on desktop, another.
-
@gnydick said in Time for a complete re-write or start over with v2 of DWC:
@fcwilt yeah, I was using a different meaning. I was referring to layout using css so you build one page and if you're on mobile it looks one way and on desktop, another.
Vue.js has a mode already to decide from sreen resolution and orientation how to display elements, e.g. for a wide tablet screen left-right and mobile top-down.
But this doesn't solve the problem that if there are too much elements, to show
them on one page. IMHO a solution is to add a configuration setting page (and the setting being persisted) where the user decides how to solve it: all details, but only one parameter. Or all details and all parameters, but without spacings, as dense as possible. Another setting could be as much information as possible on one page, or using the tabs and navigation. Or a button "show details". The configuration setting can store the order and position of the personal preference where to see which details also. My wish is to add a "lock all dangerous buttons" button for usage while printing. Another example is, someone with lower eyesight wishes bigger fonts at cost of less information, another user maximum information with small fonts.The disadvantage of individual settings is that help becomes more difficult, but this is a common problem of individual versus standard solutions.
