a bug, feature??

Message boards : Number crunching : a bug, feature??
Message board moderation

To post messages, you must log in.

1 · 2 · Next

AuthorMessage
Profile PyroFox
Avatar

Send message
Joined: 5 Apr 03
Posts: 155
Credit: 213,891
RAC: 0
Canada
Message 27295 - Posted: 17 Sep 2004, 12:03:02 UTC
Last modified: 17 Sep 2004, 12:07:04 UTC

i don't even know if I would call it a bug...if it is, it ain't high on the priority list.

anyhoo, I was doing some testing in relation to minimized tabs (this thread http://setiweb.ssl.berkeley.edu/forum_thread.php?id=4234 i don't have time for HTML, just C + P) and I left it on the "disk" tab for most of the night, however, in keeping with precise CPU times, I suspended operations BEFORE opening the BOINC GUI window, (right - click), THEN when I opened the GUI window, the "messages" tab was up. now being as forgetful as I am, I thought I accidentally left it on the message tab, but after a few tries, the exact same thing happened.

whenever you are on any other tab (I tried with disk, and work) other then messages, right click the B icon in the system tray, and either click run, run with prefs, or suspend, once you open the GUI window, the "messages" tab is up, instead of whatever you left in on before.

I'm using BOINC 4.09 released 09-13-04, running only SETI for the duration of this test.


It's not a big deal, just want to see if I'm the only one :P. We got other more important things to fix.


-Fox

~edit for clarification.

oh, and paul, the rumor may be true. significantly. I'll post what results I got later, but I have only 2 tabs done.


<a><img>[/url]
ID: 27295 · Report as offensive
Profile Captain Avatar
Volunteer tester
Avatar

Send message
Joined: 17 May 99
Posts: 15133
Credit: 529,088
RAC: 0
United States
Message 27297 - Posted: 17 Sep 2004, 12:10:43 UTC

Hi PyroFox,

I recreated your (Bug) but I honestly don't know
why you would consider this a Bug. It seams to me that it makes since
and is normal.


Tim
</img>

ID: 27297 · Report as offensive
Profile Thierry Van Driessche
Volunteer tester
Avatar

Send message
Joined: 20 Aug 02
Posts: 3083
Credit: 150,096
RAC: 0
Belgium
Message 27301 - Posted: 17 Sep 2004, 12:22:56 UTC
Last modified: 17 Sep 2004, 12:23:20 UTC

I tried to reproduce it.

Hiding Boinc, openening again, I always get it with the tab open being the same as I had it before hiding.

Boinc v4.09, XP Pro SP1.

Greetings from Belgium.

ID: 27301 · Report as offensive
Ulrich Metzner
Volunteer tester
Avatar

Send message
Joined: 3 Jul 02
Posts: 1256
Credit: 13,565,513
RAC: 13
Germany
Message 27302 - Posted: 17 Sep 2004, 12:26:57 UTC - in response to Message 27301.  

> Hiding Boinc, openening again, I always get it with the tab open being the
> same as I had it before hiding.
>

Yes, but if it prints a message in the time it's minimized it will open with the message tab.




greetz, Uli
ID: 27302 · Report as offensive
Profile Thierry Van Driessche
Volunteer tester
Avatar

Send message
Joined: 20 Aug 02
Posts: 3083
Credit: 150,096
RAC: 0
Belgium
Message 27307 - Posted: 17 Sep 2004, 12:38:01 UTC - in response to Message 27302.  

> Yes, but if it prints a message in the time it's minimized it will open with
> the message tab.

OK.
I was thinking about that as beeing one possibility.

Thanks
ID: 27307 · Report as offensive
ric
Volunteer tester
Avatar

Send message
Joined: 16 Jun 03
Posts: 482
Credit: 666,047
RAC: 0
Switzerland
Message 27309 - Posted: 17 Sep 2004, 12:41:00 UTC - in response to Message 27301.  
Last modified: 17 Sep 2004, 12:42:31 UTC

PyroFox!

man you have ideas and time for it!!!!!!

but your are RIGHT!!!!

but it's not a bug,( for me!), it more looks like an "normal "behaviour",
You "have " this also in earlier versions and releases.

I needed a time to understand what exactly PyroFox is doing

Situation as described, ANY other tab is click, not the message tab.
you minimize
now NOT doppelclick for open,
first
right-mouse click on the boinc icon on the iconbar bottom right,
change run mode pro.. to something else

now double click the minimized icon to open the boinc gui.

Message tab is in foreground.

but, due changing the run mode, an event is done for the client and a message is added to the message tab.

(why is an other questions. perhaps actualized/refreshed infos = activating
message tab)

"for me" this is an natural behaviour. As "natural" if it would not do it

*smile*

thanks for posting, you have a good observation..

greetings

ric
ID: 27309 · Report as offensive
Profile wilsen
Volunteer developer

Send message
Joined: 15 Apr 00
Posts: 68
Credit: 73,527
RAC: 0
Germany
Message 27312 - Posted: 17 Sep 2004, 12:42:28 UTC

Why should that be a bug? If there is a message, why shouldn't the client try to show this message to the user in the first place?
KEINE PANIK
ID: 27312 · Report as offensive
Profile Contact
Volunteer tester
Avatar

Send message
Joined: 16 Jan 00
Posts: 194
Credit: 2,249,004
RAC: 0
Canada
Message 27322 - Posted: 17 Sep 2004, 13:09:47 UTC - in response to Message 27312.  

> Why should that be a bug? If there is a message, why shouldn't the client try
> to show this message to the user in the first place?
> KEINE PANIK

While this can be considered a feature and not a bug, me thinks PyroFox is testing out the rumor of another bug where the BOINC Panes are updated even when minimized. Reverting to Messages Pane while minimized is then an issue. I've also tried testing for 'minimized pane bug' and have noticed strange behavior. I'll post later when time allows and i can get my head around the short WU's i had during these tests.
ID: 27322 · Report as offensive
Profile Paul D. Buck
Volunteer tester

Send message
Joined: 19 Jul 00
Posts: 3898
Credit: 1,158,042
RAC: 0
United States
Message 27367 - Posted: 17 Sep 2004, 15:03:43 UTC - in response to Message 27297.  
Last modified: 17 Sep 2004, 15:06:11 UTC

Tim,

> I recreated your (Bug) but I honestly don't know
> why you would consider this a Bug. It seams to me that it makes since
> and is normal.

Well, no ... it is a bug.

When the application is closed, no updates should be posted to the GUI. The GUI should not be updated unless the application is on the desktop and the window is open.

Technically, even if minimized to the taskbar the refreshes should not occur until the window is opened again and has visibility.

Note that if the widow is open and obscured, many OS will not update the hidden portions of the window. This is because it makes no sense to waste CPU updating something that is not visible. TO do so is a waste of CPU, and I/O of any kind is usually the slowest activities in a computer. Granted, a lot of the work is offloaded by the Graphics processors in the video cards, but, still ...

Last point, why is it changing the visible pane on me. If I have the BOINC Work Manager open it does not do that. And it shouldn't ... So, why is it doing it when it should not be doing any updates to the GUI?

Pyrofox,

I noticed that too .. I have been setting my GUI to the projects tab and I get enough messages because of the off line projects that it does not stay there long ...
<p>
For BOINC Documentaion: Click Me!


ID: 27367 · Report as offensive
Profile Captain Avatar
Volunteer tester
Avatar

Send message
Joined: 17 May 99
Posts: 15133
Credit: 529,088
RAC: 0
United States
Message 27375 - Posted: 17 Sep 2004, 15:28:51 UTC
Last modified: 17 Sep 2004, 15:29:52 UTC

Hi PyroFox and Paul,

Let me see if I can make sense of all this thru my dummie mind
O.K.

If the gui is minimized to the task bar and on the (disk tab) then the gui is still active and will report changes and accordingly flash most of the time,,, But if the gui is on messages tab when minimized it won't flash unless it uploads a unit.

This makes perfect sense to me, If the Bonic gui is a separate progran and crunches a work unit which is a separtate program in the puters eyes it will want to tell you its done a good job and wants you to see the message. which makes sense.

Tell me I am full of wooie and I'll sit back and read more...

Respecfully

TimBO
</img>

ID: 27375 · Report as offensive
Profile PyroFox
Avatar

Send message
Joined: 5 Apr 03
Posts: 155
Credit: 213,891
RAC: 0
Canada
Message 27390 - Posted: 17 Sep 2004, 16:17:16 UTC

not minimized to the task bar, but the system tray. (The B icon beside your clock)
[/url]
ID: 27390 · Report as offensive
Profile Captain Avatar
Volunteer tester
Avatar

Send message
Joined: 17 May 99
Posts: 15133
Credit: 529,088
RAC: 0
United States
Message 27400 - Posted: 17 Sep 2004, 16:39:27 UTC

FOX

O.K. Minimize to the system tray
all these years I thought it was the task bar...

Tim
</img>

ID: 27400 · Report as offensive
Profile Paul D. Buck
Volunteer tester

Send message
Joined: 19 Jul 00
Posts: 3898
Credit: 1,158,042
RAC: 0
United States
Message 27445 - Posted: 17 Sep 2004, 20:43:56 UTC - in response to Message 27375.  


> Let me see if I can make sense of all this thru my dummie mind
> O.K.
>
> If the gui is minimized to the task bar and on the (disk tab) then the gui is
> still active and will report changes and accordingly flash most of the time,,,
> But if the gui is on messages tab when minimized it won't flash unless it
> uploads a unit.
>
> This makes perfect sense to me, If the Bonic gui is a separate progran and
> crunches a work unit which is a separtate program in the puters eyes it will
> want to tell you its done a good job and wants you to see the message. which
> makes sense.
>
> Tell me I am full of wooie and I'll sit back and read more...

Ok, I used to have about 6 books on GUI design, but I will summarise it here, and this goes all the way back to IBM's CUA definition of a GUI (old stuff).

Fundamentally, if there is program activitiy and the window is open and visible it should be refreshed. If it is not open or visible, it should not be updated. There is no reason to post an update. What SHOULD be posted is a notification that the window is "dirty" (out-of-date) so that when the window is made visible, the changes are made at that time.

This means that if the GUI normally has an update every second, and you have it minimized for 10 minutes, well, you have just saved 599 updates. The posting of the "dirty" flag is done 599 times, but that is a simple boolean flag so the cost is negligable. But to post changes that are not going to be seen is, um, un-good.

Ok,

The bottom bar is called my Microsoft the "Task Bar" or "Taskbar" and it extends the width of the screen. In the right side area there is a place called the "Notification" area.

The updates to the notification area should be programmable. Right now they seem to be posting to the messages pane each message update, and then updating the notification area. The two posting activities are not, and should not be, directly connnect.

And you are mixing the GUIs ... The windows GUI shows the icon in the notification area. But updates to it are updates to the windows OS window. The BOINC Work Manager (a.k.a. core client - though the term is depreciated, a.k.a. BOINC Software) is a GUI for BOINC and BOINC alone. When the BOINC Work Manager is not visible either because it is minimized to the taskbar (as a button) or closed entirely it is not visible and updates to the visual windows should not be posted.

Whew! I hope this helps your understanding ... Remember, it is only my opinion too ... :)

