Re: gtk performance

2018-10-09 Thread ente
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  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 

Re: gtk performance

2018-10-08 Thread Andrea Giammarchi via gtk-list
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 = 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 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  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 

Re: gtk performance

2018-10-08 Thread Gergely Polonkai
Hello,

I don’t know about GtkListBox, but when using GtkTree, are you detaching
your model from the treeview while you are doing mass operations on it?

I remember reading it in a tutorial years (decades?) ago that you should
do this.

Sorry, but i have no answers at hand for your other questions.

Best,
Gergely

On Mon, Oct 08, 2018 at 12:24:03PM +0200, ente 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 

gtk performance

2018-10-08 Thread ente
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


Gtk performance

2008-06-11 Thread Gerardo Di Iorio
Hi,
i started to make an application in gtk.
I have find on the web why gtk is slow and require much memory!
Is true?

Thanks
Gerardo Di Iorio


___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list


Re: Gtk performance

2008-06-11 Thread Tor Lillqvist
 I have find on the web why gtk is slow and require much memory! Is true?

If you read it on the web, it must be true, yes.

--tml
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list


Re: Gtk performance

2008-06-11 Thread Gerardo Di Iorio


On Wed, 11 Jun 2008 17:37:46 +0200, G Hasse [EMAIL PROTECTED] wrote:
 On Wed, Jun 11, 2008 at 01:27:34PM +0200, Gerardo Di Iorio wrote:
 Hi,
 i started to make an application in gtk.
 I have find on the web why gtk is slow and require much memory!
 Is true?
 
 You must ask yourself - comparing to what?
 
 Java?
 QT?

comparing to  QT.


___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list


Re: Gtk performance

2008-06-11 Thread Gian Mario Tagliaretti
On Wed, Jun 11, 2008 at 6:30 PM, Gerardo Di Iorio
[EMAIL PROTECTED] wrote:

 You must ask yourself - comparing to what?

 Java?
 QT?

 comparing to  QT.

As Tor already pointed out, if you have read it on the web it _must_ be true.

cheers
-- 
Gian Mario Tagliaretti
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list


Re: Gtk performance

2008-06-11 Thread Martin (OPENGeoMap)

Gian Mario Tagliaretti escribió:


On Wed, Jun 11, 2008 at 6:30 PM, Gerardo Di Iorio
[EMAIL PROTECTED] wrote:

 


You must ask yourself - comparing to what?

Java?
QT?
 


comparing to  QT.
   



As Tor already pointed out, if you have read it on the web it _must_ be true.

cheers
 


http://www.wikivs.com/wiki/Qt_vs_GTK

--
Regards.
Martin

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list


Re: Gtk performance

2008-06-11 Thread Michael Torrie
Gerardo Di Iorio wrote:
 Hi,
 i started to make an application in gtk.
 I have find on the web why gtk is slow and require much memory!
 Is true?

Yes, no, maybe.

From my experience, speed is really divided into two things: perception
and throughput.  On the perception side of things, sometimes end users
perceive GTK as slow due to things like flicker during refresh, or
widgets that redraw too many times during a resize.  These are issues
that have been addressed and are being addressed.  Some of the
perception issues have a lot to do with the asynchronous nature of X11,
or due to the way GDK was implemented on windows (windows don't redraw
while being moved on windows xp, for example).  If the problem is X11,
then Qt will exhibit it also.  Things like double buffering and the new
X11 synchronization protocol help with flickering.

As for throughput, you'll need hard numbers to make any judgments there.
   And it all depends on what you are doing too.  From what I've seen,
GTK is probably faster and light than Qt.  Signal propagation is known
to be faster, and in general, GTK is pretty quick, at least as fast as
Qt.  I highly doubt GTK takes up much memory compared to Qt either.

Frankly there are lots of reasons to choose one toolkit over the other
but simply slow or much memory are not initially valid reasons.
Rather ease of development, the richness of the widgets, the ability to
rapidly generate good, usable interfaces, and other factors are much,
much more important to you as a developer.  Whether or not and end user
thinks your program is slow often depends on how badly you've set up the
interface!
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list


Re: GTK+ performance problem

2006-09-15 Thread James Henstridge
On 15/09/06, mikecorn [EMAIL PROTECTED] wrote:

  By redundant marks, I meant multiple marks at the same place, with the same
 name (or no name), and the same gravity.

  How about changing the create mark function to return the existing mark if
 the created mark would be the same?

A mark can be moved with gtk_text_buffer_move_mark(), so just because
two marks are at the same position in the text at one instant doesn't
mean they'll be at the same position later.

For example, there is a mark called insert that represents the
cursor where text the user types will be inserted.  When the cursor
position changes, so does the position of the mark.

If two bits of unrelated code were handed the same mark by
create_mark() and one piece of code moved the mark, you'd run into
weird bugs.

James.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list


GTK+ performance problem

2006-09-14 Thread mikecorn

I had a performance problem and found a work-around. 
I think the GTK gurus should know about this.

