Patch that speed things up (brain dump)

[Patrick Julien]

Before you do this, what Krita really needs is to use X shared memory when 
it's on a local display.

If you consider that it's still not using Xsm, I don't consider Krita slow, 
no.


On February 27, 2004 07:26 am, Boudewijn Rempt wrote:
> On Friday 27 February 2004 12:43, Roger Larsson wrote:
> > This patch speeds things up enough for most brushes (even the paprika).
> >
> > It is really a multi part...
> > 1) An attempt to speed up drawing itself (not finished, has bugs)
> > 	Guess why I started to look into other image libraries :-)
> >
> :-). I haven't found any library that's as versatile as we want Krita's
> : design
>
> to be -- so we'll have to roll our own, I fear. I think we're near the
> moment when it would be wise to do some actual profiling to check where the
> worst bottlenecks are, currenlty.
>
> > 2) Rethink of m_dirtyRect and screen redraws
> > 	let m_dirtyRect accumulate changes!
> > 	notify on:
> > 	a) mouse release
> > 	b) timeout  (kis_notify_limit [ms])
> > 		The timeout is global to simplify modifications.
> > 		kis_notify_limit = 0 gives you back the current behaviour.
> > 		kis_notify_limit = 10 gives about one update per monitor refresh
> > (100Hz). kis_notify_limit = 50 X is no longer the problem - krita/brushes
> > are.
>
> It looks pretty interesting: I have been thinking about the timed notify
> lately, too. I think it would be pretty cool to absolve all tools and
> drawing code from the obligation to notify, and put the timer in KisView,
> and store the dirty rect in KisImage. Then whenever the timer fires, the
> view can be repainted, possibly in another thread so drawing operations are
> not disrupted -- you'd need to synchronize on tiles, of course, but I think
> it would give both a speed-up and a better design.