Before any, um, malcontents attempt to use this discussion to beat on the development team should have their beanines taken away. With software you write it, make it work correctly in the sense that the features are all there, and then, and only then, do you optimize the programs.

We are still working on the feature set. So, this is not a big deal. We are getting science done, the systems are functioning and are allowing us to work out the minor issues like the GUI for my Macintosh .... :)
<p>
For BOINC Documentaion: Click Me!


ID: 27445 · Report as offensive
Profile Captain Avatar
Volunteer tester
Avatar

Send message
Joined: 17 May 99
Posts: 15133
Credit: 529,088
RAC: 0
United States
Message 27663 - Posted: 18 Sep 2004, 10:33:03 UTC - in response to Message 27445.  

WoW! I've Got it! Thank you for taking the time to help set me straight :)

Respectfully

Timmy

</img>

ID: 27663 · Report as offensive
Profile Paul D. Buck
Volunteer tester

Send message
Joined: 19 Jul 00
Posts: 3898
Credit: 1,158,042
RAC: 0
United States
Message 27681 - Posted: 18 Sep 2004, 11:16:49 UTC - in response to Message 27663.  

Tim,

> WoW! I've Got it! Thank you for taking the time to help set me straight :)

You are welcome. Pontificating is my game ... :)

There is more if you want to do some of your own looking, click on my signature to get started. Though I will warn you, there are a few "potholes" in the work right now. I am racing to get the material updated as fast as they keep adding...
<p>
For BOINC Documentaion: Click Me!