Scrolling output of text from a text view window got slower and slower as
the 
amount of text in the buffer increased.

Here is what I was doing after adding each line of text at the end of the
buffer:

  gtk_text_buffer_get_end_iter(textBuff,iter1);
  endMark = gtk_text_buffer_create_mark(textBuff,null,iter1,0);
  gtk_text_view_scroll_to_mark(GTK_TEXT_VIEW(textWin),endMark,0,0,1,1);

After a few thousand lines, the output speed was a tiny fraction of the
initial speed. 

I found an easy solution: save the endMark and avoid the call to
gtk_text_buffer_create_mark(...). 
Apparently this function is very slow if the text in the buffer is large
(like  100 KB).
(Is there a good reason for this?).

After this change, the output speed remains very fast (1000s of lines per
second), 
even if the buffer has megabytes of  text.

My GTK+ version is 2.8.20

-- 
View this message in context: 
http://www.nabble.com/GTK%2B-performance-problem-tf2265649.html#a6286930
Sent from the Gtk+ - Dev - General forum at Nabble.com.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: GTK+ performance problem

2006-09-14 Thread Owen Taylor
On Wed, 2006-09-13 at 07:41 -0700, mikecorn wrote:
 I had a performance problem and found a work-around. 
 I think the GTK gurus should know about this.
 
 Scrolling output of text from a text view window got slower and slower as
 the 
 amount of text in the buffer increased.
 
 Here is what I was doing after adding each line of text at the end of the
 buffer:
 
   gtk_text_buffer_get_end_iter(textBuff,iter1);
   endMark = gtk_text_buffer_create_mark(textBuff,null,iter1,0);
   gtk_text_view_scroll_to_mark(GTK_TEXT_VIEW(textWin),endMark,0,0,1,1);
 
 After a few thousand lines, the output speed was a tiny fraction of the
 initial speed. 
 
 I found an easy solution: save the endMark and avoid the call to
 gtk_text_buffer_create_mark(...). 
 Apparently this function is very slow if the text in the buffer is large
 (like  100 KB).
 (Is there a good reason for this?).
 
 After this change, the output speed remains very fast (1000s of lines per
 second), 
 even if the buffer has megabytes of  text.
 
 My GTK+ version is 2.8.20

The problem isn't, I think, that creating marks is slow for large
buffers, it's that having thousands and thousands of marks for the same
buffer is slow...

Why did you think that your original implementation wasn't a problem?
Sounds like some documentation somewhere needs to be fixed.

Owen


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: GTK+ performance problem

2006-09-14 Thread Owen Taylor
On Thu, 2006-09-14 at 16:44 +0200, mikecorn wrote:
 Owen,
 
 Thanks for your response. In answer to your question, I did what I
 thought the documentation said to do in order to scroll the window so
 that newly appended text came into view. You are right that I was
 creating thousands of marks, something I realize only now. After
 playing around with a small benchmark and reading the documentation
 more carefully, I realized the mark would move to the end of the
 inserted text and did not need to be created each time.

Which documentation? that documentation could be fixed.

 Perhaps the create mark function could be enhanced to detect and
 reject (or report) redundant marks? It seems that I had created
 thousands of unnamed redundant marks at the end of the text buffer. 

I'm not sure what would count as a a redundant mark.

- Owen

(The GtkTextView actually has an internal system where it will create
a temporary mark at an iter, scroll to it, and when the scrolling is
done, delete the iter. It would be really handy if there was some
scroll-to-iter variant that behaved in that manner.)



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: GTK+ performance problem

2006-09-14 Thread mikecorn




Owen,

Thanks for your response. In answer to your question, I did what I
thought the documentation said to do in order to scroll the window so
that newly appended text came into view. You are right that I was
creating thousands of marks, something I realize only now. After
playing around with a small benchmark and reading the documentation
more carefully, I realized the mark would move to the end of the
inserted text and did not need to be created each time.

Perhaps the create mark function could be enhanced to detect and reject
(or report) redundant marks? It seems that I had created thousands of
unnamed redundant marks at the end of the text buffer. 

thanks and regards,
Mike C.

Owen Taylor wrote:

  On Wed, 2006-09-13 at 07:41 -0700, mikecorn wrote:
  
  
I had a performance problem and found a work-around. 
I think the GTK gurus should know about this.

Scrolling output of text from a text view window got slower and slower as
the 
amount of text in the buffer increased.

Here is what I was doing after adding each line of text at the end of the
buffer:

  gtk_text_buffer_get_end_iter(textBuff,iter1);
  endMark = gtk_text_buffer_create_mark(textBuff,null,iter1,0);
  gtk_text_view_scroll_to_mark(GTK_TEXT_VIEW(textWin),endMark,0,0,1,1);

After a few thousand lines, the output speed was a tiny fraction of the
initial speed. 

I found an easy solution: save the endMark and avoid the call to
gtk_text_buffer_create_mark(...). 
Apparently this function is very slow if the text in the buffer is large
(like  100 KB).
(Is there a good reason for this?).

After this change, the output speed remains very fast (1000s of lines per
second), 
even if the buffer has megabytes of  text.

My GTK+ version is 2.8.20

  
  
The problem isn't, I think, that creating marks is slow for large
buffers, it's that having thousands and thousands of marks for the same
buffer is slow...

Why did you think that your original implementation wasn't a problem?
Sounds like some documentation somewhere needs to be fixed.

		Owen



  



___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: GTK+ performance problem

2006-09-14 Thread mikecorn




By redundant marks, I meant multiple marks at the same place, with the
same name (or no name), and the same gravity.

How about changing the create mark function to return the existing mark
if the created mark would be the same?

Here is the documentation I was using:
 
(http://developer.gnome.org/doc/API/2.0/gtk/GtkTextBuffer.html#gtk-text-buffer-create-mark)

gtk_text_buffer_create_mark ()

GtkTextMark* gtk_text_buffer_create_mark  (GtkTextBuffer *buffer,
 const gchar *mark_name,
 const GtkTextIter *where,
 gboolean left_gravity);

Creates a mark at position where. If mark_name is NULL, the mark is
anonymous; otherwise, the mark can be retrieved by name using
gtk_text_buffer_get_mark(). If a mark has left gravity, and text is
inserted at the mark's current location, the mark will be moved to the
left of the newly-inserted text. If the mark has right gravity
(left_gravity = FALSE), the mark will end up on the right of
newly-inserted text. The standard left-to-right cursor is a mark with
right gravity (when you type, the cursor stays on the right side of the
text you're typing).

The caller of this function does not own a reference to the returned
GtkTextMark, so you can ignore the return value if you like. Marks are
owned by the buffer and go away when the buffer does.

Emits the "mark_set" signal as notification of the mark's initial
placement.




Owen Taylor wrote:

  On Thu, 2006-09-14 at 16:44 +0200, mikecorn wrote:
  
  
Owen,

Thanks for your response. In answer to your question, I did what I
thought the documentation said to do in order to scroll the window so
that newly appended text came into view. You are right that I was
creating thousands of marks, something I realize only now. After
playing around with a small benchmark and reading the documentation
more carefully, I realized the mark would move to the end of the
inserted text and did not need to be created each time.

  
  
Which documentation? that documentation could be fixed.

  
  
Perhaps the create mark function could be enhanced to detect and
reject (or report) redundant marks? It seems that I had created
thousands of unnamed redundant marks at the end of the text buffer. 

  
  
I'm not sure what would count as a a redundant mark.

	- Owen

(The GtkTextView actually has an internal system where it will create
a temporary mark at an iter, scroll to it, and when the scrolling is
done, delete the iter. It would be really handy if there was some
scroll-to-iter variant that behaved in that manner.)

  



___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: GTK performance on Windows

2006-06-23 Thread Tor Lillqvist
Alex Nedelcu writes:

  Why is GTK's performance so bad on Windows ?

Because you haven't profiled it and contributed performance
improvements?

  Of all the gui tookits I use, it has the worse performance.

Well, d'oh, you should ask for your money back then!

--tml

___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list


Re: GTK performance on Windows

2006-06-23 Thread Hans Oesterholt-Dijkema
He must have been adding sleeps in his code.

Tor Lillqvist schreef:
 Alex Nedelcu writes:

   Why is GTK's performance so bad on Windows ?

 Because you haven't profiled it and contributed performance
 improvements?

   Of all the gui tookits I use, it has the worse performance.

 Well, d'oh, you should ask for your money back then!

 --tml

 ___
 gtk-list mailing list
 gtk-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/gtk-list


   

___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list


GTK performance on Windows

2006-06-22 Thread Alex Nedelcu
Why is GTK's performance so bad on Windows ?
Of all the gui tookits I use, it has the worse performance.

I am interested in GTK on Windows because I want to make cross-platform 
applications.

Isn't there a new version on the horizon that will fix this ?
Or what can be done to tune the performance of GTK interfaces ?

I am using GTK+ version 2.8, and Windows XP.
The platform I use is Mono with the GTK# bindings,
but I also made tests in Python with the PyGTK.bindings, and I've got 
the same results.


Thank you,

___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list


Re: GTK performance on Windows

2006-06-22 Thread Daniel Kasak
Alex Nedelcu wrote:

 Why is GTK's performance so bad on Windows ?
 Of all the gui tookits I use, it has the worse performance.

 I am interested in GTK on Windows because I want to make cross-platform 
 applications.

 Isn't there a new version on the horizon that will fix this ?
 Or what can be done to tune the performance of GTK interfaces ?

 I am using GTK+ version 2.8, and Windows XP.
 The platform I use is Mono with the GTK# bindings,
 but I also made tests in Python with the PyGTK.bindings, and I've got 
 the same results.
   

I don't think it's so bad. I'm developing gtk2-perl applications and
deploying on a mix of Linux and Windows ( 2000 ) clients, and the
performance is actually quite impressive. It even runs inside vmware on
my Linux desktop quite well, though obviously not at full speed.

As per previous posts re: performance problems, have you tried changing
themes?

Also, what exactly is slow?

-- 
Daniel Kasak
IT Developer
NUS Consulting Group
Level 5, 77 Pacific Highway
North Sydney, NSW, Australia 2060
T: (+61) 2 9922-7676 / F: (+61) 2 9922 7989
email: [EMAIL PROTECTED]
website: http://www.nusconsulting.com.au
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list


GTK Performance on Athlon

2006-06-21 Thread Michael Kahn








A few months ago, I bought an HP Athlon PC and installed
SuSE 9.2. The system clock took off at warp speed (about three times
normal speed). When I emailed SuSE, they told me that the BIOS does not
provide a solid real-time clock interrupt. (One side-effect of the warp
speed system clock was I could not double click on anything.)
They felt that they may have a fix for this problem in SUSE 10.0. It may
be that the Athlon clock fix in SUSE 10.0 is what is hindering your GTK
performance. I really hope this isnt your problem.



BTW  I have since returned to using my old 1.7 GHz PC
(assembled myself) to run Linux. I wont be taking any chances on
the Athlon in the future; thats just too much money to spend on a
machine that doesnt play nicely with my preferred flavor of Linux.



 Michael Kahn








___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list


Re: GTK Performance on Athlon

2006-06-21 Thread Valdis . Kletnieks
On Wed, 21 Jun 2006 10:45:33 EDT, Paul Davis said:
 On Wed, 2006-06-21 at 09:21 -0500, Michael Kahn wrote:
  A few months ago, I bought an HP Athlon PC and installed SuSE 9.2.
  The system clock took off at warp speed (about three times normal
  speed).  When I emailed SuSE, they told me that the BIOS does not
  provide a solid real-time clock interrupt.  (One side-effect of the
  warp speed system clock was I could not “double click” on anything.)
  They felt that they may have a fix for this problem in SUSE 10.0.  It
  may be that the Athlon clock fix in SUSE 10.0 is what is hindering
  your GTK performance.  I really hope this isn’t your problem.
 
 it sounds quite likely that you have been the victim of some slightly
 uninformed customer support. was this a dual core Athlon?

No, the turbo clock ticks problem is a very real issue on certain Athlon
motherboards.  There's been several long threads about it on the linux-kernel
mailing list, and I believe it's fixed in 2.6.16 or 2.6.17 or so (although
I'd have to go back and check, I wasn't paying much attention because I don't
have an Athlon).  SUSE may well have backported the fix into whatever kernel
they're shipping with 10.0.

And a screaming clock *can* bork double-clicks - imagine where you need to get
in 2 clicks in under 250 milliseconds, but the system ticks off what it thinks
is 250ms in only 75ms.  And your mouse won't double-click faster than 80ms. ;)


pgpz5N7hZ1bib.pgp
Description: PGP signature
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list


Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]

