Hi Philippe, I just committed some changes to pgserver that will hopefully fix this problem. Any time a new divnode is created, it starts with the DIVNODE_UNDERCONSTRUCTION flag. As long as this flag is present, the divnode is ignored by the layout engine. The first time the app calls pgUpdate(), all these flags are removed from divnodes that it owns. This way one app calling pgUpdate() can never cause another to do a partial redraw of itself.
I hope it works for you :) --Micah On 2002.01.16 08:32 Philippe Ney wrote: > > 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. > > No it's ok. Even when I comment all the pgUpdate and pgSubUpdate of > all > the running applications, the behavior is unchanged... > And I haven't already run gdb on our architecture or emulator. Maybe > something to start a soon as I have time... > > > - 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(). > > Yessss! > Maybe pgRegisterApp() should _always_ create unattached widgets. And > those are attached when calling pgEventLoop()... > > I also thought about a mechanism that could control the way an app is > displayed from outside itself. Something similar to the 'pgEventLoop - > pgSetIdle' mechanisme. > With 2 client functions to manage the update and prevent unwanted ones > from the pgserver: > - pgStopUpdate() > - pgResumeUpdate(). > > And a call to pgResumeUpdate() should be added in pgEventLoop() before > entering the said loop to ensure restart of the update process. > > Backward compatibility is ok. > > -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