ID: 27681 · Report as offensive
Profile Daryl H
Avatar

Send message
Joined: 3 Apr 99
Posts: 21
Credit: 14,561
RAC: 0
Canada
Message 27908 - Posted: 19 Sep 2004, 4:41:03 UTC

I, too have noticed this behaviour, and if you don't mind, I'd like to ante up my interpretive nickel here.

The snag happens when an inactive BOINC! window is given a mouse event (it doesn't have to be minimized, only idle while new messages are coming in).
I suspect that the message window gets an update event, and somehow executes a "focusme" operation after rendering the text. The culprit might be residing inside a library, instead of mainline code, however.

regards,
Daryl.







ID: 27908 · Report as offensive
Cryz

Send message
Joined: 22 Feb 02
Posts: 46
Credit: 9,737
RAC: 0
Belgium
Message 28190 - Posted: 19 Sep 2004, 23:43:38 UTC - in response to Message 27445.  
Last modified: 19 Sep 2004, 23:45:08 UTC

> Fundamentally, if there is program activitiy and the window is open and
> visible it should be refreshed. If it is not open or visible, it should not
> be updated. There is no reason to post an update. What SHOULD be posted is a
> notification that the window is "dirty" (out-of-date) so that when the window
> is made visible, the changes are made at that time.
>
> This means that if the GUI normally has an update every second, and you have
> it minimized for 10 minutes, well, you have just saved 599 updates. The
> posting of the "dirty" flag is done 599 times, but that is a simple boolean
> flag so the cost is negligable. But to post changes that are not going to be
> seen is, um, un-good.

I agree. the visual side of a window and control should not be update when it is hiden (minimize, cover by another window, ...)

> The bottom bar is called my Microsoft the "Task Bar" or "Taskbar" and it
> extends the width of the screen. In the right side area there is a place
> called the "Notification" area.
>
> The updates to the notification area should be programmable. Right now they
> seem to be posting to the messages pane each message update, and then updating
> the notification area. The two posting activities are not, and should not be,
> directly connnect.
>
> And you are mixing the GUIs ... The windows GUI shows the icon in the
> notification area. But updates to it are updates to the windows OS window.
> The BOINC Work Manager (a.k.a. core client - though the term is depreciated,
> a.k.a. BOINC Software) is a GUI for BOINC and BOINC alone. When the BOINC
> Work Manager is not visible either because it is minimized to the taskbar (as
> a button) or closed entirely it is not visible and updates to the visual
> windows should not be posted.
>
> Whew! I hope this helps your understanding ... Remember, it is only
> my opinion too ... :)
>
> Before any, um, malcontents attempt to use this discussion to beat on the
> development team should have their beanines taken away. With software you
> write it, make it work correctly in the sense that the features are all there,
> and then, and only then, do you optimize the programs.
>
> We are still working on the feature set. So, this is not a big deal. We
> are getting science done, the systems are functioning and are allowing
> us to work out the minor issues like the GUI for my Macintosh .... :)
> <p>