2005-08-21 Thread Jeroen Zwartepoorte
Since everybody is talking about how glitz will eventually speedup
drawing operations by using hardware accelerated OpenGL, i built it
and then rebuilt cairo so cairo will detect glitz and compile with
support for it.

How does glitz further integrate into the desktop stack? Can i make
gtk+ use glitz for drawing widgets? If so, how?

Regards,

Jeroen

On 6/10/05, Owen Taylor [EMAIL PROTECTED] wrote:
 On Thu, 2005-06-09 at 10:49 -0400, Luis Villa wrote:
  On 6/9/05, Luis Villa [EMAIL PROTECTED] wrote:
 
  Went ahead and did it myself. TextView is brutally slower (300-400%),
  some other things are 25-30% slower, and some things actually get
  faster. Disclaimer: I'm pretty sure I did this right and I'm linking
  against the right stuff, but these numbers should be confirmed by an
  expert, and I can't speak to the validity of the tool's measurements
  itself, except to note that scrolling in a textview area is *visibly*
  slower.
 
  The data:
 
  first 'column' of times is gtk 2.6, second is gtk/cairo HEAD of
  yesterday, both with the Mist theme:
 
 With the Mist theme, you are testing mixed Cairo and GDK rendering.
 Right now, that could conceivably hide some performance problems with
 Cairo. In the future, there are some performance optimizations that will
 be disabled when you are mixing Cairo and GDK rendering.
 
 The GTK+ builtin theme probably gives more of an accurate feel for
 GTK+/Cairo performance.
 
 What the appropriate theme to test is does depend on what we will
 be shipping for GNOME-2.10 as the default, of course. Which is likely
 not the GTK+ builtin theme.
 
  GtkEntry - time:  0.43 0.76
  GtkComboBox - time: 12.61 15.30
  GtkComboBoxEntry - time: 11.95 13.25
  GtkSpinButton - time:  0.65 1.09
  GtkProgressBar - time:  0.53 0.87
  GtkToggleButton - time:  2.17 4.42
  GtkCheckButton - time:  3.41 3.27
  GtkRadioButton - time:  4.29 3.96
  GtkTextView - Add text - time: 91.88 268.67
  GtkTextView - Scroll - time: 43.17 190.83
  GtkDrawingArea - Lines - time:  8.40 8.48
  GtkDrawingArea - Circles - time: 13.38 13.58
  GtkDrawingArea - Text - time: 48.70 29.99
  GtkDrawingArea - Pixbufs - time: 11.71 11.46
 
 Without studying what these benchmarks are actually doing, I'd consider
 them pretty encouraging ... some operations got faster, and what
 got slower is something we have in our sights already ...
 cairo_scaled_font_glyph_extents(). (GtkTextView performance is
 text measuring performance.)
 
 There is an obvious big-hammer approach that would allow us to get rid
 of that ... to put a cache in front of it so that we avoid calling
 into Cairo entirely, but I'd like to see what we can do inside of
 Cairo first.
 
 Regards,
 Owen
 
 
 
 BodyID:12373415.2.n.logpart (stored separately)
 
 ___
 desktop-devel-list mailing list
 [EMAIL PROTECTED]
 http://mail.gnome.org/mailman/listinfo/desktop-devel-list
 

