Re: gtk performance

[ente <ente ck76 de>]

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 WebView

through title notifications:

https://gist.github.com/WebReflection/7ab0addec037508cc8380a9c37d285f2#gistcomment-2245132

The nitty-gritty is that you change your title from the page

```js

document.title = `${SECRET}:js=${JSON.stringify(data)}`;

```

and you intercept it from GJS side

```js

webView.connect('notify::title', (self, params) => {

  if (`${SECRET}`:js=/.test(self.title)) {

    const data = "" + 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 send

eventually data back. The SECRET can be any channel, for circular data just

use one of the many circular JSON parsers/stringifiers (i.e. flatted or

CircularJSON)

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'm

scaling 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 bar

which is **not** the native one or performance will be super bad regardless.

On Mon, Oct 8, 2018 at 12:44 PM ente <

ente ck76 de

> wrote:

Hi,

I am facing performance issues in GTK upon presenting a big amount of

tabular data. First I used GtkListbox for it's layout flexibility. Handling

more than 10,000 items gets inacceptable slow. Switching to GtkTreeview I

can handle some 300,000 items after applying a few optimizations (column

sizing 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 (that

feels awkward to say) or implementing paging on the GtkTreeview.

At this moment I am analyzing the reasons for the performance issues. I

measured 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 1m18s

After the loop I pack the GtkBox into a window and show it. That takes

another century to show up.

If I adjust the loop to skip the packing of the labels into the box, the

times 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 the

GtkTreeview it seems speficially to boil down to the sizing and signalling

of the items: The performance of the treeview was highly impacted by the

fixed height mode & the fixed column sizing (more than ordering by a column

or calling GtkMain while adding rows). So my question goes down to: How can

I further optimize my way of using GTK in order to speed up UI? Is there

any way to add 1,000,000 labels to a GtkBox in less than a second? Could I

somehow suspend the signalling during UI creation and replace it by a "I am

done, now calculate all the sizes" signal? Am I wrong about my assumption

that the sizing signalling is the cause for the low performance?

With regards to the treeview: After initially creating the data rows I am

calculating values that affect 4 columns out of 10 columns. So far I

determine the GtkTreeIter of the affected row and update all cells in that

row using gtk_list_store_set. Should I adjust to update the affected

columns only? When I implement paging for the TreeView: should I rather

drop the existing ListStore and create a new or is it faster to overwrite

all 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 (I

didn't keep the measurements).

I could isolate the problem to UI rendering. If I don't assign my

ListStore 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 _javascript_

world using the Webkit2Gtk webview? More specificly: I am working in go

language. 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 the

DOM back to go?

Background on the application:

I am developing a text analysis application. Text fragments get

precalculated attributes assigned. Based on these attributes and the

Levensthein distance between fragments, someone is supposed to (for now:

manually) define text fragment categories (categories). Roughly speaking

the application has a paned window: on the left I show the category list or

an editor for a new / existing category; on the right I show a list of text

fragments with the major 3 attributes or a details view on a specific

fragment: all attributes and a list of similar fragments.

The smallest amount of text fragments to be analyzed and categorized is

about 300,000 items. The number of items goes easily up to 5,000,000 or

even much more. Categorizing all fragments requires about 100 to at maximum

1,000 categories, i.e. there is quite some clustering among those text

fragments. On the interface I work with highlight colors: a human can

easily realize which fragements are already clustered and which aren't.

Usually only a small number of text fragment categories are of special

interest. One could compare it to a log file: I don't care so much about

how often someone sucessfully authorized; it is much more interesting if

someone suddenly fails to authorize.

thanx,

ente

_______________________________________________

gtk-list mailing list

gtk-list gnome org

https://mail.gnome.org/mailman/listinfo/gtk-list

A brilliant idea!

thanks,

ente