Community
Participate
Working Groups
When opening the batch service view on a batch system with ~100 nodes, it takes around 5 seconds for the view to be ready. Much worse for the user is that the views in eclipse cannot be resized anymore (almost, the bar separating the views moves just a few pixels each time). The views can be resized again if the batch system view/editor is hidden by another tab.
5 seconds is on my laptop, Centrino 1,8MHz and 2GBy, just for reference only, but to give an idea. Some profiling would be here really helpful to know what is taking the cicles.
Centrino 1,8MHz would explain the slowness, i meant 1,8GHz ;-)
It will take me some time to look at this. I have some ideas of how to "compress" the information displayed for large sites.
Kyriacos is working on redesign of the GUI that will be applied in the next few weeks and should be ready for the M5 release.
Created attachment 96251 [details] New GUI to enhance performance New GUI
Patch is applied. Ariel would you mind testing out the new GUI and see if it is still slugish for a medium site?
No, now it works quite fast, tested with 256 nodes. Nice. I noticed a couple of minor issues however, reporting here to avoid opening a new bug: - the gray "box" containing all the WNs is much longer than necessary (see screenshot) - the arrows connecting the Queues -> batch system -> WNs behave "randomly" when moving the batch-system box around (see screenshot) Sometimes the arrow starts/end near the middle of the border, but as you start shifting the BS box to the side the arrow ends start to "drift" towards the middle of the box, on some WN for instance.
Created attachment 98055 [details] Box bigger than necessary
Created attachment 98056 [details] Arrows do end/start in strange places
And yet another 2 small issue: - the Batch-system box can be moved "under" the Queues or WNs boxes, and the WNs box under the queues box (see attachment, you can also see here how the arrows get crazy ;-) Either you should forbid the boxes to "step on each other" or the BS box should be the uppermost one (then queues, then WNs below all). - also dragging one box A over the other B, seems to interpret that we want to drag and drop it inside B: grab box A anywhere, and move the mouse over box B.... then some "location" in box B is activated as if we could drop A into that location of B. (And if you actually release the mouse when the pointer is over B, then box A jumps back to its original position, doesn't get moved. This is fine for me)
Created attachment 98057 [details] Layer ordering
Kyriakos will work on this
Created attachment 100144 [details] Solving the last issues Solving the last issues
Patch applied
Changing status to fixed and added the contributed keyword for Kyriakos patch
Works much better now thanks (although there are still some tinny strange behaviours... which i do not think it is wirth caring about now ;-) Two other size-related issues which are still important: - i am able to resize the Queues and Nodes boxes to sizes smaller than the area required by the objects inside... If i make the box more narrow, more rows are added, but then the elements dissapear at the "bottom". And there is no visual indication of these "missing" elements. But we do not want scrollbars there, right? so perhaps a good solution is to block resizing when the area required by the boxes inside is smaller than the new "proposed" area. - the default size of the batch-system box is too small and the text (# of WNs, # of queues) gets cut...
Created attachment 102330 [details] fixing the last issues fixing the last issues
Created attachment 102336 [details] a small change :)
Can this one be closed?
Yes, fine now, closing
Comment on attachment 100144 [details] Solving the last issues Applied by Harald G
Comment on attachment 96251 [details] New GUI to enhance performance Applied by Harald G
Comment on attachment 102330 [details] fixing the last issues Applied by Harald G
Comment on attachment 102336 [details] a small change :) Applied by Harald G
