Neil,
I should probably mention that I am not using one of the tried and
true platforms. I've been trying to implement the platform
compatibility layer in Qt 4. My development platforms are Mac OS X
and windows. I'm getting on pretty well.
We did evaluate qscintilla first but determined that waiting for the
transition to 4 would cost more in the long run than doing our own
implementation. We also found the license less than ideal. In any
case we are very pleased with scintilla so far.
I have done some fairly extensive profiling because of redraw
performance concerns. After streamlining the font metrics routines
in my platform code I find that an obscene majority (north of 95
percent) of time is spent just rendering text. This, I suppose,
shouldn't come as any great surprise. That is why I have turned my
attention to trying to avoid any unnecessary repainting. Like I said
before, performance is pretty good with just one widget, but initial
tests with two scrolled together show some jumpiness.
A couple more comments follow inline.
On Feb 9, 2006, at 7:01 PM, Neil Hodgson wrote:
Jason Haslam:
I had thought that it was more a case of diminishing returns. My
assumption is that scrolling the widget is always faster than
rendering text. If any part of the view can be copied then there is
something to be gained. Does that oversimplify?
I don't know as I haven't done enough measurements. One thing that
is slow is scrolling when there is another window clipping into the
scrolling area.
Hmm... I tried to do this just now but I couldn't get scroll focus
with any part of the window obscured.
I imagine a case where 30 lines are visible on the screen. If a
mouse wheel event generates a scroll of 20 lines then I would want
the pixel information for the remaining 10 lines to be copied and 20
lines to be rendered new. It seems like a gain but there may be some
additional costs in getting up that machinery to do a widget scroll.
I don't know if scrolling is always implemented inside the graphics
server or if it requires the live pixels to be sent back to the client
for redisplay. Current setups are probably well optimised but X is an
old system with many implementations.
Yes. I hadn't considered the implications on X windows. It
certainly is something that I need to be worried about since we will
be deploying this on platforms that use X.
Scroll performance wouldn't worry me too much, but I'm trying to put
two scintilla editors inside of a diff tool. These kind of costs
start to add up when scrolling both views together.
Then measure it. It should be fairly easy to tweak the lines
parameter inside Scintilla and see if it makes a difference. If there
is a reasonable speed-up on a current x.org server on a less than year
old PC then I'd include it. Robert can scream if it upsets his
minority platform.
I have tweaked it and can see no appreciable difference. That is, I
can't feel any difference. I haven't done any formal analysis. I
still might do some measurement if I have time, but it probably isn't
worth the expenditure of effort anymore.
However, I do see a noticeable difference in small scrolls when the
caret is visible after removing the call to ShowCaretAtCurrentPosition
().
Jason
_______________________________________________
Scintilla-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scintilla-interest