I don't believe the visual side of the message control gets updated. As far as I can tell from the function MessageUser, it updates the data in the message control and changes the icon if needed. The message control is an extension of a standard list control so this means:
- if the message control is wasting cpu time by updating it's visual side then the dev team of the list control are to blame (=> dev team of the compiler, possibly Microsoft )
- Updating the contents (data, not visual) of the message control when an event happens or later when the control is visible again, CPU time used will be about the same.

The fact that the message tab is the one being visible after a message is written to it when minimized or hidden, is because it is the last one updated (content). The big difference between the message control and the work control (and the controls on the other tabs) is the nature of the content. The content of the work control (and co) is rewritten every time (no trace of previous content) but for the message control data is added to the previous content. So what Paul wrote should apply more to this window (and co) but then applied to content updates. The controls on the work (and co) tab(s) are really wasting cpu time because the content of these controls is rebuild even if the main window is not visible (minimized, …), but the possible waste op cpu time by the visual update of the controls, again the boinc dev team is not to blame but the ones who wrote the list and pie control.

but then again, I could be completely wrong ;)
ID: 28190 · Report as offensive
Profile Paul D. Buck
Volunteer tester

Send message
Joined: 19 Jul 00
Posts: 3898
Credit: 1,158,042
RAC: 0
United States
Message 28282 - Posted: 20 Sep 2004, 8:54:31 UTC - in response to Message 28190.  

