Hi Phillippe, I just wrote a new video base library, "slowvbl", that makes it easy to see what areas of the screen are changed. You can use it by turning it on in the compile-time configuration, then (assuming you're using the sdlfb driver for debugging) specifying --video-sdlfb.slowvbl on the command line or putting "slowvbl = 1" in the [video-sdlfb] section of your config file.
You're right about the problem being caused by too many calls to pgUpdate(). The pgUpdate() function synchronizes the display to reflect what pgserver has in it's widget tree, so if one app's busy launching and another calls pgUpdate(), pgserver will draw the partially-completed app. There are two ways i can think of to fix this: - Make sure pgUpdate() doesn't get called frequently. This is the approach PicoGUI has been using so far. In particular, make sure your battery monitor program calls pgSubUpdate() instead of pgUpdate(). I suspect that the battery monitor is the one calling Update 96 times, but if it's not try running pgserver in gdb with a breakpoint in its update() function. - A better solution would be to keep the entire app hidden while the client is busy creating it. The pgRegisterApp() function could create the apps' widget, but not attach it. When a new function, maybe pgShowApp() or something, is called the app would be attached to pgserver's tree. For backward compatibility, maybe we have it automatically attach the app the first time it waits for an event with pgEventLoop() or pgGetEvent(). --Micah On 2002.01.14 10:59 Philippe Ney wrote: > Hi Micah, hi all, > > Thanx for the tips for emplementing password support. I will start > this soon. > > By now, I have another problem due to some ~concurrent~ update which > appear only on the DragonBall platform :-) > > I have the following application: > > +------------+ > | | > | LAUNCHER | > | | > +------------+ > | TOOLBAR | > +------------+ > > The LAUNCHER is an application that contain a grid of 3x3 'icon + text > application' which disppear (is size is set to 0) when an app is > launched. > The launched app take place of the LAUNCHER > > The TOOLBAR contain a 'Prefs' button to access some popup windows, a > 'Home' button that appear when an app is launched to go back to the > LAUNCHER (kill the app and size set to all), a public box that let a > battery monitor daemon display battery level and a 'KBD' button that > is connected to a running pgboard to show/hide it. > > The problem is that when I launch the vrcalc for exemple, everything > is updated each time a widget is created and we can see each widget > creating on the display. This really slow the display of the vrcalc. > > Tracing the problem, I note the following: > > * killing the pgboard speed the vrcalc display to a normal delay > > * If I display whatever a popup at the beginning of the vrcalc > definition and I kill it just > before entering in the EventLoop also speed the display > The popup will dimm the background and then none refresh is done as > long as the popup is displayed > > * the app is vfork-ed. If I 'waitpid()' after vforking, the vrcalc is > also displayed quickly > > * I print the DEBUG_VIDEO debug of pgsever/gcore/div.c -> update(...) > and get the following when launching vrcalc: > > ****************** Update (sub: 0x10749A9C) > ****************** Update (sub: 0x10749A9C) > ****************** Update (sub: 0x10749A9C) > ****************** Update (sub: 0x00000000) -+ > ... |--> 96 times !!! > ****************** Update (sub: 0x00000000) -+ > > > In fact, the display is speeded when I prevent the programm to run > normaly. > > When a client app is loaded, the first time it is updated is when you > enter the pgEventLoop, right? > In my full application, I have the main app, the battery daemon and > the pgboard which have each an EventLoop, I suspect then that things > are updated many times for the same reason. > The vrcalc displaying is updated by the others applications before it > enters its own EventLoop. > > For exemple, when the vrcalc create a widget, this video modification > is taken by the update loop of the pgboard which decide to update the > display, etc... > > Maybe it could be useful to have a way to stop/enable video updates. > > Currently I use the 'display-kill popup' in each app to speed the > display... > > Do you have some idea about how fixing those strange behaviours? > Maybe the applications have to start a global update system if it is > the first running or register it to this global update system if it > already has been created by a previously loaded application... > > -philippe > > _______________________________________________ > Pgui-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/pgui-devel > _______________________________________________ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel
