bugFreeciv - Bugs: bug #21314, Gtk3 client is very sluggish on...

 
 
Show feedback again

bug #21314: Gtk3 client is very sluggish on Windows

Submitted by:  Jacob Nevins <jtn>
Submitted on:  Sat Nov 30 12:35:35 2013  
 
Category: client-gtk-3.0Severity: 4 - Important
Priority: 5 - NormalStatus: Duplicate
Assigned to: NoneOpen/Closed: Closed
Release: 2.4.0+Operating System: Microsoft Windows
Planned Release: 2.5.0,2.6.0Contains string changes: None

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Tue Dec 22 14:20:23 2015, comment #14:

I checked again, that effect is not visible at linux at all.

mir3x <mir3x>
Project Member
Tue Dec 22 14:08:49 2015, comment #13:

I checked few days ago both gtk2 and gtk3 and it seems they
had the same speed.

But recentering map with sliding(animation) disabled takes almost 1 sec on my cpu - but on both clients (qt somehow does it instant).
It's slighty visible on linux.

I checked fps counter in set_mapview_origin() in mapview_common with sliding on linux and gtk3 was faster than qt 2-3x times, and a bit faster than gtk2.

So maybe there is also some bug with recentering map when animation is disabled in both gtk clients.

mir3x <mir3x>
Project Member
Sun Nov 8 19:41:57 2015, comment #12:

So it seems that main-map drawable is no more, but the only canvas that gets drawable assigned is the overview:

> grep -r "drawable" client/gui-gtk-3.0/

...
store.drawable = gdk_cairo_create(gtk_widget_get_window(overview_canvas));
...

Marko Lindqvist <cazfi>
Project Administrator
Sun Nov 8 19:28:43 2015, comment #11:

"Have you any statistics how often that slow path (not having re-usable drawable) is taken compared to the fast path?"

I checked for functions:

canvas_put_rectangle
canvas_put_sprite
canvas_copy

and (!pcanvas->drawable) was always true

and overall those function were executed about 18 000 times in first 3 seconds.

mir3x <mir3x>
Project Member
Sun Nov 8 19:16:59 2015, comment #10:

I was wrong:
cr = cairo_create(pcanvas->surface)
doesn't create new pixmap, just references it.

mir3x <mir3x>
Project Member
Sun Nov 8 19:02:32 2015, comment #9:

Have you any statistics how often that slow path (not having re-usable drawable) is taken compared to the fast path?

Marko Lindqvist <cazfi>
Project Administrator
Sun Nov 8 18:55:22 2015, comment #8:

Depening on cpu - gtk3 is still quite slugish. Just move around map with right click and you might spot some lags ( on linux also ).

I think I maybe found why:

In each canvas function u see:

if (!pcanvas->drawable) {
/* thats always true probably*/
cr = cairo_create(pcanvas->surface);
} else {
/* thats always false probably */
cr = pcanvas->drawable;
}

and in end of each canvas_XXX function
if (!pcanvas->drawable) {
cairo_destroy(cr);
/* always true I guess */
} else {
cairo_restore(cr);
}

so at each canvas operation, there is created and deleted extra pixmap, and I think there are hundreds of those pixmaps per second.

Haven't fully investigated it, but it has to make client so slow.

mir3x <mir3x>
Project Member
Sun Sep 14 10:11:57 2014, comment #7:

I tried 2.4.3 and 2.5.0-beta1 Gtk3 builds on Windows recently, and they were no longer sluggish.

I have admittedly upgraded my graphics card in the meantime, but I doubt that makes the difference.

I haven't checked that the old builds are still sluggish on my current system. Since we've made changes that are expected to speed things up recently (patch #4590, bug #21726), I'm going to declare this fixed unless more evidence turns up.

Jacob Nevins <jtn>
Project Administrator
Fri Jul 4 09:28:31 2014, comment #6:

...or bug #21726?

Jacob Nevins <jtn>
Project Administrator
Tue Mar 11 21:44:40 2014, comment #5:

Perhaps we might hope for patch #4590 to have improved matters?

Jacob Nevins <jtn>
Project Administrator
Sun Jan 5 15:34:16 2014, comment #4:

Another data point: cproc uploaded a 2.4.1 Gtk3 build to the 'testing' area. It's just as sluggish as the previous between-releases build. (Probably no surprise, since it has the same versions of all the DLLs.)

(Forgot to test whether sound made a difference.)

Jacob Nevins <jtn>
Project Administrator
Thu Dec 5 00:03:34 2013, comment #3:

> although there were occasional long pauses in both


Did you have sounds enabled? I've got reports that such pauses started appearing when user switched from dummy sound plugin to real one.

> based on Windows resource version information in DLLs, unless
> otherwise stated


FYI there's table of crosser component versions at http://www.cazfi.net/crosser/

> SDL.dll 1.2.14.0 1.2.14.0


In case of clients other than SDL, SDL library is not used for gfx, but only initialized for use of SDL_mixer.

Marko Lindqvist <cazfi>
Project Administrator
Wed Dec 4 23:49:34 2013, comment #2:

> Could you test with crosser-based builds to see if there's
> equivalent difference between gtk2- and gtk3-clients there?

Good thought. There isn't; in the S2_5 crosser build I tried, Gtk2 and Gtk3 are equivalently responsive (although there were occasional long pauses in both), and about as responsive as cproc's Gtk2 client.

This is with freeciv-win32-2.4.99-alpha-r23559.zip, crosser-0.11.1.

Comparing versions of vaguely-graphics-related libraries used by freeciv-gtk3.exe (based on Windows resource version information in DLLs, unless otherwise stated):

Jacob Nevins <jtn>
Project Administrator
Wed Dec 4 01:13:21 2013, comment #1:

Could you test with crosser-based builds to see if there's equivalent difference between gtk2- and gtk3-clients there? I don't have S2_4 builds available any more, as it's already release branch with official installer builds, but build from S2_5 or TRUNK should be ok for testing this.

http://www.cazfi.net/freeciv/builds/win.html

Latest builds are made with crosser-0.11 which has gtk2-2.24.19 and gtk3-3.6.4 (crosser-0.12 should be released any day now)

Marko Lindqvist <cazfi>
Project Administrator
Sat Nov 30 12:35:35 2013, original submission:

As noted in task #7681, on my Windows 7 32-bit installation at least, the first experimental Gtk3 installer that cproc built is incredibly sluggish for some reason, and eats lots of CPU (much more than the Gtk2 client, or Gtk3 on the same machine under Linux).

Don't know how we can progress this; creating ticket to gather more data / ideas.
Marking as blocker for 2.5.0 since IMO this blocks Gtk3 as default client. (Of course if we find an easy fix in Freeciv we'll probably backport it to 2.4.0 as well.)

(Is it possible that the Windows Gtk3 Cairo implementation is not well optimised, or something?)

Jacob Nevins <jtn>
Project Administrator

 

(Note: upload size limit is set to 1024 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Digest:
   task dependencies.

 

Carbon-Copy List
  • -unavailable- added by mir3x (Posted a comment)
  • -unavailable- added by cazfi (Posted a comment)
  • -unavailable- added by jtn (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Error: not logged in

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun Sep 14 10:11:57 2014jtnStatusNeed Info=>Duplicate
      Open/ClosedOpen=>Closed
    Fri Jul 4 09:27:10 2014jtnSeverity5 - Blocker=>4 - Important
    Show feedback again

    Back to the top


    Powered by Savane 3.1-cleanup