___
gtk-devel-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]

2005-08-21 Thread Billy Biggs
Rob Taylor ([EMAIL PROTECTED]):

 You'll have to excude me for not having followed much cairo/X work for
 a while, but does that ' --- RENDER ---' imply that cairo is
 rendering lots of traps using the RENDER extension?

  Yes.  When you draw a line or a curve using cairo, it is decomposed
into trapezoids which are rendered by RENDER.

  -Billy
___
gtk-devel-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]

2005-08-21 Thread Clemens Eisserer
 When you draw a line or a curve using cairo, it is decomposed
 into trapezoids which are rendered by RENDER.

Sorry if this question is quite naive, but I wonder why cairo seems to
generate such a large amount of overhead at all - why can't simple
operations like fills and blits which are the most used  not be
executed just like it was before switching to cairo just using plain
x?

I do not mean using cairo+x but furthermore let cairo do stuff that
can be done using x-core do by x-core and not create trapezoids out of
every curve?
Seems I don't get something...

lg Clemens
___
gtk-devel-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]

2005-08-21 Thread Billy Biggs
Clemens Eisserer ([EMAIL PROTECTED]):

  When you draw a line or a curve using cairo, it is decomposed into
  trapezoids which are rendered by RENDER.
 
 Sorry if this question is quite naive, but I wonder why cairo seems to
 generate such a large amount of overhead at all - why can't simple
 operations like fills and blits which are the most used  not be
 executed just like it was before switching to cairo just using plain
 x?

  This is already being done in the Cairo code for certain operations
where possible.  Do you have a case where cairo is generating a large
amount of overhead?

 I do not mean using cairo+x but furthermore let cairo do stuff that
 can be done using x-core do by x-core and not create trapezoids out of
 every curve?
 Seems I don't get something...

  What application are you using that draws a lot of curves?  Core X
doesn't do antialiased curves.

  -Billy

___
gtk-devel-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: GtkPerf [was: gtk performance testing]

2005-07-20 Thread Zeeshan Ali
Hello,

 So, I still understand that benchmarking tools such as this only suit to some
 high-level testing and collecting numbers in specific environments. But I 
 would
 like to get some insider information from you how GtkPerf could better test 
 the
 speed user experiences with GTK+ applications? And also offer my 
 (work-limited)
 help on tuning GtkPerf in the direction which could help more the actual GTK+
 development. Any ideas?

   Recently I tried GtkPerf but then didn't use it for my performance
analysis because of two reasons:

1. GtkPerf wasn't generic enough: I couldn't just tell it a name of
any widget and tell it to analyze it for me
2. I wanted/needed a programmer's tool (e.g a library) 

   So instead of using GtkPerf, i wrote my own testing code based on
Owen's suggestions and used that instead. I haven't librarified it
(yet) and you can have a look at it here if you want to:
http://piipiip.net/~zeenix/widget-perf-test.c

-- 
Regards,

Zeeshan Ali
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list


GtkPerf [was: gtk performance testing]

2005-07-19 Thread Kaj Grönholm
Hello all,

I'm the developer of GtkPerf (http://gtkperf.sf.net) and just realized (thanks
Clemens!) that you guys have been talking about GTK+ performance few weeks ago
and used also GtkPerf!

So, I still understand that benchmarking tools such as this only suit to some
high-level testing and collecting numbers in specific environments. But I would
like to get some insider information from you how GtkPerf could better test the
speed user experiences with GTK+ applications? And also offer my (work-limited)
help on tuning GtkPerf in the direction which could help more the actual GTK+
development. Any ideas?


- Kaitsu -

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]

