With a GDC 3.50 we don't see this phenomenon because obviously AUI tree it is better controlled but in UR this part of the table display processing is not totaly optimized.
I don't know if you have raised a support case, but just on the above.
a) there was no GDC 3.50. So I don't know what your before and after for comparison is, and if you are using latest versions. For instance there was an issue
https://4js.com/support/issue/?id=GBC-2684 delivered in GBC 1.00.59 and then a little more in 4.00.03 which should give better responses. You should give versions when raising with support.
b). The AUi Tree and User interface protocol (With reference to
http://4js.com/online_documentation/fjs-fgl-manual-html/#fgl-topics/c_fgl_DynamicUI_006.html or even better this diagram
http://4js.com/online_documentation/fjs-fgl-manual-html/#fgl-topics/c_fgl_feconn_protocol.html ) is the same wether you are GDC+Native+SSH, GDC+Native+GAS, GDC+UR+SSH, GDC+UR+GAS . So not sure what you mean by AUI Tree is better controlled. The AUI Tree is the same.
I understand communication is a tiny bit slower using GAS vs SSH but is generally not noticeable.
GDC+Native vs GDC+UR. With GDC+Native, the GDC is an executable with compiled code rendering the AUI Tree. With GDC+UR and GBC in a browser, you have interpreted Javascript rendering the AUI Tree. The expectation is that this will be slower but again is not generally noticeable. One place it can be noticed is with Folder Rendering, see here
https://4js.com/ask-reuben/ig-108/ where I discussed this. Essentially you won't notice when one screens size worth of rendering is calculated but you might if it is 10 folder pages that are being calculated as that is effectively 10 screens worth of rendering.
With Tables and the AUI Tree, the front-end sends to the backend the visible rows and the unhidden columns. I covered this here
https://4js.com/ask-reuben/ig-28/#:~:text=I%20would%20also%20like%20you%20to%20refresh%20your%20memory (perhaps I should have that as a standalone entry). If there is 20 visible rows and 20 unhidden columns this is 400 values.
1. If you are on a slow network or slow device you might ask yourself, how can I reduce what is sent to 10 visible rows and 10 unhidden columns, so only 100 values or a 1/4 of the data is sent. That might involve using WANTFIXEDPAGESIZE to keep the number of rows manageable, or it might involve initially hiding columns to reduce number of columns sent. Also look for the use of TEXTEDIT within an array as the whole text value is sent.
2. A valid question, particular as you mention scrolling, is to ask how often over the course of this scrolling is the communication taking place between front-end and back-end. For instance there was an issue with completer where GBC requested an interaction after every keystroke whereas GDC bundled up keystrokes. See
https://4js.com/support/issue/?id=GBC-02671 . So with GBC there was AUI interaction after every keystroke so ON CHANGE was fired as you typed A, AB, ABC, ABCD etc whereas with GDC, the AUI interaction was after user stopped typing for X milliseconds, so ON CHANGE was fired only after ABCD. A way to test for something similar with array scrolling would be to capture two GUI logs, one with Native, one with UR. See
http://4js.com/online_documentation/fjs-fgl-manual-html/#fgl-topics/c_fgl_feconn_replay.html for how to capture a GUI log. What we would be looking for if you scrolled from row 1 to row 11, is how many times is the AUI tree updated? Is it the same, more, or less?
3. If the current row is changing in the user action then BEFORE ROW would also be triggered and you'd also have to look at what that is doing. There was an interesting case which I don't think has been delivered yet. BEFORE ROW changed the GROUP title via DOM. A GROUP Box is sized as minimum of content and title, hence changing the title caused the group size calculation to occur. Everything the GROUP was a child of, was then recalculated. In this case GROUP was in a PAGE, so FOLDER size was being recalculated to see if it should be wider now that the GROUP title had changed. Not noticeable on Native but was on UR. I mention this just to get you to examine, is your table in a folder? Is there code being executed by a BEFORE ROW?
4. Another question relates to use of .4st. If you use our default.4st is performance same or similar.? Frozen columns maybe a factor. As might how alternate row color shading is implemented (alternateRows
http://4js.com/online_documentation/fjs-fgl-manual-html/#fgl-topics/r_fgl_presentation_styles_table_style_attributes.html is much faster than old pseudo selectors) . Also is setCellAttributes in use. In general look for anything you are doing that maybe different from standard. That normally comes out if we see a log or an example. (also in this area, standard vs customised GBC, is that a factor)
Reuben
Sign in for full access
Help