Cryz,

> I don't believe the visual side of the message control gets updated. As far as
> I can tell from the function MessageUser, it updates the data in the message
> control and changes the icon if needed. The message control is an extension of
> a standard list control so this means:
> - if the message control is wasting cpu time by updating it's visual side
> then the dev team of the list control are to blame (=> dev team
> of the compiler, possibly Microsoft
)
> - Updating the contents (data, not visual) of the message control when an
> event happens or later when the control is visible again, CPU time used will
> be about the same.
>
> The fact that the message tab is the one being visible after a message is
> written to it when minimized or hidden, is because it is the last one updated
> (content). The big difference between the message control and the work control
> (and the controls on the other tabs) is the nature of the content. The content
> of the work control (and co) is rewritten every time (no trace of previous
> content) but for the message control data is added to the previous content. So
> what Paul wrote should apply more to this window (and co) but then applied to
> content updates. The controls on the work (and co) tab(s) are really wasting
> cpu time because the content of these controls is rebuild even if the main
> window is not visible (minimized, …), but the possible waste op cpu time by
> the visual update of the controls, again the boinc dev team is not to
> blame
but the ones who wrote the list and pie control.
>
> but then again, I could be completely wrong ;)

We are still in speculation mode here. And, in that light, what we have is nebulous at best. And most certainly it is very likely that it is the result of a library call and not the BOINC Developers who made the control. It could even be a result of a missed call that is not well documented.

At this stage we know next to nothing, and only have suspicions. And even if they are true, this is not the part I would be working on right now ... (believe it or not).

What interests me most is that when the BOINC Work Manager window is open, messages written do not change the tab selected. But when it is minimized, as soon as a message is written, the tab selected is changed to the Messages tab.

But I am still more interested in a cross-OS version of the BOINC Work Manager GUI.
<p>
For BOINC Documentaion: Click Me!


ID: 28282 · Report as offensive
Cryz

Send message
Joined: 22 Feb 02
Posts: 46
Credit: 9,737
RAC: 0
Belgium
Message 28294 - Posted: 20 Sep 2004, 9:31:53 UTC - in response to Message 28282.  

> Cryz,
>
> We are still in speculation mode here. And, in that light, what we have is
> nebulous at best. And most certainly it is very likely that it is the result
> of a library call and not the BOINC Developers who made the control. It could
> even be a result of a missed call that is not well documented.
>
> At this stage we know next to nothing, and only have suspicions. And even if
> they are true, this is not the part I would be working on right now ...
> (believe it or not).
>
> What interests me most is that when the BOINC Work Manager window is open,
> messages written do not change the tab selected. But when it is minimized, as
> soon as a message is written, the tab selected is changed to the Messages
> tab.
>
> But I am still more interested in a cross-OS version of the BOINC Work Manager
> GUI.

Paul,

If I’m not mistaken, you are an experienced programmer, I’m only a student. I respect you very much(and you work on the documentation), but I can’t let that prevent me from posting my opinion(s). I know I’m far from perfect so I added: “but then again, I could be completely wrong ;)”