2005-06-15 Thread Owen Taylor
On Wed, 2005-06-15 at 11:16 +0100, Rob Taylor wrote:
 On Fri, 2005-06-10 at 09:33 -0400, Owen Taylor wrote:
  On Fri, 2005-06-10 at 15:12 +0200, Jeroen Zwartepoorte wrote:
   Since everybody is talking about how glitz will eventually speedup
   drawing operations by using hardware accelerated OpenGL, i built it
   and then rebuilt cairo so cairo will detect glitz and compile with
   support for it.
   
   How does glitz further integrate into the desktop stack? Can i make
   gtk+ use glitz for drawing widgets? If so, how?
  
  The way glitz integrates in is on the server side:
  
   GTK+ = Cairo --- RENDER --- X server = glitz = OpenGL
  
  This will give the same basic performance benefits as having Cairo
  use glitz directly, but with many less complications. Currently,
  we don't foresee having GTK+ render via glitz as a very interesting
  way to go for the desktop.
  
  Note that the performance slowdowns people have been seeing for
  GtkTextView likely have not much to do with rendering and everything
  to do with text measurement.
 
 You'll have to excude me for not having followed much cairo/X work for a
 while, but does that ' --- RENDER ---' imply that cairo is rendering
 lots of traps using the RENDER extension?

Yes.
Owen



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]

2005-06-10 Thread Luis Villa
On 6/9/05, Luis Villa [EMAIL PROTECTED] wrote:
 On 6/9/05, Luis Villa [EMAIL PROTECTED] wrote:
  On 6/9/05, Jon K Hellan [EMAIL PROTECTED] wrote:
   On Thu, 2005-06-09 at 14:39 +0100, Mark McLoughlin wrote:
  If we're talking about performance/stability in the context of 
whether
GNOME 2.12 should use GTK+ 2.8, we're effectively saying I think the
GTK+ team might ship a unstable or unacceptably slow 2.8.0 release;
GNOME shouldn't commit to using GTK+ 2.8 yet. I would hope that we
would have more confidence in the judgement of the GTK+ team than that.
  
   Crashes and performance are very different types of problem. Crashes get
   fixed once they can be reproduced. Fixing bad performance can take a
   long time.
  
   Well, I haven't tested gtk2.7 since just after Cairo got added, so I
   can't tell whether there is a performance problem. Has anybody got
   numbers?
 
  I haven't seen this announced on gtk-devel or here, so:
 
  http://gtkperf.sourceforge.net/
 
  Apparently this is a test tool to test gtk performance. Would be great
  to have someone test 2.7 with it.
 
 Went ahead and did it myself. TextView is brutally slower (300-400%),
 some other things are 25-30% slower, and some things actually get
 faster. Disclaimer: I'm pretty sure I did this right and I'm linking
 against the right stuff, but these numbers should be confirmed by an
 expert, and I can't speak to the validity of the tool's measurements
 itself, except to note that scrolling in a textview area is *visibly*
 slower.

New third column is HEAD + glitz, with an x31's ATI card. Still with
Mist. Performance is slightly slower than HEAD just about everywhere,
actually. I'll probably do an N=100 run with default theme +
2.6/HEAD/HEAD + glitz sometime later. Have to figure out how to
automate this. :)
 
The data:
 
GtkEntry - time:  0.43 0.76 0.89
GtkComboBox - time: 12.61 15.30 15.11
GtkComboBoxEntry - time: 11.95 13.25 13.36
GtkSpinButton - time:  0.65 1.09 1.17 
GtkProgressBar - time:  0.53 0.87 0.99
GtkToggleButton - time:  2.17 4.42 4.47
GtkCheckButton - time:  3.41 3.27 3.37
GtkRadioButton - time:  4.29 3.96 4.10
GtkTextView - Add text - time: 91.88 268.67 311.53
GtkTextView - Scroll - time: 43.17 190.83 229.29
GtkDrawingArea - Lines - time:  8.40 8.48 8.39
GtkDrawingArea - Circles - time: 13.38 13.58 13.42
GtkDrawingArea - Text - time: 48.70 29.99 30.34
GtkDrawingArea - Pixbufs - time: 11.71 11.46 11.16
 ---
Total time: 253.31 565.94 647.60
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]

2005-06-10 Thread Alexander Larsson
On Fri, 2005-06-10 at 09:40 -0400, Luis Villa wrote:
 On 6/10/05, Luis Villa [EMAIL PROTECTED] wrote:
I haven't seen this announced on gtk-devel or here, so:
   
http://gtkperf.sourceforge.net/
   
