On Mon, 2018-10-08 at 14:06 +0200, Andrea Giammarchi wrote: > about this: > > is there any way to create callbacks from the javascript world > > using the > Webkit2Gtk webview? > I've created a JSON communication channel between GJS and the > WebViewthrough title notifications: > https://gist.github.com/WebReflection/7ab0addec037508cc8380a9c37d285f2#gistcomment-2245132 > > The nitty-gritty is that you change your title from the page > ```jsdocument.title = `${SECRET}:js=${JSON.stringify(data)}`;``` > and you intercept it from GJS side > ```jswebView.connect('notify::title', (self, params) => { if > (`${SECRET}`:js=/.test(self.title)) { const data = > JSON.parse(self.title.slice(SECRET.length + 4)); // do stuff ... > then ... const response = > {}; self.run_javascript( `document.dispatchEvent( new > CustomEvent( '${SECRET}:gjs', {detail: > ${JSON.stringify(response)}} ) );`, null, (self > , result, error) => > { self.run_javascript_finish(result); } ); }});``` > This way you can pass any serializable data to the listener and > sendeventually data back. The SECRET can be any channel, for circular > data justuse one of the many circular JSON parsers/stringifiers (i.e. > flatted orCircularJSON) > Hope this helps at least with the last part of the question. > P.S. on DOM, a table with 1.000.000 rows would be slow as well, the > way I'mscaling these kind of tables on DOM is by rendering only > what's visible(fixed rows height helps a lot with this) virtually > updating the scroll barwhich is **not** the native one or performance > will be super bad regardless. > > > On Mon, Oct 8, 2018 at 12:44 PM ente <e...@ck76.de> wrote: > > Hi, > > I am facing performance issues in GTK upon presenting a big amount > > oftabular data. First I used GtkListbox for it's layout > > flexibility. Handlingmore than 10,000 items gets inacceptable slow. > > Switching to GtkTreeview Ican handle some 300,000 items after > > applying a few optimizations (columnsizing fixed, fixed height > > mode): a full load takes about 4 seconds, i.e.the application feels > > anything but "responsive" although this is ... ok.Currently I see 2 > > options: dropping Gtk in favor of a HTML frontend (thatfeels > > awkward to say) or implementing paging on the GtkTreeview. > > At this moment I am analyzing the reasons for the performance > > issues. Imeasured the time it takes to generate a number of labels > > in a simple loop(no call ot GtkMain) and to add those labels to a > > GtkBox:* 100 labels in 1.7 ms* 1,000 labels in 20.9 ms* 10,000 > > labels in 610 ms* 100,000 labels in 1m18sAfter the loop I pack the > > GtkBox into a window and show it. That takesanother century to show > > up.If I adjust the loop to skip the packing of the labels into the > > box, thetimes are down to:* 10,000 labels in 115 ms* 100,000 labels > > in 940ms > > The windows shows up instantly (although empty of course). > > So my performance issue is related to the packing. In my tests with > > theGtkTreeview it seems speficially to boil down to the sizing and > > signallingof the items: The performance of the treeview was highly > > impacted by thefixed height mode & the fixed column sizing (more > > than ordering by a columnor calling GtkMain while adding rows). So > > my question goes down to: How canI further optimize my way of using > > GTK in order to speed up UI? Is thereany way to add 1,000,000 > > labels to a GtkBox in less than a second? Could Isomehow suspend > > the signalling during UI creation and replace it by a "I amdone, > > now calculate all the sizes" signal? Am I wrong about my > > assumptionthat the sizing signalling is the cause for the low > > performance? > > With regards to the treeview: After initially creating the data > > rows I amcalculating values that affect 4 columns out of 10 > > columns. So far Idetermine the GtkTreeIter of the affected row and > > update all cells in thatrow using gtk_list_store_set. Should I > > adjust to update the affectedcolumns only? When I implement paging > > for the TreeView: should I ratherdrop the existing ListStore and > > create a new or is it faster to overwriteall elements in the > > Liststore with the new items? > > I tried to use the GtkBuilder in order to setup a box with 100,000 > > labels.This performance was somewhat the same as creating the > > labels in a loop (Ididn't keep the measurements). > > I could isolate the problem to UI rendering. If I don't assign > > myListStore to the Treeview, all is fine. As soon as my ListStore > > is filled,I assign the model to the treeview. That's the most time > > consuming step. > > Last question: is there any way to create callbacks from the > > javascriptworld using the Webkit2Gtk webview? More specificly: I am > > working in golanguage. I am aware of the webview widget. > > Unfortunately that's a window.I would prefer to rather place a > > widget into a native GtkApplicationWindow.Using Eval I can inject > > anything into the DOM. How do I get events from theDOM back to go? > > > > Background on the application:I am developing a text analysis > > application. Text fragments getprecalculated attributes assigned. > > Based on these attributes and theLevensthein distance between > > fragments, someone is supposed to (for now:manually) define text > > fragment categories (categories). Roughly speakingthe application > > has a paned window: on the left I show the category list oran > > editor for a new / existing category; on the right I show a list of > > textfragments with the major 3 attributes or a details view on a > > specificfragment: all attributes and a list of similar fragments. > > The smallest amount of text fragments to be analyzed and > > categorized isabout 300,000 items. The number of items goes easily > > up to 5,000,000 oreven much more. Categorizing all fragments > > requires about 100 to at maximum1,000 categories, i.e. there is > > quite some clustering among those textfragments. On the interface I > > work with highlight colors: a human caneasily realize which > > fragements are already clustered and which aren't.Usually only a > > small number of text fragment categories are of specialinterest. > > One could compare it to a log file: I don't care so much abouthow > > often someone sucessfully authorized; it is much more interesting > > ifsomeone suddenly fails to authorize. > > > > thanx, > > > > ente_______________________________________________gtk-list mailing > > listgtk-l...@gnome.org > > https://mail.gnome.org/mailman/listinfo/gtk-list > >
A brilliant idea! thanks, ente
_______________________________________________ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
