fxruby users - Feb 2008 - FXColorDialog slow UI update

Hi Lyle,

I have noticed a very small problem with the FXColorDialog class: when
changing the color with the color wheel, it takes quite a long time
(until 4 seconds, sometimes less) for the other panels of the dialog to
synchronize.

The opposite is also true: when changing the color with the sliders, it
may take sometimes until 4 seconds for the color wheel to reflect the
change.

That''s not a big deal, really. I guess it is only a refresh problem,
which I also had on the other parts of my framework. I solved that with:

  def forceImmediatePageRefresh
    $app.repaint
    $app.forceRefresh
    $app.flush
  end

I''m not sure this is optimal at all, but it works!

Good luck with your book, and thanks for FXRuby,

Regards,

Philippe

Note: FXRuby 1.6.13 under Windows XP, with ruby 1.8.6

> I have noticed a very small problem with the FXColorDialog class: when
> changing the color with the color wheel, it takes quite a long time
> (until 4 seconds, sometimes less) for the other panels of the dialog
> to synchronize.
Did you try to put (if your app is not multi-threaded):

app.disableThreads

before app.create ?

I found that this speeds up the GUI updates considerably...

Vlad

Please access the attached hyperlink for an important electronic communications
disclaimer: http://www.lse.ac.uk/collections/secretariat/legal/disclaimer.htm

fxruby-users-bounces at rubyforge.org wrote:
>> I have noticed a very small problem with the FXColorDialog class:
>> when changing the color with the color wheel, it takes quite a long
>> time (until 4 seconds, sometimes less) for the other panels of the
>> dialog to synchronize.
> 
> Did you try to put (if your app is not multi-threaded):
> 
> app.disableThreads
> 
> before app.create ?
> 
> I found that this speeds up the GUI updates considerably...
Hi,

Thanks, it works just fine now. The problem disappeared. Is there a
reason why multithreading slows down FXRuby so much?

Philippe

> Thanks, it works just fine now. The problem disappeared. Is there a
> reason why multithreading slows down FXRuby so much?
I think it has to check some lock/mutex a _lot_ to make sure that
FXRuby data structures do not become corrupt (but this is only a guess,
not a knowledge from an expert ;-).

Vlad

Please access the attached hyperlink for an important electronic communications
disclaimer: http://www.lse.ac.uk/collections/secretariat/legal/disclaimer.htm

On Feb 28, 2008, at 7:16 AM, Philippe Lang wrote:
> Thanks, it works just fine now. The problem disappeared. Is there a
> reason why multithreading slows down FXRuby so much?

It''s related to the fact that Ruby doesn''t use native threads,
and
what I therefore have to do in FOX''s event loop in order to ensure  
that Ruby threads get scheduled.

FXRuby adds a chore that yields a little slice of time to Ruby''s  
thread scheduler whenever your application becomes idle. Even if you  
don''t *have* any other threads in your application, the FXRuby thread  
will "sleep" for 100 milliseconds every time that chore runs. You can
adjust the amount of time that FXRuby yields to the thread scheduler  
via the FXApp#sleepTime attribute, e.g.

	app.sleepTime = 50 # only sleep for 50ms at a time

Or you can just disable it altogether (as Vlad pointed out) by calling  
FXApp#disableThreads.

It''s an ugly solution to a tricky problem, but it''s all I
could come
up with. I am willing to consider patches that implement alternative  
solutions to the problem, however!

Hope this helps,

Lyle

fxruby-users-bounces at rubyforge.org wrote:
> On Feb 28, 2008, at 7:16 AM, Philippe Lang wrote:
> 
>> Thanks, it works just fine now. The problem disappeared. Is there a
>> reason why multithreading slows down FXRuby so much?
> 
> 
> It''s related to the fact that Ruby doesn''t use native
threads, and
> what I therefore have to do in FOX''s event loop in order to ensure
> that Ruby threads get scheduled.  
Hum ok. Wouldn''t it be a good idea then, until threads code gets
reimplemented, to disable threads by default under FXRuby? I *think* a
vast majority of FXRuby programers do not use threads at all. And those
who do could simply activate them explicitely?

Regards,

Philippe