Apparently this is a test tool to test gtk performance. Would be great
to have someone test 2.7 with it.
  
   Went ahead and did it myself. TextView is brutally slower (300-400%),
   some other things are 25-30% slower, and some things actually get
   faster. Disclaimer: I'm pretty sure I did this right and I'm linking
   against the right stuff, but these numbers should be confirmed by an
   expert, and I can't speak to the validity of the tool's measurements
   itself, except to note that scrolling in a textview area is *visibly*
   slower.
  
  New third column is HEAD + glitz, with an x31's ATI card. 
 
 Someone larted me on IRC and informed me that it is likely that glitz
 wasn't actually being used. So take these with an even bigger grain of
 salt than my last set. I would love to know how one can (1) know for
 certain glitz is being used and/or (2) how to force glitz to be used
 so that I can do a quickie hack to automate this.

  Total time: 253.31 565.94 647.60

The question is: Why did you get different times then?

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander LarssonRed Hat, Inc 
   [EMAIL PROTECTED][EMAIL PROTECTED] 
He's a fiendish umbrella-wielding househusband from the 'hood. She's a 
cold-hearted gypsy mechanic with the soul of a mighty warrior. They fight 
crime! 

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]

2005-06-10 Thread Owen Taylor
On Fri, 2005-06-10 at 15:12 +0200, Jeroen Zwartepoorte wrote:
 Since everybody is talking about how glitz will eventually speedup
 drawing operations by using hardware accelerated OpenGL, i built it
 and then rebuilt cairo so cairo will detect glitz and compile with
 support for it.
 
 How does glitz further integrate into the desktop stack? Can i make
 gtk+ use glitz for drawing widgets? If so, how?

The way glitz integrates in is on the server side:

 GTK+ = Cairo --- RENDER --- X server = glitz = OpenGL

This will give the same basic performance benefits as having Cairo
use glitz directly, but with many less complications. Currently,
we don't foresee having GTK+ render via glitz as a very interesting
way to go for the desktop.

Note that the performance slowdowns people have been seeing for
GtkTextView likely have not much to do with rendering and everything
to do with text measurement.

Regards,
Owen



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]

2005-06-10 Thread Owen Taylor
On Fri, 2005-06-10 at 09:47 -0400, Luis Villa wrote:
 On 6/10/05, Alexander Larsson [EMAIL PROTECTED] wrote:
  On Fri, 2005-06-10 at 09:40 -0400, Luis Villa wrote:
   On 6/10/05, Luis Villa [EMAIL PROTECTED] wrote:
  I haven't seen this announced on gtk-devel or here, so:
 
  http://gtkperf.sourceforge.net/
 
  Apparently this is a test tool to test gtk performance. Would be 
  great
  to have someone test 2.7 with it.

 Went ahead and did it myself. TextView is brutally slower (300-400%),
 some other things are 25-30% slower, and some things actually get
 faster. Disclaimer: I'm pretty sure I did this right and I'm linking
 against the right stuff, but these numbers should be confirmed by an
 expert, and I can't speak to the validity of the tool's measurements
 itself, except to note that scrolling in a textview area is *visibly*
 slower.
   
New third column is HEAD + glitz, with an x31's ATI card.
  
   Someone larted me on IRC and informed me that it is likely that glitz
   wasn't actually being used. So take these with an even bigger grain of
   salt than my last set. I would love to know how one can (1) know for
   certain glitz is being used and/or (2) how to force glitz to be used
   so that I can do a quickie hack to automate this.
  
Total time: 253.31 565.94 647.60
  
  The question is: Why did you get different times then?
 
 Very good question. I tried to kill anything particularly
 CPU-consuming, and in all cases stopped using the machine during the
 test, so I don't *think* that is a factor, but it could have been-
 it's not like I was running this on a perfectly-controlled test box.
 (Which I'd like to do, as part of the tinderboxing, whenever someone
 gets me a box to tinder on  :)

I suspect that it's just difficulties in the benchmark ... especially 
with GtkTextView, things can happen a little differently each time you
run it ... a different balance between repainting the screen and 
updating the text. Everything other than GtkTextView looked the same
up to noise, but the GtkTextView numbers dominate the total.

Regards,
Owen



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]

2005-06-09 Thread Luis Villa
On 6/9/05, Luis Villa [EMAIL PROTECTED] wrote:
 On 6/9/05, Jon K Hellan [EMAIL PROTECTED] wrote:
  On Thu, 2005-06-09 at 14:39 +0100, Mark McLoughlin wrote:
 If we're talking about performance/stability in the context of 
   whether
   GNOME 2.12 should use GTK+ 2.8, we're effectively saying I think the
   GTK+ team might ship a unstable or unacceptably slow 2.8.0 release;
   GNOME shouldn't commit to using GTK+ 2.8 yet. I would hope that we
   would have more confidence in the judgement of the GTK+ team than that.
 
  Crashes and performance are very different types of problem. Crashes get
  fixed once they can be reproduced. Fixing bad performance can take a
  long time.
 
  Well, I haven't tested gtk2.7 since just after Cairo got added, so I
  can't tell whether there is a performance problem. Has anybody got
  numbers?
 
 I haven't seen this announced on gtk-devel or here, so:
 
 http://gtkperf.sourceforge.net/
 
 Apparently this is a test tool to test gtk performance. Would be great
 to have someone test 2.7 with it.

