Re: The correct way to implement a large scrolled canvas



On Fri, 2004-10-22 at 18:14 +0100, David J. Singer wrote:
> On Tuesday 19 October 2004 20:51, Owen Taylor wrote:
> >
> > There is no memory cost proportional to the size of the drawing area.
> > (That's why you need to repaint your drawing area in the expose
> > handler...)
> 
> But surely for even a moderately complicated "drawing area", you would
> need to create and maintain a backing pixmap to speed up the exposures.

Generally not, no. I've almost never seen that done in a real
application. Basically real applications have to handle changes to the
content of their drawing areas, if they can't handle exposes fast
enough, they can't do that fast enough either.

> I was assuming such a backing pixmap in my original question.  Hence my 
> concern about creating a big drawing are and the resultant memory usage.

Well, if you are maintaining your own backing pixmap, you are free to
maintain it only to the size of the visible area. It's not completely
trivial to track, but not that hard either - you just connect to 
'changed' and 'value-changed' on the viewports GtkAdjustments, and the
visible x area (for examplee) is given by 

 [hadjustment->value, hadjustment->value + hadjustment->page_size)

Regards,
							Owen

Attachment: signature.asc
Description: This is a digitally signed message part



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]