I'm not familar at all with the gnomecanvas implementation, but I highly doubt it stores information about every pixel in memory. On Mon, 14 Mar 2005 17:31:59 -0600, Greg Breland <gbreland@xxxxxxxxxxxxxxx> wrote: > I'm amazed its even possible to create a canvas that is 1million x > 1million. The shear amount of memory needed to do this is staggering. > Lets say it a 16bit canvas, that would be (1000000*1000000*2)/1024/1024 > = 1,907,349MB. > > Your going to have to manage scrolling yourself and only make the canvas > slightly larger than the current viewport size. > > On Mon, 2005-03-14 at 16:24, Joe Van Dyk wrote: > > Say I have a 2D space that's potentially very large. I need to be > > able to display various player icons on this world (they rotate and > > move around in this space) and draw a grid on it. > > > > Players shouldn't really be limited to a certain area of movement, > > they should be able to move pretty darned far. So if I initialize a > > gnomecanvas that's 1000000x1000000, they could probably move off of > > that and I'd have to resize the viewable area. > > > > And if I initialize a huge world up front and draw grids all over it, > > the application takes a long time to start. > > > > So, what I really need to do is make the world big enough to contain > > all the players, even when the players move around (the world should > > expand as the players move away from the center). > > > > Ideas on how to properly implement something like this? Another > > problem I've run in to is that when the world / viewable area is very > > large, the scroll bars don't provide very good movement (think > > scrolling in a million page document or something). > > > > Thanks, > > Joe > > _______________________________________________ > > > > gtk-list@xxxxxxxxx > > http://mail.gnome.org/mailman/listinfo/gtk-list > > _______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list