Went ahead and did it myself. TextView is brutally slower (300-400%),
some other things are 25-30% slower, and some things actually get
faster. Disclaimer: I'm pretty sure I did this right and I'm linking
against the right stuff, but these numbers should be confirmed by an
expert, and I can't speak to the validity of the tool's measurements
itself, except to note that scrolling in a textview area is *visibly*
slower.

The data: 

first 'column' of times is gtk 2.6, second is gtk/cairo HEAD of
yesterday, both with the Mist theme:

GtkEntry - time:  0.43 0.76
GtkComboBox - time: 12.61 15.30
GtkComboBoxEntry - time: 11.95 13.25
GtkSpinButton - time:  0.65 1.09
GtkProgressBar - time:  0.53 0.87
GtkToggleButton - time:  2.17 4.42
GtkCheckButton - time:  3.41 3.27
GtkRadioButton - time:  4.29 3.96
GtkTextView - Add text - time: 91.88 268.67
GtkTextView - Scroll - time: 43.17 190.83
GtkDrawingArea - Lines - time:  8.40 8.48
GtkDrawingArea - Circles - time: 13.38 13.58
GtkDrawingArea - Text - time: 48.70 29.99
GtkDrawingArea - Pixbufs - time: 11.71 11.46
 --- 
Total time: 253.31 565.94

HTH-
Luis
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]

2005-06-09 Thread Luis Villa
On 6/9/05, Jon K Hellan [EMAIL PROTECTED] wrote:
 On Thu, 2005-06-09 at 10:49 -0400, Luis Villa wrote:
  first 'column' of times is gtk 2.6, second is gtk/cairo HEAD of
  yesterday, both with the Mist theme:
 
  GtkEntry - time:  0.43 0.76
  GtkComboBox - time: 12.61 15.30
  GtkComboBoxEntry - time: 11.95 13.25
  GtkSpinButton - time:  0.65 1.09
  GtkProgressBar - time:  0.53 0.87
  GtkToggleButton - time:  2.17 4.42
  GtkCheckButton - time:  3.41 3.27
  GtkRadioButton - time:  4.29 3.96
  GtkTextView - Add text - time: 91.88 268.67
  GtkTextView - Scroll - time: 43.17 190.83
  GtkDrawingArea - Lines - time:  8.40 8.48
  GtkDrawingArea - Circles - time: 13.38 13.58
  GtkDrawingArea - Text - time: 48.70 29.99
  GtkDrawingArea - Pixbufs - time: 11.71 11.46
   ---
  Total time: 253.31 565.94
 

I should have mentioned that this was with N=1000; jkh, I'm assuming
you did the default n=100?
 
 Here are my numbers. The tendency is the same. I'm comparing the head of
 the 2.6 branch in cvs with HEAD. Both locally compiled with the same
 jhbuild setup. Default theme.
 
 Gtk branch   2.6   HEAD
 
  time  time
 GtkEntry 0.04  0.07
 GtkComboBox  1.11  1.51
 GtkComboBoxEntry 0.99  1.17
 GtkSpinButton0.07  0.11
 GtkProgressBar   0.04  0.09
 GtkToggleButton  0.21  0.41
 GtkCheckButton   0.34  0.44
 GtkRadioButton   0.41  0.65
 GtkTextView - Add text   1.62  2.82
 GtkTextView - Scroll 0.34  1.39
 GtkDrawingArea - Lines   0.54  0.49
 GtkDrawingArea - Circles 1.22  1.08
 GtkDrawingArea - Text3.98  5.05
 GtkDrawingArea - Pixbufs 1.23  1.00
  --- ---
 Total time: 12.16 16.27
 
 
 ___
 gtk-devel-list mailing list
 gtk-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/gtk-devel-list

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: Win32 gtk performance sucks (all versions), any suggestions for finding the bottlenecks?

2005-03-25 Thread Hubert Sokołowski

Hi!

On Fri, 25 Mar 2005 20:44:16 -0800 (PST)
Dave Andruczyk [EMAIL PROTECTED] wrote:

 
 I have seen my app run about 10-50x slower on win32 and doing simple
 things
 like changing a widgets color or text can max the CPU EASILY on a 1Ghz
 Win2k
 install.  on linux the cpu penalty is usually less than 10% in most
 cases..
 
 I've tested this with the GTK+ runtime builds from gladewin32.sf.net
 (tried
 2.4.11, 2.4.13 and 2.4.14)
I also notice very low performance of gtk on windows. my program draws
lines and points and on linux it takes max 8% of CPU but on windows on
the same machine it takes 100% CPU and it flicks. 

I don't know how to cope with it. You could also try gtk 2.6 from Tor's
site. I use this switches when compiling my app
FLAGS = -Wall -O2 -ffast-math -fomit-frame-pointer
-fexpensive-optimizations -fstrength-reduce -mno-cygwin -mcpu=pentium
-mms-bitfields -mwindows

regards
hs
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list