I think most of the people working on boinc outside the boinc dev team are working on optimizing the seti part of boinc. I, being just a student, lack the experience to start optimizing that code for P4, 3Dnow and so on.

That’s why I’m looking and changing the boinc_gui code (and only testing it on windowsXP). I’m using (abusing) this code to learn more of C and C++, so why not try to make some simple option available from the GUI?
So I’m working on code to make Boinc remember more of it’s settings, adding project suspend options and maybe I try to give people(or maybe just me) more control over the scheduler.

On the cpu time topic:
I’ve done this little test on my P4 HT 3.0GHz with WinXp sp1 using the task manager and boinc uses most cpu time on the work tab when the window is visible(1-4%). When minimized it uses less cpu time(1%), but still more then minimized on the message tab(0-1%)

ID: 28294 · Report as offensive
Profile Paul D. Buck
Volunteer tester

Send message
Joined: 19 Jul 00
Posts: 3898
Credit: 1,158,042
RAC: 0
United States
Message 28299 - Posted: 20 Sep 2004, 9:51:02 UTC - in response to Message 28294.  

> Paul,
>
> If I’m not mistaken, you are an experienced programmer, I’m only a student. I
> respect you very much(and you work on the documentation), but I can’t let that
> prevent me from posting my opinion(s). I know I’m far from perfect so I added:
> “but then again, I could be completely wrong ;)”

Yes, I am an old and tired programer. I never said you should not post your opinions, nor ask questions. I am not sure where you got that from my last note, but I was not trying to turn you off, nor to chastize you for your questions. If I did give that impression I am truly sorry.

> I think most of the people working on boinc outside the boinc dev team are
> working on optimizing the seti part of boinc. I, being just a student, lack
> the experience to start optimizing that code for P4, 3Dnow and so on.

Yes there are efforts under way to to what you say, and in that sense what you are planning to do also comes under the heading of optimization. But yes, their concentration is on the math intensive part of the science application and at the moment only focusing on BOINC because of the fact that it is open source. I think there is a similar effort with Predictor@Home, but I may be wrong

And just for the record, I am not a developer on the BOINC team. I am just another participant like you on the outside looking in. I do the documentation because I can, and no one else was doing any meaningful documentation. It is something of a hobby of mine, so, natural inclenation has me doing this part (mis-spelling words along the way - math and spelling were never high on my list of run things - thank heaven for spell checkers).

> That’s why I’m looking and changing the boinc_gui code (and only testing it on
> windowsXP). I’m using (abusing) this code to learn more of C and C++, so why
> not try to make some simple option available from the GUI?
> So I’m working on code to make Boinc remember more of it’s settings, adding
> project suspend options and maybe I try to give people(or maybe just me) more
> control over the scheduler.

Oh, my yes. Good practice. The one thing you need to keep in mind is that most code is nothing to write home about. There is more commentary in the BOINC code than I thought there might be, but for all of that, it is not well documented with internal comments (speaking from the teacher's grading perspective).

> On the cpu time topic:
> I’ve done this little test on my P4 HT 3.0GHz with WinXp sp1 using the task
> manager and boinc uses most cpu time on the work tab when the window is
> visible(1-4%). When minimized it uses less cpu time(1%), but still more then
> minimized on the message tab(0-1%)

Interesting numbers ... but I would have thought that when closed it would be even less than that ...

At any rate, my comment about not spending time on it was only intended to mean the BOINC developers should not spend time here right now. Not that outsiders could not, or should not, just them. We need the cross-platform application or cut out a small but growing population of participants. Granted that in the near term the biggest group is going to be the windows PC, but, Linux in particular is showing up in greater and greater numbers. The Macintosh is also gaining, mainly because it does not run the windows OS.

Again, I apologise for the misunderstanding ...
<p>
For BOINC Documentaion: Click Me!


ID: 28299 · Report as offensive
1 · 2 · Next

Message boards : Number crunching : a bug, feature??


 
©2024 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.