FLTK logo

STR #2359

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

Return to Bugs & Features | Roadmap 2.0 | Post Text | Post File | SVN ⇄ GIT ]

STR #2359

Application:FLTK Library
Status:5 - New
Priority:4 - High, e.g. key functionality not working
Scope:3 - Applies to all machines and operating systems
Subsystem:Unassigned
Summary:cpu time sharing issues in v1 and v2 (solutions).
Version:2.0-current
Created By:rainbowsally
Assigned To:Unassigned
Fix Version:Unassigned
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Post File ]
Name/Time/Date Filename/Size  
 
#1 rainbowsally
07:44 Mar 02, 2011
xp-theme.png
14k
 
     

Trouble Report Comments:

Post Text ]
Name/Time/Date Text  
 
#1 rainbowsally
04:55 Apr 30, 2010
[V 1 users, there's a note about the "lock" function below that
you should see if you want your threads to behave properly.]

V2 user!  Here's the solution to your server crash.

The TabGroup cpu time hogging problem...

TabGroup will loop like crazy drawing and redrawing the overlay
whether it needs it or not until you manage to put a child widget
in it.  This only happens when the overlay is visible.

Solution?  Force the overlay drawing function in fluid to
time-share with the operating system instead of hogging time
(possibly due to TabGroups also being the window that is called by calling itself below).

In WindowType.cxx around line 43 add

  #include <unistd.h> // pause for cpu time sharing for empty TabGroup <-rs

and around line line 163 where you see...
  void Overlay_Window::draw_overlay() {
add...
    // TabGroup was hogging cpu time rs->
    usleep(1000); // share time with operating system, 1 uS even works.
above this...
    window->draw_overlay();
  }

That is a one millisecond delay.  It also works with a 1 microsecond delay
on my machine, but I'm not sure if all operating systems will honor a 1
microsecond delay.  Mine does. 

(Note to dev.  I have verfied that the window being called to draw
overlay is not the TabGroup window itself, so this is it for now.)

--------------------------------------------------------

I'd also VERY STRONGLY recommend anyone and everyone to add a 1
microsecond (really only one) to the thread lock function. This was
an issue with version 1 as well, but if you missed that post or
if it hasn't been addressed in the latest rev of version 1, you
do do it yourself quite easily if you still have the installation
files.

Here's where I inserted the code in version 2.

  void fltk::lock() {usleep(1); init_or_lock_function();}

And voila!  Your multi-threads now behave properly instead of hogging
cpu time and causing the queue to misfire. :-)

That function is in lock.cxx in version 2, possibly in Fl.cxx in ver 1.

Then run the thread test in either version and compare to previous
runs.
 
 
#2 bgbnbigben
01:31 Mar 02, 2011
RS, have you got an example where the queue "misfires" without your modification? The standard test/threads program runs fine....  
 
#3 rainbowsally
03:23 Mar 02, 2011
Hi Ben.

I noticed it in that very demo.

After some time, I realized that this is probably a Linux issue, and may even be related to the kernel version.  I'm using SuSE 10 Linux and whatever kernel that is.

Here's what I noticed (and what improves with a 'usleeep()' inserted from time to time.

The two displays burst at intervals of about half a second (might be lesss, but the bursts were noticeable).  With the kernel's version of a "check()" call (usleep()), they both stream evenly.

Again, if you don't try the usleep() you won't see the difference, and so, no.  I don't have any code that shows this clearly -- other than my own system which now uses a timer so that the usleep() is only called every 60 milliseconds.

First of all, though, just try adding a usleep(1) in the lock() function for test, then rerun the demo.  Remove it if you don't see a difference.

Then if you do see a difference, store the last time and only call usleep if some portion of a "timeslice" has expired.  I used 60 milliseconds because this is about half the usual timeslice I noticed in Linux.

There WILL be a performance hit, in terms of speed.  If this is unacceptable, that's your call.  But for a hit of about 5-10% in speed, the display looks much much smoother, which is what you'd expect from a multitasking/threaded application.

Hey!  It's great to see someone working on 2.0.  Thanks!!  :-)

