View Issue Details

IDProjectCategoryView StatusLast Update
0007717Lazarus-public2009-07-22 11:10
ReporterAles Katona Assigned ToMartin Friebe  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Platformx86_32OSFreeBSD 
Target Version0.9.28Fixed in Version0.9.27 (SVN) 
Summary0007717: Scrolling down with arrow in TSynEdit = 100%CPU
DescriptionThis is gtk2 specific, in gtk1 I get only about 10% usage.
Tagsgtk2
Fixed in Revision19999, 19801
LazTarget1.2
WidgetsetGTK 2
Attached Files

Relationships

related to 0011715 closedMartin Friebe Synedit on windows, SetTopline "paints", outside of "procedure paint". possible flicker, or unnecessary paint 
child of 0008165 closedMattias Gaertner GTK2 - suggested to be default 

Activities

Felipe Monteiro de Carvalho

2007-05-09 11:01

developer   ~0012559

I just tested here on a not so good notebook and it goes to about 70% CPU usage. On Gtk 1 it uses around 10%.

Ales Katona

2007-10-26 12:02

developer   ~0015757

fixed in the meantime

Felipe Monteiro de Carvalho

2008-04-16 18:34

developer   ~0018870

It's still very slow here. The time to paint a written character is very noticable and very annoying.

Vincent Snijders

2009-04-22 21:40

manager   ~0026955

Reminder sent to: Felipe Monteiro de Carvalho

Felipe, is it still slow? Or can this issue be closed?

Martin Friebe

2009-04-23 00:21

manager   ~0026961

Last edited: 2009-04-23 00:22

@Felipe Monteiro de Carvalho
If it still is slow: can you please check with various fonts?

Does the slowness apply to:
- all fonts (proportional and monospaced)
- proportional only
 when using a monospaced font, make sure it is available for all bold, italic, underline styles that you use in your highlighter-settings. Otherwise you cant be sure that not a proportional font is used in substitution.

Does it depend on the usage of Syntax Highlighting (maybe in combination with the font used)


The background of this question is, that SynEdit is using fixed width display.
It allows to select proportional fonts, which it will force into the grid. However this "forcing" can be expensive.

Vincent Snijders

2009-04-23 08:57

manager   ~0026964

Maybe this issue should be closed, because Ales thinks it is has been fixed. Felipe can open a new issue, if he think it is not yet fixed.

Martin Friebe

2009-04-23 14:00

manager   ~0026981

Actually, in the mean time I was able to test myself and I was able to get 50% cpu usage during scrolling myself (70% with proportional fonts)

So it probably still exists.

Martin Friebe

2009-05-04 16:43

manager   ~0027282

Please test and close if ok.

This does fix the main issue: Scrolling with cursor up/down.

There are a few cases where this does still not work (and this is rooted very deep in the overall design or even Gtk2 itself).

- Gtk2 is quite resource-hungry when it comes to paint text. (This appears to be Gtk2, but there may or may not be room for minor improvements in the LCL Interface. But that's a different issue)
- Scrolling can be done by either: repainting the whole text; or moving the currently visible canvas and paint only the noew lines
- Gtk2 (same as windows and others) always combines all invalidate parts of a widget/canvas to one single all including rectangle.

Therefore the following can be said: scrolling up, invalidates the bottom-line (as it must be painted with the text that was scrolled in / not previously visible).
If in addition anything invalidates the top-line => this leads to the whole text being repainted, instead of scrolled.

Currently the line with the caret is always (almost always) invalidated. this means if you are scrolling down (top line has new text), and the caret is at the bottom-line => full repaint => slow.

This happens if / Scrolling is slow if:
- you scroll using ctrl-cursur_up / ctrl-cursor_down
- you scroll using the mousewheel or scrollbar, and the option "Caret always visible" is true

Scrolling is fast if:
- you scroll with the cursor keys, attempting to move the caret out of the visible window)
- you scroll using the mousewheel or scrollbar, and the option "Caret always visible" is false





It all depends

Martin Friebe

2009-05-05 00:11

manager   ~0027300

Fix doesn't work with highlighting. Sorry

Martin Friebe

2009-05-26 15:04

manager   ~0028018

