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: <1410041502.27594.4.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:11:42 +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>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.12.4-0ubuntu1 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
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
Precedence: bulk

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