I think you're going to love it, Ben, once you get to where things start working.  I did.  It's got tons of great stuff in it that I'd like to see in a 3.x someday.

If you don't have a copy of my 2.x you can install a sandboxed version using this.  I tried to keep my fltk-X2 fairly compatible with 2.x back then.

http://rainbowsally.net/tkf/fltk-x2/FLTK-X2-Personal-2010-12-17.tar.gz

I just tried that link and it appears to be good, but if you have anyh problems and if you want a copy, let me know and I'll re-upload it somewhere folks can get it.  One feature you're sure to want is the test/demo code.  It's all in the 2.0 dialect.  Themes also worked, such as they were.  But having working code to start with should make it a hell of a lot easier to get the other stuff working the way you want it.

You're a courageous fellow, Ben.  Thanks again.  It will get better...
 
 
#4 rainbowsally
03:34 Mar 02, 2011
Also...

If you get the fltk-x2 download AND you have linux, try the x2-find utility.

I started out using kdevelope for it's find function but x2-find (or something like it) makes finding needles in haystacks quite simple.  Best if you also have kate, but it allows using the built-in fltk editor if you need it (default).

Again, best wishes to all.
 
 
#5 bgbnbigben
03:46 Mar 02, 2011
So the problem is that if this *is* a bug, the usleep(1) (or however many milli/micro seconds) isn't really a valid fix.
On a kernel level, threading works properly. Which means there's some form of (surprise surprise) bug in the 2.0 code, currently.
I'm just trying to see if/where this bug exists, for now. All I've got currently is that it exists _somewhere_ inside the lock code :P
The other problem is that this bug is being found in a prime checker - and since the distribution of primes isn't quite linear, we can't really use when "Max Prime:" is updated as a valid checking mechanism.


... and now that I've written all that, this bug definitely exists. I can only see it when running *two* threading demos at once though, so it's probably slightly dependent on cpu stress.
Damnit. Oh well, I'll add this to the todo list, right after I fix the last two FileChooser STRs.
 
 
#6 AlbrechtS
06:21 Mar 02, 2011
... and I can confirm that it is also visible in the threads demo in FLTK 1.3 (and probably 1.1 as well). It looks different, though, on my different Ubuntu (9.10 and 10.10, resp.) VM's, running on the same Windows 7 host. The former looks much smoother, whereas the latter seems to hang longer between display updates. I never saw this on Windows.

So, if you can find a reason, I'd be interested in the solution for FLTK 1.x as well...
 
 
#7 rainbowsally
07:43 Mar 02, 2011
To Ben and AlbrechtS.

First to Ben.  As AlbrechtS mentioned, it this bug (or failure to address a kernel issue) is in FLTK going waaaay back.  My first note on this was in reference to 1.x.

While it may not be an appealing "fix" it's certainly valid.  It works.

Albrecht, a quick and dirty solution is to add usleep(1) in the lock() function.  I think it MAY be in the Fl.x code.  Can't recall, but a grep of the src files should show where it is.

Back to Ben.

The bugs are 99.9% gone in my fltk-x2 code, so if you want to take a peek, the link appears to be good.  Create a new user named ftlk-x2 or something and there will ZERO risk to any other version(s) you may have confusing each other.

You can also use the update.exec (clickable) in the hidden '.inst' folder to incorporate any changes you make into the installer itself.

In any case, 2.x was NOT that bad.  It just hadn't been finished.

You will definitely like it once you get past the half-written and broken code.

I'll send you some screenshots of it working if you like.  A computer CAS system, a stereo chorus effect, alpha-transparency overlays for buttons allowing highlight rollover effects to be generated in fluid... and lots and LOTS more.

Try the rainbowsally.net link above.  It installs into ~/usr32 even if it compiles the 64-bit version.  There are some notes on how to get certain non-missing libs to work with 32/64-bits so you can switch versions, as well.

I used to post screenshots here but I think that wasn't entirely appreciated.  So let me know.

I'll try to see if I can at least post my first working XP theme widget.  If there's a file attachment, that probably means I did it.  ;-)

DON'T GIVE UP. 2.x rocks.  I'm serious.
 
     

Return to Bugs & Features | Post Text | Post File ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.