On Wed, 2008-02-13 at 01:26 +0100, Webmaster wrote: > Hi, > > sorry for double-mailing last time. > > I can now give a more precise description of the > bad behavior of my entries in TOPLEVEL-windows > having some (normally one) of my own-written > spread sheets. > > This spread sheet draws on demand of the > scroll bar. Thus drawing is independant of the length > of the table - i had a run with 24.000 lines (10 columns). > However, it has autosized columns, thus a method > prepares the pango-layouts and measures their widths. > Initialization of that 24.000 lines took around half a minute. > Fixed widths could provide the possibility of > lazily computed infinite tables - but i had no > need for that recently. > > But this means a lot of drawing - therefore > python on its own is too slow - at least for a > normal bureau computer. Scrolling more than 1,000 > lines was impossible without psyco. The spread > sheet inherits from psyco.compact. But it's not > psyco with its changed object model. Same > problems without psyco (and smaller tables). > > Problems with my spread sheet are not restricted to > entry-widgets around. In IDLE modules with the > spread sheet cannot be killed properly. And > if the program's window is above an editor > window of IDLE bad artefacts on that editor > window can arise. > > Thus my spread sheet seems to affect parts of > the whole grafic system. The problem does not > exist with eclipse and not while running > such modules standalone. And there is no increased > demand for memory. > > The entry widgets seemingly cease to draw on > keyboard input directly, as they normally do. > It seems, that the delay of around a second is > due to the blinking frequence of the cursor. > That this blinking generates expose events, which > then cause the entries to render the text finally. > This suspicion comes from what i see. > > Here my repeated question: Have such problems > seen with gtk.Entry before ? Respectively > with gtk.CellRenderer (which i suspect to be > the real offender) ?
Its very rare that there is a fundamental problem in large frequently used libraries such as (py)Gtk, most errors are due to developer error or misunderstandings. In any case it is nearly impossible to help you without seeing the source code you are talking about Regards, John > > Cheers, Joost > _______________________________________________ > pygtk mailing list pygtk@daa.com.au > http://www.daa.com.au/mailman/listinfo/pygtk > Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/ _______________________________________________ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
