[ wxwindows-Bugs-1786972 ] Slow Painting
SourceForge.net
noreply at sourceforge.net
Wed Sep 5 04:31:42 PDT 2007
Bugs item #1786972, was opened at 2007-09-03 09:31
Message generated for change (Comment added) made by roebling
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=109863&aid=1786972&group_id=9863
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: wxGTK specific
Group: Platform specific
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Lloyd (lloydkl)
Assigned to: Nobody/Anonymous (nobody)
Summary: Slow Painting
Initial Comment:
In wxGtk2.8.4 the painting is too slow compared to wxGtk2.6.3. The slowliness of the painting would be annoying to the user. This problem can be found by running the drawing sample and by rotating the mouse scroll wheel to and fro for too many times consecutively.
OS Redhat EL 4 (Kernel 2.6.9-5)
Gtk+ lib version 2.4.13
gcc 3.4.3
----------------------------------------------------------------------
>Comment By: Robert Roebling (roebling)
Date: 2007-09-05 11:31
Message:
Logged In: YES
user_id=77100
Originator: NO
I have downloaded the two files and I'm looking at them with KCachegrind,
but I fail to understand the difference. The wxGTK 2.8.4 output says 100000
calls of g_check_is_instance() from within GTK+, whereas the wxGTK 2.6.3
output has no call to this? Anyways, I need your test app and then run it
myself to find more. Please attach the source.
----------------------------------------------------------------------
Comment By: Lloyd (lloydkl)
Date: 2007-09-05 10:11
Message:
Logged In: YES
user_id=1805805
Originator: YES
sorry, I am not able to upload the profiler output, though it is bigger
than the supported size by the sourceforge. Could you access it from here?
http://w13.easy-share.com/4727411.html
----------------------------------------------------------------------
Comment By: Robert Roebling (roebling)
Date: 2007-09-04 19:49
Message:
Logged In: YES
user_id=77100
Originator: NO
Forgot to mention that the flag -DGTK_NO_CHECK_CASTS is no longer used and
-DG_DISABLE_CAST_CHECKS should be used for the same thing in new code.
----------------------------------------------------------------------
Comment By: Robert Roebling (roebling)
Date: 2007-09-04 18:42
Message:
Logged In: YES
user_id=77100
Originator: NO
Actually, I just remembered the likely reason. In wxGTK 2.6, when
compiling the release build, configure adds _DGTK_NO_CHECK_CASTS to the
compile line. This changes the "meaning" of GTK_WIDGET() or GTK_LIST() etc.
macros from performing a run-time test to being just a cast. What's strange
is that the drawing code has no such casts, these are almost only in the
control code (e.g. in /src/gtk/window.cpp), so maybe there is something
else?
----------------------------------------------------------------------
Comment By: Robert Roebling (roebling)
Date: 2007-09-04 12:46
Message:
Logged In: YES
user_id=77100
Originator: NO
Can you attach the test program and the Valgrind output.
----------------------------------------------------------------------
Comment By: Lloyd (lloydkl)
Date: 2007-09-04 12:25
Message:
Logged In: YES
user_id=1805805
Originator: YES
Yes I have compiled the same program on the same system with the different
wxGtk Versions by keeping all the command line options as same. Both of my
build is wxGtk unicode shared. I have written a small program to test this
and that too has the same problem.
I have tried the code with valgrind tool and what I could understand from
the result is, in 2.6.3 it takes only 2 calls when painting is done while
the 2.8.4 takes something around 200. (But I am not sure whether I have
interpreted the callgring output correctly)
----------------------------------------------------------------------
Comment By: Robert Roebling (roebling)
Date: 2007-09-04 11:30
Message:
Logged In: YES
user_id=77100
Originator: NO
I'm currently updating to the latest revisions from the two branches and
will compile and test then. But a diff betwenn the drawing code from 2.6
and 2.8 showed no obvious change for slowdown. You are sure you are using
the same compilation options, the same GTK+ version etc. for the same
drawing code? The drawing sample is pretty big, complex and has "unnatural"
drawing calls, since it test the API, not performance.
Interesting would be if the reporting of invalidated areas might differ
between the two version of wxGTK when scrolling happens. This would be the
easiest explanation for a slow down (or absence thereof).
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=109863&aid=1786972&group_id=9863
More information about the wx-dev
mailing list