Re: Scintilla GTK2 profiling results
- From: "Neil Hodgson" <nhodgson bigpond net au>
- To: "Owen Taylor" <otaylor redhat com>
- Cc: <biswapesh_chatterjee tcscal co in>, "Scintilla Interest" <scintilla-interest lyra org>, "GTK Devel" <gtk-devel-list gnome org>, "Naba Kumar" <kh_naba gmx net>
- Subject: Re: Scintilla GTK2 profiling results
- Date: Thu, 17 Apr 2003 06:12:55 +1000
Owen Taylor:
> Generally you want synchronous exposes of the target widget on
> scrolling; it just looks better, and for another thing, if you don't
> do your drawing, GTK+ may spend all the CPU time doing a beautifully
> smooth animation of the scrollbar.
For user initiated scrols, synchronous exposes are good. However,
Scintilla also manipulates the current scroll position, when, for example
changing documents or moving to a searched for string. For these operation,
there may be other invalidates performed. Because the text and the scroll
bar share a window, these invalidates are combined into a single expose that
will often hit the whole window. Because the expose is synchronous, it will
not then be combined with other invalidates in the same operation.
> If Scintilla is redrawing the whole buffer on every scroll, that
> certainly sounds like the first thing to address.
Scintilla should not be drawing the whole buffer on every scroll. The
ScrollText method blits the common text and then draws the exposed portion.
However, there is some deep gdk/x contributed code here which does a
gdk_gc_set_exposures(gc, TRUE); and then a loop (now disabled for GTK+ 2)
that is essentially while (gdk_event_get_graphics_expose) gdk_event_free()
The IRC transcript (sorry, couldn't work out attributions) suggests
gdk_window_scroll but it looks to me ike this scrolls all the contents of
the window, including the scroll bars.
Neil
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]