Please test and close if ok.

Note, there are some cases where you can keep the caret on the line opposite to the "scrolled in area" => for those case this will not work. (and probably will not be fixed or not in near future)

In this cases *all* widget-sets spend more CPU. The fact that GTK2 is taking more time to draw a character than windows (afaik), can not be fixed in Lazarus.

This cases can be triggered by
- scrolling with ctrl-cursor-up/down
- mouse-wheel, if "Always visible Caret" is ON

example:
Scrolling up, with the caret in the top-line (and the caret being kept in the top line, instead of being scrolled away)
In this case the topline will be repainted for the caret, and the bottom line will be scrolled in, and needs painting too.
For compatibility between Widgets, this triggers a full repaint.

Normal scrolling, by just moving the cursor down (to scroll the text up) should work fine.

Issue History

Date Modified Username Field Change
2006-10-31 20:25 Ales Katona New Issue
2006-10-31 20:25 Ales Katona Target => -
2006-10-31 20:25 Ales Katona Widgetset => GTK 2
2006-12-01 22:38 Vincent Snijders LazTarget - => post 1.0
2006-12-01 22:38 Vincent Snijders Status new => acknowledged
2007-05-09 11:01 Felipe Monteiro de Carvalho Note Added: 0012559
2007-05-09 11:01 Felipe Monteiro de Carvalho LazTarget post 1.0 => 1.2
2007-10-26 12:02 Ales Katona Status acknowledged => resolved
2007-10-26 12:02 Ales Katona Resolution open => fixed
2007-10-26 12:02 Ales Katona Assigned To => Ales Katona
2007-10-26 12:02 Ales Katona Note Added: 0015757
2008-03-11 11:30 Ales Katona Status resolved => closed
2008-04-16 18:34 Felipe Monteiro de Carvalho Assigned To Ales Katona =>
2008-04-16 18:34 Felipe Monteiro de Carvalho Status closed => feedback
2008-04-16 18:34 Felipe Monteiro de Carvalho Resolution fixed => reopened
2008-04-16 18:34 Felipe Monteiro de Carvalho Note Added: 0018870
2008-04-16 18:34 Felipe Monteiro de Carvalho Status feedback => confirmed
2008-04-16 18:55 Felipe Monteiro de Carvalho Tag Attached: gtk2
2008-07-16 20:36 Vincent Snijders Relationship added child of 0008165
2009-04-22 21:40 Vincent Snijders Note Added: 0026955
2009-04-22 21:40 Vincent Snijders Status confirmed => assigned
2009-04-22 21:40 Vincent Snijders Assigned To => Martin Friebe
2009-04-23 00:21 Martin Friebe Note Added: 0026961
2009-04-23 00:21 Martin Friebe Status assigned => feedback
2009-04-23 00:22 Martin Friebe Note Edited: 0026961
2009-04-23 08:57 Vincent Snijders Note Added: 0026964
2009-04-23 14:00 Martin Friebe Note Added: 0026981
2009-04-23 14:02 Martin Friebe Status feedback => assigned
2009-04-23 14:04 Martin Friebe Relationship added related to 0011715
2009-05-04 16:43 Martin Friebe Fixed in Revision => 19801
2009-05-04 16:43 Martin Friebe Status assigned => resolved
2009-05-04 16:43 Martin Friebe Fixed in Version => 0.9.27 (SVN)
2009-05-04 16:43 Martin Friebe Resolution reopened => fixed
2009-05-04 16:43 Martin Friebe Note Added: 0027282
2009-05-04 16:43 Martin Friebe Target Version => 0.9.28
2009-05-05 00:11 Martin Friebe Status resolved => assigned
2009-05-05 00:11 Martin Friebe Resolution fixed => reopened
2009-05-05 00:11 Martin Friebe Note Added: 0027300
2009-05-26 15:04 Martin Friebe Fixed in Revision 19801 => 19999, 19801
2009-05-26 15:04 Martin Friebe Status assigned => resolved
2009-05-26 15:04 Martin Friebe Resolution reopened => fixed
2009-05-26 15:04 Martin Friebe Note Added: 0028018
2009-07-22 11:10 Ales Katona Status resolved => closed