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.

> 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.

> 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.

   Neil

_______________________________________________
Scintilla-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scintilla-interest

Reply via email to