From owner-oi-users Fri Mar 10 08:28:06 1995 Return-Path: oi-users-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA17637 for oi-users-outgoing; Fri, 10 Mar 1995 08:28:06 -0800 Received: from marvin.boulder.openware.com (marvin.boulder.openware.com [192.245.99.138]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id IAA17630 for ; Fri, 10 Mar 1995 08:28:02 -0800 Received: from garya.boulder.openware.com (garya.boulder.openware.com [198.135.223.34]) by marvin.boulder.openware.com (8.6.9/8.6.9) with ESMTP id JAA24928; Fri, 10 Mar 1995 09:25:30 -0700 Received: (from garya@localhost) by garya.boulder.openware.com (8.6.9/8.6.9) id JAA05193; Fri, 10 Mar 1995 09:02:34 -0700 Date: Fri, 10 Mar 1995 09:02:34 -0700 From: Gary Aitken Message-Id: <199503101602.JAA05193@garya.boulder.openware.com> To: PCOBAS%ESOC.BITNET@vm.gmd.de Subject: Re: Rules to speed up the creation of OI objects Cc: oi-users@freefall.cdrom.com Sender: oi-users-owner@FreeBSD.org Precedence: bulk > We are having time problems when we try either to load a > big configuration file or creating dinamically OI objects. It > takes a long time to create the objects. This won't help for .cf file loading, but if you bracket the addition of children to a parent object with suspend/resume_layout, it should help: app->set_layout(OI_layout_row); app->suspend_layout(); ... create a bunch of objects and lay out in app app->resume_layout(); > For instance we have to create an OI_app_window with around > 64 OI_boxes, 240 OI_entry_fiels and 64 OI_buttons, and it > takes around 30 seconds. One problem you may be seeing here is X server related -- the server bogs down terribly when many windows are created as children of another window, which happens in the above case. Not sure how much of the problem you are seeing is related to this. One way to investigate it would be to group sets of the objects together into other containers, making a somewhat deeper hierarchy, and seeing how it affects performance. I can't remember where the performance gets lousy in terms of numbers; you may be under it, so this may not be an issue. I would guess it is more related to geometry management (layout), so the suspend/resume scenario may help.