[wxPython] GTK problem with wxStyledTextCtrl.

wxPython Users
1

wxStyledTextCtrl Problem

···

------------------------

I am running
    Redhat Linux 6.2.
    wxGTK 2.2.2
    wxPython 2.2.2
    Python 2.0

I am experiencing a problem with the wxStyledTextControl. The behaviour
is sluggish
and it uses up a lot of CPU.

My Research
------------

I placed a printf into stc.cpp, in the OnPaint() method. This printf
displays the rectangle co-ordinates. I see that the OnPaint method is
called
each time the cursor blinks.

I notice that the call is made even when the cursor is not blinking,
i.e.
where the cursor is on another screen (Small problem).

You can see the cursor behavior by placing these lines in OnPrint..

    wxRect rect = region.GetBox();
    printf("stc.cpp:wxStyledTextCtrl::Painted(%d, %d, %d, %d\n",
        rect.x, rect.y, rect.width, rect.height);

If you run the demo program, you can see the paints ...

    python2.0 run.py wxStyledTextCtrl_2.py

O.K. So far.

Problematic Behaviour
---------------------

I place my wxStyledTextControl on a notebook. There is a wxPanel between
the
wxStyledTextControl, because I found that this helps. Occasionally, when
I
scrolldown using the scrollbar, the cursor region height gets totally
messed
up. It becomes some number > 60000. (possibly some short underflow ??)
The resulting refreshes are extremely time consuming.

stc.cpp:(1513)::wxStyledTextCtrl::Painted(40, 0, 579, 65168
stc.cpp:(1513)::wxStyledTextCtrl::Painted(0, 0, 619, 404
stc.cpp:(1513)::wxStyledTextCtrl::Painted(40, 0, 579, 64784
stc.cpp:(1513)::wxStyledTextCtrl::Painted(40, 0, 579, 64784

I am not sufficiently familiar with wxWindows to identify the source of
these
events. Perhaps someone could give me a few pointer as to where to look
(and
perhaps how).

I can defend against the problem by placing the following code in
the OnPaint method. (However, I would like to identify the source of the
problem.)

    wxRect rect = region.GetBox();
    if (rect.height > 60000)

rect.height=16;

Thanks in advance

Kevin
_______________________________________________
wxPython-users mailing list
wxPython-users@lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/wxpython-users

2

Hi Kevin,

I notice that the call is made even when the cursor is not blinking,
i.e.
where the cursor is on another screen (Small problem).

   Could be fixed but need to have the blinking version be non-sluggish
anyway. Something else to look for is the amount of code being executed
within the StyleNeeded, UpdateUI, and Painted (Painted probably isn't in
wxSTC yet) notifications as its often the callback code that slows it down
even if its just a matter of marshalling into the Python world. Not that
StyleNeeded or UpdateUI should be called for every blink, but if the styling
doesn't happen completely (some lexers in the past did not style the final
line end of each segment so were called continuously) then there will be
overhead here.

   The cursor blinking code could be seriously optimised in a many ways such
as determining a smaller paint rectangle just around the caret location and
possibly caching two line pixmaps.

I place my wxStyledTextControl on a notebook. There is a wxPanel between
the
wxStyledTextControl, because I found that this helps. Occasionally, when
I
scrolldown using the scrollbar, the cursor region height gets totally
messed
up. It becomes some number > 60000. (possibly some short underflow ??)

   Ughh, Scintilla uses signed integer coordinates. If another piece of code
is treating these as unsigned shorts then they should be converted back
before use and possibly clipped to the positive quadrant if that is required
by wxWindows.

   Neil

···

_______________________________________________
wxPython-users mailing list
wxPython-users@lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/wxpython-users

3

Thanks for the information.

Do you know where the PAINT requests are being generated. Since
the Event Handler is in wxStyledTextControl, I presume the
events are being generated in the wxPython / wxWindows world,
rather than the Scintilla world. Where would I look to find the
code which is the source of these events ?

I'm afraid that I have 3 modules, Scintilla, wxPython and wxWindows
and I am unfamiliar with the source of any of them.

Kevin

Neil Hodgson wrote:

···

   Hi Kevin,

> I notice that the call is made even when the cursor is not blinking,
> i.e.
> where the cursor is on another screen (Small problem).

   Could be fixed but need to have the blinking version be non-sluggish
anyway. Something else to look for is the amount of code being executed
within the StyleNeeded, UpdateUI, and Painted (Painted probably isn't in
wxSTC yet) notifications as its often the callback code that slows it down
even if its just a matter of marshalling into the Python world. Not that
StyleNeeded or UpdateUI should be called for every blink, but if the styling
doesn't happen completely (some lexers in the past did not style the final
line end of each segment so were called continuously) then there will be
overhead here.

   The cursor blinking code could be seriously optimised in a many ways such
as determining a smaller paint rectangle just around the caret location and
possibly caching two line pixmaps.

> I place my wxStyledTextControl on a notebook. There is a wxPanel between
> the
> wxStyledTextControl, because I found that this helps. Occasionally, when
> I
> scrolldown using the scrollbar, the cursor region height gets totally
> messed
> up. It becomes some number > 60000. (possibly some short underflow ??)

   Ughh, Scintilla uses signed integer coordinates. If another piece of code
is treating these as unsigned shorts then they should be converted back
before use and possibly clipped to the positive quadrant if that is required
by wxWindows.

   Neil

_______________________________________________
wxPython-users mailing list
wxPython-users@lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/wxpython-users

_______________________________________________
wxPython-users mailing list
wxPython-users@lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/wxpython-users

4

Do you know where the PAINT requests are being generated. Since
the Event Handler is in wxStyledTextControl, I presume the
events are being generated in the wxPython / wxWindows world,
rather than the Scintilla world. Where would I look to find the
code which is the source of these events ?

I'm afraid that I have 3 modules, Scintilla, wxPython and wxWindows
and I am unfamiliar with the source of any of them.

The paint events are coming from wxWindows like any other EVT_PAINT. It is
caught by wxStyledTextCtrl::OnPaint in stc.cpp, which passes it to
ScintillaWX::DoPaint in ScintillaWX.cpp where it then lets the Scintilla
code take over.

All events are handled in this way. They are caught by wxStyledTextCtrl
which derives from wxControl so it is "the window" and then they passed over
to ScintillaWX which is derived from ScintillaBase and which is our
interface with the higher level Scintilla code. When Scintilla needs to do
some low level gui work (actuall drawing, making fonts, etc.) then it uses
some generic wrappers defined in Platform.h/PlatWX.cpp to do it.

···

--
Robin Dunn
Software Craftsman
robin@AllDunn.com
http://wxPython.org Java give you jitters?
http://wxPROs.com Relax with wxPython!

_______________________________________________
wxPython-users mailing list
wxPython-users@lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/wxpython-users