X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-Cam-AntiVirus:	no malware found
X-Cam-ScannerInfo:	http://www.cam.ac.uk/cs/email/scanner/
Message-ID:	<1410041434.27594.3.camel@cam.ac.uk>
Subject:	Re: [geda-user] gschem sometimes takes a nap
From:	Peter Clifton <pcjc2 AT cam DOT ac DOT uk>
To:	geda-user AT delorie DOT com
Date:	Sat, 06 Sep 2014 23:10:34 +0100
In-Reply-To:	<75C94905-4B16-4DEE-B42F-E33F35312204@sbcglobal.net>
References:	<lu83am$t8p$1 AT ger DOT gmane DOT org>
	<CAGRhJMZt5Z5DdVO=+=b+-6dDoOEAB4V57=MWuStR5imC1+WWQg AT mail DOT gmail DOT com>
	<7C56210D-D45D-4E93-B755-E373AC009668 AT sbcglobal DOT net>
	<lubvfc$p5k$1 AT ger DOT gmane DOT org>
	<68DB3C77-2335-4016-B466-20CA135CD4CC AT sbcglobal DOT net>
	<75C94905-4B16-4DEE-B42F-E33F35312204 AT sbcglobal DOT net>
X-Mailer:	Evolution 3.12.4-0ubuntu1
Mime-Version:	1.0
Reply-To:	geda-user AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	geda-user AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Fri, 2014-09-05 at 21:38 -0700, Edward Hennessy wrote:
> A potential fix is checked into source control. Hopefully, it isn't just tuned to execute faster on my machine.
> 
> Something not intuitive is going on under the hood:
> 
> - The change in x_event.c reduces the number of invalid rectangles to one - yields a speed improvement
> - The change in x_grid.c moves the cairo_stroke() into the for loop - performance actually gets WORSE
> - When both changes are combined - performance is much faster than the changes in x_event.c alone


Presumably you are seeing a trade-off between painting lots of small
pieces of the screen, and painting the whole screen in one hit. Gschem
isn't very efficient at mapping the small regions into a list of objects
to paint.

I'd suggest looking at whether there is a heuristic you can apply for
the operations which cause a certain amount of redraw, to force a redraw
of the whole screen rather than the individual areas.

It might be worth looking at whether invalidating the whole screen for
_every_ update is actually a pragmatic way to proceed.

If you invalidate the whole screen area, GDK _should_ subsume the small
regions into the larger one.

Now most X11 desktops have moved away from a model where you get
individual small expose events, so painting exposed regions uncovered by
moving other windows is not really a concern nowadays. All the drawing
is triggered by us.


-- 
Peter Clifton <peter DOT clifton AT clifton-electronics DOT co DOT uk>

Clifton Electronics

- Raw text -